binlog ログを自動的にクリーンアップする MySQL メソッド-mysql チュートリアル-php.cn

手順:

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 はマスターサーバー上の一連のログを取得します。
３．すべてのスレーブサーバーの中で最も古いログを特定します。これが対象のログです。すべてのスレーブサーバーが最新の場合、これがリストの最後のログになります。