web-dev-qa-db-ja.com

MySQLは引き続きバイナリログをパージし、expire_logs_daysを無視します

私たちはmysql v5.6.17を実行しており、バイナリログがパージされる原因が次のようなもの以外にあるかどうかはわかりません。

  • My.iniにexpire_logs_daysを追加します（show global variables like 'expire%';を介してサーバーに設定されていることを確認します）
  • 手動で実行 PURGE BINARY LOGS

メインデータベースをバックアップし、7Zipを使用して圧縮してから、別のサーバーにFTPで転送する夜間バックアップがあります。バイナリログは毎晩00:00に作成されたバイナリログにパージされることがわかりました。 GTIDを使用する実行中のレプリケーションマシンがあり、gtid_purgedで指定されたマスターでバイナリログを見つけることができないため、これは問題です。

これをトラブルシューティングするために2つのイベントを作成しました。最初のイベントは、パージされているこの期間中にテーブルへの一般的なロギングをオンにし、2番目のイベントは数時間後に一般的なログをオフにします。バックアップは00:05に開始され、パージは00:07頃に発行されます

PURGE MASTER LOGS TOコマンドはroot [root] @ localhost [:: 1]によって実行されていたようです。

これを実行するサーバーに接続している人はいません。 mysqldumpコマンドの--delete-master-logsはRESET MASTERと似ていますが、PURGE BINARY LOGSとは異なります。ただし、--delete-master-logsは使用しません。

パージの原因は何ですか？

mysqlmysqldumplogsgtid
1
HappySloth

問題は、使用しているMySQLのバージョンにあると思います。

あなたはMySQL 5.6.17を持っていますが、 MySQL 5.6.19の変更ログ はこれを持っています：

レプリケーション：SIGHUPシグナルの受信によりバイナリログがローテーションされた場合、新しいバイナリログには、そのバイナリログのGTIDイベントの後続の処理に必要なPrevious_gtid_eventが含まれていませんでした。 SIGHUPを受信すると、GTIDイベントを新しいログに書き込む前に、サーバーが必要なPrevious_gtid_eventを新しいログに書き込むようにするための手順が実行されます。バグ＃17026898）

これは単なる推測である可能性がありますが、I/Oスレッドがマスターでバイナリログのローテーションの臭いがするときに切断し、 expire_logs_days = 1の場合、最も古いバイナリログが消えているため、このバグが発生している可能性がありますスレーブのI/Oスレッドがバスの下にスローされ、見えなくなったGTID値を探します。

次のいずれかを行う必要がある場合があります。

  • 最新のMySQL 5.6（5.6.38）または少なくとも5.6.23にアップグレードする
  • 一部のオプションを変更します

ログの消失に関しては、FLUSH LOGSが手動または内部で実行されるたびに、 expire_logs_days * 86400秒より古いバイナリログが削除されます。

何年も前に expire_logs_days が毎晩午前0時にトリガーされることを覚えています（5.0.xに戻ります）。現在、 expire_logs_days は秒単位の粒度を持っています。

0
RolandoMySQLDBA