MySQLのバイナリログ削除タイミング

バイナリログの運用について

バイナリログは更新系のログが記録されますが、放っておくと際限なく増えます
先日、不可解な更新クエリが大量に発生し、ディスク容量が90％を超えてしまったのでその時の諸々のまとめ

障害前基本設定

[mysqld]
expire_logs_days=14

expire_logs_daysの動きについて

• MySQL の再起動時 もしくは、バイナリログのローテート時に実行される
• そのため、14日たてば自動的に削除されるわけではなく、少しずれる

障害時の挙動

• 20MB/s でディスクが使われていった

若手メンバーからの質問

Q: mysql-bin をrm していいですか？
A: ダメです。mysql の中に入ってpurge しないとディスクは空きません
Q: purge ってなんすか？
A: こんなクエリを投げるのだよ

mysql> PURGE MASTER LOGS TO 'mysql-bin.429210';
Query OK, 0 rows affected (0.02 sec)

対応方針

• 1ポジションで数百MBあったので、一気にpurge するとサービス中のMySQLが落ちる可能性があるので、少しづつ実行する
• ある程度purge が完了したら、my.cnf をいじって自動でpurge されるようにする

作業内容

• まず現在のポジションを確認する
  • ここまでは消して大丈夫！

mysql> SHOW MASTER STATUS\g;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.434364 | 85145715 |              |                  | 
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

• 一番古いログのpositionを探す

ls -ltr /data/mysql/mysql-bin* | head -100

• ひと思いに消す

mysql> PURGE MASTER LOGS TO 'mysql-bin.459210';
Query OK, 0 rows affected (0.02 sec)

障害後基本設定

[mysqld]
expire_logs_days=7