binlog ログを自動的にクリーンアップする MySQL メソッド

手順:

MySQL を開きます binlog サーバーがログを自動的に消去するように設定されていない場合、binlog ログはデフォルトで保持され、時間が経つとサーバーのディスク領域が binlog ログによっていっぱいになり、MySQL データベースでエラーが発生します。

binlog ログを安全にクリアするには、次の方法を使用します

1. マスターとスレーブの同期を行わずにログを削除します

mysql -uroot -p123456 -e 'PURGE MASTER LOGS BEFORE DATE_SUB( NOW( ),INTERVAL) 5 DAY)';

#mysql 5日前のbinlogを定期的にクリアします

mysql -u root -p #mysqlコンソールに入る

マスターログをリセットする

1, mysql -u root -p #スレーブに入るサーバー mysql コンソール

スレーブのステータスを表示 G; # スレーブサーバーからどのログを読み取っているかを確認します。 複数のスレーブサーバーが存在します。最も古いものを対象のログとして選択します。

2. マスターサーバーの mysql コンソールに入ります

show master log; #マスターサーバー上の一連のログを取得します

マスターログを 'binlog.000058' にパージします。 #binlog.000058 を除く、binlog.000005 より前のログを削除

'2016-06-22 より前のマスター ログをパージ 13:00:00'; #2016-06-22 13:00:00 までに binlog ログをクリア
マスター ログを削除してください DATE_SUB( NOW( ), INTERVAL 3 DAY); #3 日前のバイナリ ログ ログをクリアします

3、MySQL バイナリ ログ ログの自動クリーニングを設定します

vi /etc/my.cnf #設定を編集します

expire_logs_days = 15 #自动删除15天前的日志。默认值为0，表示从不删除。
log-bin=mysql-bin #注释掉之后，会关闭binlog日志
binlog_format=mixed #注释掉之后，会关闭binlog日志

:wq ! # 保存して終了します

詳細説明:

mysql>ヘルプパージ;

名前:'PURGE BINARY LOGS'

説明:

構文:

PURGE { BINARY MASTER } LOGS

{ TO 'log_name' | BEFORE datetime_ expr }

バイナリ ログは、MySQL サーバーによって行われたデータ

の変更に関する情報を含むファイルのセットです。ログは、

バイナリ ログ ファイルのセットとインデックス ファイルで構成されます (

を参照)。 http:// dev.mysql.com/doc/refman/5.5/en/binary-log.html)。

PURGE BINARY LOGS ステートメントは、指定されたログ インデックス ファイルより前のログ インデックス ファイルにリストされているすべてのバイナリ ログ ファイルを削除します

ログ ファイルの名前または日付。

BINARY と MASTER は同義語です。削除されたログ ファイルは

インデックス ファイルに記録されているリストからも削除されるため、指定されたログ ファイルは

リストの最初になります。

このステートメントサーバーがバイナリログを有効にする

--log-bin オプションを使用して起動されていない場合、効果はありません。

URL: http://dev.mysql.com/doc/refman/5.5/en/purge-binary- logs.html

例:

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

PURGE BINARY LOGS BEFORE '2008-04-02 22:46:26';

以下は、他のによって提供されるメソッドですネチズンの皆さん、参考にしてください

MYSQL マスター/スレーブ レプリケーションは RBR を使用します モードを変更すると、binlog の形式は「ROW」になり、元のキー重複の問題の多くを解決できます。

忙しいマスターデータベース内 サーバー上では、binlog ログ ファイルが急速に大きくなり、定期的にクリアしないと、すぐにハードディスクの容量がいっぱいになってしまいます。

mysqlの自動クリーニングを設定する バイナリ ログ、my.cnf の設定:

expire_logs_days = 10

実行時に変更:

バイナリ ログを表示

'%log%' のような変数を表示

set global expire_logs_days = 10;

クリアする前に、対応するバックアップ戦略を使用できます。

10 日前の MySQL binlog ログを手動で削除:

PURGE MASTER LOGS BEFORE DATE_SUB(CURRENT_DATE, INTERVAL 10 DAY);

show マスター ログ;

MASTER と BINARY は同義語です。

通常の状況では、MIXED binlog レプリケーションを使用することをお勧めします。 http://dev.mysql.com/doc/refman/5.1/en/open-bugs-general.html の手順: レプリケーション クエリレベルのロギングを使用します: マスターは実行されたクエリをバイナリに書き込みます これは、非常に高速かつコンパクトで効率的なロギング方法です。 ほとんどの場合、完全に完了します。

添付: MYSQL レプリケーションのいくつかのモード

MySQL 5.1.12 以降、次の 3 つのモードを使用して実現できます:

– ステートメントベースのレプリケーション レプリケーション (SBR)、

– 行ベースのレプリケーション (行ベースのレプリケーション (RBR)、
–) 混合ベースのレプリケーション (MBR)。
これに対応して、binlog には STATEMENT、ROW、および MIXED の 3 つの形式があります。 MBR モードでは、SBR モードがデフォルトです。

次の状況を除き、実行時に動的に変更できます:
ストレージ プロセスまたはトリガーの途中で

現在のセッションで RBR を試してください。 モードになり、一時テーブルが開かれました

binlog が MIXED モードを採用している場合、以下の状況では、binlog モードは SBR モードから RBR モードに自動的に変更されます。
。 DML ステートメントが NDB テーブルを更新する場合
。関数に UUID() が含まれる場合

。AUTO_INCREMENT フィールドを含む 2 つ以上のテーブルが更新される場合

。 INSERT DELAYED ステートメントを実行する場合
。UDF を使用する場合
。ビューの作成時など、ビューで RBR を使用する必要がある場合は、UUID() が使用されます。 機能

マスター/スレーブ レプリケーション モードを設定します:
log-bin=mysql-bin
#binlog_format="STATEMENT"
#binlog_format="ROW"
binlog_format="MIXED"

実行時に binlog 形式を動的に変更することもできます。たとえば、
mysql> SET SESSION binlog_format = 'ステートメント';
mysql> SET SESSION binlog_format = 'ROW';
mysql> SESSION binlog_format = 'MIXED';
mysql> SET GLOBAL binlog_format = 'ステートメント';
mysql> SET GLOBAL binlog_format = 'ROW';
mysql> GLOBAL binlog_format = 'MIXED';

2 つのモードの長所と短所:

SBR 利点:
長い歴史、成熟したスキル
binlog ファイルのサイズが小さい
binlog にはすべてのデータベース変更情報が含まれており、データベースのセキュリティやその他の状況の監査に使用できます
binlog はレプリケーションだけでなく、リアルタイムの復元にも使用できます
マスタースレーブのバージョンは異なる場合があり、スレーブ サーバーのバージョンはマスター サーバーのバージョンよりも高い場合があります
SBR 欠点:
特に不確実な操作が含まれている場合、すべての UPDATE ステートメントをコピーできるわけではありません。
非決定的な要素を使用して UDF を呼び出す コピー時に問題が発生する可能性があります。次の関数を使用するステートメントはコピーできません:
* LOAD_FILE()
* UUID()
* USER()
* FOUND_ROWS()
* SYSDATE() (起動時に –sysdate-is-now オプションが有効でない場合)
INSERT … SELECT RBR よりも多くの行レベルのロックが生成されます
コピーでフルテーブルスキャンの UPDATE を実行する必要がある場合 (WHERE ステートメントでインデックスが使用されていない場合)、RBR よりも高速である必要があります より多くの行レベルのロックをリクエストします
AUTO_INCREMENT フィールドを持つ InnoDB テーブルの場合、INSERT ステートメントは他の INSERT をブロックします ステートメント
一部の複雑なステートメントでは、スレーブ サーバーのリソース消費がより深刻になり、RBR モードでは、変更されたレコードにのみ影響します
ストアド関数 (ストアド プロセスではありません) ) は、呼び出されたときに NOW() 関数を 1 回実行します。これは悪いことにも良いことにもなります
UDF の決定 スレーブサーバーでも実行する必要があります
データテーブルはマスターサーバーとほぼ一致している必要があります。そうでないとレプリケーションエラーが発生する可能性があります
複雑なステートメントの実行時にエラーが発生すると、より多くのリソースが消費されます

RBR 利点:

あらゆる状況をレプリケートできるため、レプリケーションにとって最も安全で信頼性が高くなります
他のほとんどのデータベース システムのレプリケーション スキルと同じです
ほとんどの場合、スレーブ サーバー上のテーブルに主キーがある場合、レプリケーションは非常に効果的です高速化
次のステートメントをコピーする際の行ロックが少なくなります:
* INSERT … AUTO_INCREMENT フィールドを含む SELECT
* INSERT
* 条件なし、または多くのレコードを変更せずに UPDATE または DELETE ステートメント
INSERT、UPDATE、DELETE ステートメントを実行する際のロックが軽減されます
マルチスレッドを使用してサーバーからレプリケーションを実行することが可能です
RBR 欠点:
ビンログが非常に大きくなります
複雑なロールバック中、ビンログには大量のデータが含まれます
メインサーバーでUPDATEを実行します ステートメントを使用すると、変更されたすべてのレコードが binlog に書き込まれますが、SBR は 1 回しか書き込まないため、binlog の同時書き込みの問題が頻繁に発生します
UDF によって生成される大きな BLOB この値により、レプリケーションが遅くなります
どのステートメントがコピーされ、書き込まれた (暗号化された) のかはバイナログからは確認できません
非トランザクション テーブルで大量の SQL ステートメントを実行する場合は、SBR を使用するのが最善です そうしないと、マスターサーバーとスレーブサーバーの間でデータの不整合が発生しやすくなります
さらに、システムライブラリ mysql 内のテーブルの変更の処理ガイドラインは次のとおりです:
INSERT、UPDATE、DELETEでテーブルを直接操作した場合、binlog_format
の設定に従ってログ形式が記録されます GRANT、REVOKE、SET PASSWORD などの管理ステートメントを使用してこれを行う場合、何があっても SBR モード記録が使用されます。
注: RBR の使用 このモードの実装後、当初発生していた主キーの重複の問題の多くは解決できます。例:
db_allot_ids に挿入するには、* from を選択します db_allot_ids このステートメント:
BINLOG_FORMAT=STATEMENT モード:
BINLOG ログ情報は次のとおりです:
————————————–
BEGIN
/*!*/;
# at 173
#090612 16:05:42 サーバー ID 1 end_log_pos 288 クエリ thread_id=4 exec_time=0 error_code=0
SET TIMESTAMP=1244793942/*!*/;
db_allot_ids に挿入 select * from db_allot_ids
/*!*/;
————————————–

BINLOG_FORMAT=ROW モードの場合:

BINLOG ログ情報は:
———————————— ———–
ビンログ '
hA0yShMBAAAAMwAAAOAAAAAAA8AAAAAAAAA1NOUwAMZGJfYWxsb3RfaWRzAAIBAwAA
hA0yShcBAAAANQAAABUBAAAQAA8AAAAAAAEAAv/8AQEAAAD8AQEAAAD8AQEAAAD8AQEAAAA=
'/*!*/;
———————————— ——–

ログをクリアする手順
1. ログ ファイルを検索します
mysql> show binary ログ;
+----------------+----------+
| ファイル名 | |
+----------------+----------+
|ablelee.000001 |
| 125 |
| 106 |
+----------------+----------+
2. bin-log を削除します (ablelee.000003 より前のものを削除しますが、含まれていません) ablelee .000003)
mysql> バイナリ ログを 'ablelee.000003' にパージします。
クエリ OK、影響を受ける行は 0 件 (0.16 秒)

3. クエリ結果 (現在レコードは 1 つだけです。)

mysql> show binlog eventsG
***************** ***** * 1.行 ****************************
Log_name:ablelee.000003
位置: 4
イベントタイプ: Format_desc
サーバー ID: 1
End_log_pos: 106
情報: サーバー バージョン: 5.1.26-rc-log、ビンログ バージョン: 4
セット内の 1 行 (0.01 sec)
(ablelee.000001 とablelee.000002 は削除されました)
mysql> バイナリを表示 ログ;
+-----+----------+
| ファイル名 | |
+----------------+----------+
| |
+----------------+----------+
セット内の 1 行 (0.00 秒)

(他の形式は削除されました!)
{MASTER BINARY} のログをパージします | 'log_name'
{MASTER BINARY} ログを前にパージします 'date'
指定されたログまたは日付より前の、ログ インデックスにリストされているすべてのバイナリ ログを削除するために使用されます。これらのログは、ログ インデックス ファイルに記録されるリストからも削除され、指定されたログが最初になります。
例:
パージ マスター ログを 'mysql-bin.010';
'2008-06-22 より前のマスター ログをパージ 13:00:00';
3 日前のバイナリログをクリアします
DATE_SUB( NOW( ), INTERVAL 3 DAY);
BEFORE 変数の日付引数は「YYYY-MM-DD」にすることができます 「hh:mm:ss」形式。 MASTER と BINARY は同義語です。
削除しようとしているログの 1 つを現在読み取っているアクティブなスレーブ サーバーがある場合、このステートメントは機能せず、エラーで失敗します。ただし、スレーブが静止していて、読み取り対象のログの 1 つをたまたまクリアした場合、スレーブは起動後に複製できません。このステートメントは、スレーブ サーバーの複製中に安全に実行できます。彼らを止める必要はありません。
ログをクリアするには、以下の手順に従ってください:
1. 各スレーブで、SHOW SLAVE STATUS を使用して、どのログを読み取っているかを確認します。
2. SHOW MASTERを使用する LOGS はマスター サーバー上の一連のログを取得します。
３． すべてのスレーブ サーバーの中で最も古いログを特定します。これが対象のログです。すべてのスレーブ サーバーが最新の場合、これがリストの最後のログになります。

4. 削除するすべてのログのバックアップを作成します。 (このステップはオプションですが、お勧めします。)

5. 対象のログを除くすべてのログをクリーンアップします

上記は、MySQL の binlog ログを自動的にクリーンアップする方法の内容です。その他の関連記事については、 PHP 中国語 Web サイト (www.php.cn) をフォローしてください。