web-dev-qa-db-ja.com

時間のかかるバイナリログのパージ

いくつかのクエリの待ち時間が長くなっていることを確認しています。さらに掘り下げてみると、遅いクエリログを調べると、5分ごとにクエリに長い時間がかかることがわかりました。

私たちはそれを観察しました

PURGE BINARY LOGS TO 'mysql-bin-changelog.041045';

5分ごとに実行され、1000ミリ秒以上かかります。同時に次のようなクエリ

SET timestamp=1492673425; commit;

また時間をかけて

SELECT @@session.tx_isolation;

Amazon RDSではMySQL 5.7.11を使用しています。 PURGE BINARY LOGSより時間がかかり、他のクエリも同時にスタックしますか？

mysqlamazon-rdsmysql-5.7binlog
1
Ahmed

これは、2か月前にRDSの外で経験したMySQL 5.7のかなり厄介なバグです。バイナリログのパージの動作に関連する奇妙なミューテックス動作があります。

私の回避策は、bin-log.indexにリストされているOSのバイナリログの一部を手動で削除し、PURGE BINARY LOGS BEFORE CURDATE() + INTERVAL 2 HOUR;を実行することでした（毎朝2AMパージ）。検査するOS内のファイルが少なかったため、速度が向上しました。まだ存在している実際のバイナリログに関しては、PURGE BINARY LOGS ...単にドラッグしました。それが私が手動の煙と鏡のようなものをした理由です。

あなたの実際の状況

特定のインスタンスでは、RDSを使用しています。 OSにアクセスできないため、RDSパラメータグループで max_binlog_size を変更できないため、binlogに対して他にできることはありません。 binlogへの書き込みに先立ってキャッシュする必要がある大きなトランザクションまたは多くのトランザクションがある場合、 max_binlog_cache_size を変更できますが、これは、アプリでの書き込み頻度に応じて役立つ場合とない場合があります。

勧告

この問題はMySQL 5.6には存在しません。

DBをMySQL 5.6.27 RDSに移行する必要がある場合があります。

エピローグ

私の経験から、MySQL 5.7.12のこのバグの被害を受けました。 MySQL 5.7.14で バグが対処されました であると私に通知しました。思い通りにアップグレードできたらよかったのに。あなたの状況がMySQL 5.7.11になったので、私以外の誰かがこの問題に気づいたことを知っていました。できるだけ早く5.7.16にアップグレードしてください。良い一日を過ごしてください ！！！

1
RolandoMySQLDBA

構成を変更できる場合は、

  • 下max_binlog_size
  • expire_logs_daysを手動で使用する代わりに、PURGE BINARY LOGSを適切な値に設定します。

PURGEがRDSのメンテナンススクリプトからのものである場合は、Amazonにバグレポートを提出してください。

0
Rick James