概要
検証環境のZabbixサーバーがディスクフルでサービス停止していたため調べたところ、/data/mysql配下にmysql-bin-*ファイルが大量に作成されており、ディスク使用量が100%になっていた。なるほど。
原因
expire_logs_days設定していなかった?
いや、していた。"expire_logs_days=7"で設定しており、今までバイナリファイルによるディスクフルは発生していなかった。
じゃあ何が原因だったの?
最近、検証のためにZabbixエージェントの監視間隔を30秒⇒1秒にしていたため、バイナリファイルに書き込まれるイベント数が大幅に増加し、バイナリファイルの出力が増えたことが原因だと考えれる。4日間でディスクを50GB以上使っていたのでそれはディスク圧迫するよね。。。
そもそもmysql-binファイル何者?
公式ドキュメントを読んでみる。
バイナリログには、テーブル作成操作やテーブルデータへの変更などのデータベース変更を記述する「イベント」が格納されます。
なるほど。データのレプリケーションやリカバリに使われるのがこのバイナリファイルらしい。現状、レプリケーションする予定もないし7日間もバイナリファイル保持しなくてもいいので、今回はこの期間を短くして対応したい。
dev.mysql.com
対処
そもそもMariaDBサービスが立ち上がらない
ディスクフルでサービス起動失敗するので、/data/mysql/mysql-bin*ファイルを空きディスクに移行させる。1つずつファイル移動させないとだめだったので、複数ファイル移動させてからサービス立ち上げる。
# 適当にディレクトリ作成して移動させる mkdir /home/tmp/ mv /data/mysql/mysql-bin.xxxx /home/tmp # ディスクに空きができたらサービス立ち上げる systemctl restart mariadb
purgeコマンドでバイナリファイル削除する
MySQLのコマンドpurgeを使ってログファイルを消していく。rmコマンドでこのバイナリファイルを削除するとエラーになってしまうらしいので注意。。
# バイナリファイル削除 mysql -u root -p purge master logs before 'YYYY-MM-DD hh:mm'; exit; # ディスクの空き容量確認 df -h
この後退避させたバイナリファイルも削除を忘れずに。(これはrmコマンドで消した)
my.cnfを書き換える
バイナリファイルのサイズと出力頻度を見ると、1日に1.1GBのファイルが12回出力されていたのでディスクのサイズ的に2日以上保持しないように変更した。
# バイナリファイル保持期間変更 vi /etc/my.cnf expire_logs_days=2 # mariaDB再起動 systemctl restart mariadb
正常にmariaDBが立ち上がれば問題なし。
追加設定
追記。
やっぱり不安だから1日の保持期間より短くしたいと思って、cronで定期的にqurgeしてくれるように設定を追加した。
vi purge_binary_log.spl frush logs; purge master logs before now() - interval 5 hour;
crontab -e 0 * * * * mysql -u[username] -p[password] < purge_binary_log.sql
まとめ
Zabbixのデータ取得間隔変えるとバイナリファイルの出力も増えることが今回の学び。
おしまい。