web-dev-qa-db-ja.com

パージまたはフラッシュ後もMySQL binログファイルがまだ存在するのはなぜですか？

PURGE BINARY LOGSとFLUSH LOGSを使用しましたが、mysqlディレクトリには次のファイルがまだ含まれています。

mysql-bin.000025
mysql-bin.000024
mysql-bin.000023
mysql-bin.000022
mysql-bin.000021
mysql-bin.000020
mysql-bin.000019
mysql-bin.index

コマンドの使用が機能しない理由はありますか？これらのファイルは多くのスペースを使用しています。無事に取り除きたいです。

mysqlbinlogmysqlbinlog
12
lamp_scaler

PURGE BINARY LOGS ステートメントは、指定されたログファイル名またはタイムスタンプの前に、ログインデックスファイルにリストされたすべてのバイナリログファイルを削除します。削除されたログファイルもインデックスファイルに記録されたリストから削除されるため、指定されたログファイルがリストの最初になります。

コマンドを使用してバイナリログをmysql-bin.000019までパージしたことを願っています

PURGE BINARY LOGS TO 'mysql-bin.000019';

すべてのログを消去する必要がある場合は、次のようにします

PURGE BINARY LOGS TO 'mysql-bin.000025';

これにより、mysql-bin.000025までのバイナリログが削除されます。

[〜＃〜]更新[〜＃〜]

あなたが試すことができます

RESET MASTER;

RESET MASTER インデックスファイルにリストされているすべてのバイナリログファイルを削除し、バイナリログインデックスファイルを空にリセットして、新しいバイナリログファイルを作成します

RESET MASTERの影響は、主に2つの点でPURGE BINARY LOGSの影響とは異なります。

  1. RESET MASTERは、インデックスファイルにリストされているすべてのバイナリログファイルを削除し、数字のサフィックスが.000001の空のバイナリログファイルを1つだけ残しますが、番号付けはPURGE BINARY LOGSによってリセットされません。

  2. RESET MASTERは、レプリケーションスレーブの実行中に使用するためのものではありませんでした。スレーブの実行中に使用した場合のRESET MASTERの動作は定義されていないため（したがってサポートされていません）、レプリケーションスレーブの実行中にPURGE BINARY LOGSを安全に使用できます。

RolandoMySQLDBAによる警告

スレーブが接続されて実行されている状態でRESET MASTERを実行すると、各スレーブのIOスレッドはすぐにその場所を失います。そのため、レプリケーションが壊れ、データの取得に時間を費やす必要があります。すべてのスレーブが再び同期されました。レプリケーションの整合性を損なうことなく、マスターからバイナリログを安全に削除したい場合は、次のようにします。

  • 各スレーブでSHOW SLAVE STATUS\Gを実行します。
  • Relay_Master_Log_Fileに注意してください。これは、最新のステートメントがスレーブで正常に実行されたバイナリログです。
  • SHOW SLAVE STATUS\Gのすべての表示から、どのRelay_Master_Log_Fileが最も古いかを特定します（たとえば、「mysql-bin.00123」）。
  • PURGE BINARY LOGS TO 'mysql-bin.00123';を実行できます。スレーブはどれも場所を失いません。

全体的な効果は？これにより、現時点ですべてのスレーブで実行されていないステートメントのマスターにバイナリログが残ります。

10
Abdul Manaf

これがあなたに何が起こったのかはわかりませんが、私の場合、MySQLはログの「循環」を停止し、mysql-bin.indexファイルは無効なbinlogファイルエントリで「破損」していました。

具体的には、インデックスファイルはmysql-bin.000001で始まり、mysql-bin.000220に到達しましたが、なんとかして001から再び始まりました。これをサーバー上のファイルと比較すると、001から022。

最初に試しましたPURGE LOGS TO 'mysql-bin.000022';しかし、これは機能しませんでした。

最後に、MySQLを停止し、サーバーにあるファイルと一致するまでインデックスファイルを手動で編集しました。 MySQLを再起動すると、binlogファイルがクリーンアップされ、expire_logs_days設定し、再び正常に動作し始めました。

5
sysadmiral

私の場合、PURGE BINARYは何も削除していませんでした。

私は自分のパーティションを100％使用していました（mysqlを再起動するのに十分なスペースができるように、スロークエリログを少しクリーンアップする必要がありました）。そのため、最初に/etc/my.cnfを変更して、行にコメントを付けましたlog-bin=mysql-bin（このサーバーでは必要なくなったため、削除するのを忘れていました）、次にmysqlを再起動しました（キューに入れられたクエリがあり、PURGE BINARYの実行を妨げていたため、これが必要でした）。

その後、PURGE BINARYを実行しましたが、何も起こりませんでした。だから私は manual を読んで、それを見つけました：

サーバーがバイナリログを有効にする--log-binオプションで起動されていない場合、このステートメントは効果がありません。

そのため、log-bin=mysql-binで/etc/my.cnfを再度有効にし、再起動し、ファイルをパージし（現在は成功）、行に再度コメントしてから再起動しました。この後、ファイルは削除され、作成されなくなりました。

3
carla

これは私のために働きます：（MySQLサーバーのバージョン：5.6.14）

PURGE BINARY LOGS BEFORE NOW();

システム上のすべてのバイナリログを削除します。

2
grobmotoriker

[〜＃〜] all [〜＃〜]ログを簡単に削除できます：

PURGE BINARY LOGS BEFORE NOW();

または、引用符で囲まれた任意の日付でfunc NOW（）を置き換えます。

PURGE BINARY LOGS BEFORE '2018-02-15 00:00:00';

または、my.cnfのexpire_logs_days = 10を使用してこのアクションを自動化できます。デフォルトでは、expire_logs_daysは=ログを削除しません。

（ ソース ）

0
c ccx