数か月前、MySQLのセットアップを5.5から5.6に更新しました。それ以来、さまざまなデータベースをダンプしてバックアップできるようにするために使用するスクリプトで問題が発生しています。
このスクリプトは、すべてのデータベースのリストを取得し、次のようにそれぞれに対してmysqldump
を呼び出すPerlの短い部分です。
mysqldump -udb_account -pdb_pw -hserver.com --single-transaction --flush-logs
--routines --triggers --quick $fn 2> $fn.err | gzip > $fn.mysql.gz
問題:これらのデータベースの多くには、数百のテーブルがあります(増え続けています)。これらの大きなデータベースの場合、mysqldump
コマンドは単一のテーブルの後で終了することがよくあります。 ターミナルセッションからコマンドを実行すると、正しく実行されます。(通常はcronジョブ1x/wkとして実行されます)
.err
ファイルにはメッセージが含まれていません。 MySQLルートディレクトリのserver.err
ファイルも同様です。
注:このスクリプトは、MySQL5.5で数年間正常に実行されていました。この問題は、5.6にアップグレードしたときに発生し始めました。
また、--flush-logs
の部分が機能していません。このシステムがオンラインになって以来、mysql_binフォルダーが空になることはありません。
私がまだ制御していない変数の1つ:CRONジョブとして実行すると、スクリプトは一度に3つのプロセスをフォークします。タームセッションでコマンドをテストするときは、一度に1つしか実行していません。
問題のシステム:
ここでの問題は単なる誤解です
-flush-logs をmysqldumpで使用すると、以下に対してすべてのファイルハンドルが閉じられ、開かれます。
バイナリログの場合、現在のバイナリログが閉じられ、新しいバイナリログが開かれます。本質的に、これは数値的にローテーションされる唯一のログファイルです。たとえば、SHOW MASTER STATUS;
を実行し、バイナリログファイル名mysql-bin.000027
が表示されたとします。 FLUSH LOGS;
またはFLUSH BINARY LOGS;
を実行すると、mysql-bin.000027
(そのファイルへのトランザクションの記録が停止)が閉じ、mysql-bin.000028
(着信トランザクションの記録)が開きます。
ただし、ローテーションは自動削除を意味するものではありません。
バイナリログをクリーンアップする方法は2つあります
DBサーバーがMySQLレプリケーションマスターとして使用されていない場合は、
mysql> RESET MASTER;
これにより、すべてのバイナリログが消去され、最初のログから開始されます(mysql-bin.000001
など)。
OSに移動し、削除コマンドを実行するだけです(Linuxの場合はrm
、Windowsの場合はdel
)
過去48時間のバイナリログを保持する場合は、
mysql> PURGE BINARY LOGS BEFORE NOW() - INTERVAL 48 HOUR;
mysqldは、48時間より古いすべてのバイナリログを消去します。
My.cnf(またはmy.ini)に以下を設定するだけです。
[mysqld]
expire_logs_days=2
次に、mysqldを再起動するか、以下をroot
として実行します。
mysql> SET GLOBAL expire_logs_days = 2;
そうすれば、バイナリログを手動または自動でフラッシュするたびに、2日より古いログが削除されます。
expire_logs_days が設定されると、mysqldumpは毎回古いログをクリーンアップします -flush-logs を実行します。