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

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

この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';スレーブはその場所を失うことはありません。

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

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

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

最初は試しましたPURGE LOGS TO 'mysql-bin.000022';がうまくいきませんでした。

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

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

私がした最初のものは変化であったので、私は、（私は再起動するためのMySQLへの十分なスペースがありましたように、私のslowqueriesビットを記録クリーンアップする必要がありました）、100％の使用率で私のパーティションを持っていた/etc/my.cnf行をコメントするlog-bin=mysql-bin（それが必要とされませんでしたこのサーバーでもう削除するのを忘れていたため）、次にmysqlを再起動しました（PURGE BINARY実行を妨げるクエリがキューに入れられていたため、これは必要でした）。

その後、私は走ったPURGE BINARYが何も起こらなかった。だから私はマニュアルを読んでそれを見つけました：

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

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

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

PURGE BINARY LOGS BEFORE NOW();

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

あなたは簡単にすべてのログを削除することができます：

PURGE BINARY LOGS BEFORE NOW();

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

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

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

（ソース）