MySQL 8.0 リファレンスマニュアル


13.4.1.2 RESET MASTER ステートメント

RESET MASTER [TO binary_log_file_index_number]
警告

このステートメントは、必要なバイナリログファイルデータおよび GTID 実行履歴が失われないように注意して使用してください。

RESET MASTER には、RELOAD 権限が必要です。

バイナリロギングが有効になっている (log_binON) サーバーの場合、RESET MASTER は既存のバイナリログファイルをすべて削除し、バイナリログインデックスファイルをリセットして、バイナリロギングが開始される前の状態にサーバーをリセットします。 バイナリロギングを再開できるように、新しい空のバイナリログファイルが作成されます。

GTID が使用されている (gtid_modeON) サーバーの場合、RESET MASTER を発行すると GTID 実行履歴がリセットされます。 gtid_purged システム変数の値は空の文字列 ('') に設定され、gtid_executed システム変数のグローバル値 (セッション値ではない) は空の文字列に設定され、mysql.gtid_executed テーブルはクリアされます (mysql.gtid_executed テーブル を参照)。 GTID 対応サーバーでバイナリロギングが有効になっている場合、RESET MASTER は前述のようにバイナリログもリセットします。 GTID 対応サーバーがバイナリロギングが無効になっているレプリカであっても、RESET MASTER は GTID 実行履歴をリセットする方法であることに注意してください。RESET REPLICA | SLAVE は GTID 実行履歴に影響しません。 GTID 実行履歴のリセットの詳細は、GTID 実行履歴のリセット を参照してください。

オプションの TO 句を指定せずに RESET MASTER を発行すると、インデックスファイルにリストされているすべてのバイナリログファイルが削除され、バイナリログインデックスファイルが空にリセットされ、1 から始まる新しいバイナリログファイルが作成されます。 リセット後に 1 以外の番号からバイナリログファイルのインデックスを開始するには、オプションの TO 句を使用します。

RESET MASTERTO 句とともに使用してバイナリログファイルのインデックス番号を指定すると、FLUSH BINARY LOGS および PURGE BINARY LOGS TO ステートメントの代わりに単一のステートメントが提供されるため、フェイルオーバーが簡略化されます。 インデックス番号に適切な値を使用していることを確認します。 間違った値を入力した場合は、TO 句を指定して、または指定せずに別の RESET MASTER ステートメントを発行することで、これを修正できます。 範囲外の値を修正しないと、サーバーを再起動できません。

次の例では、TO 句の使用方法を示します:

RESET MASTER TO 1234;

SHOW BINARY LOGS;
+-------------------+-----------+-----------+
| Log_name          | File_size | Encrypted |
+-------------------+-----------+-----------+
| source-bin.001234 |       154 | No        |
+-------------------+-----------+-----------+
重要

TO 句を使用しない RESET MASTER の効果は、PURGE BINARY LOGS の効果と 2 つの重要な点で異なります:

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

  2. RESET MASTER は、レプリカの実行中に使用することを意図していません。 レプリカの実行中に RESET MASTER を使用した場合の動作は定義されていません (したがってサポートされていません)。一方、レプリカの実行中は PURGE BINARY LOGS を安全に使用できます。

セクション13.4.1.1「PURGE BINARY LOGS ステートメント」も参照してください。

TO 句のない RESET MASTER は、ソースおよびレプリカを最初に設定するときに役立つことがあるため、次のように設定を検証できます:

  1. ソースとレプリカを起動し、レプリケーションを開始します (セクション17.1.2「バイナリログファイルの位置ベースのレプリケーションの設定」 を参照)。

  2. ソースでいくつかのテストクエリーを実行します。

  3. クエリーがレプリカにレプリケートされたことを確認します。

  4. レプリケーションが正しく実行されている場合は、STOP REPLICA | SLAVE を発行してからレプリカで RESET REPLICA | SLAVE を発行し、テストクエリーからの不要なデータがレプリカに存在しないことを確認します。

  5. ソースで RESET MASTER を発行して、テストクエリーをクリーンアップします。

設定の確認、ソースおよびレプリカのリセット、およびテストによって生成された不要なデータまたはバイナリログファイルがソースまたはレプリカに残っていないことの確認後、レプリカを起動してレプリケートを開始できます。


関連キーワード:  ステートメント, CREATE, TABLE, MASTER, DROP, バイナリ, SLAVE, サーバー, サブクエリー, REPLICA