このページは機械翻訳したものです。

13.4.2.5 RESET REPLICA | SLAVE ステートメント

RESET {REPLICA | SLAVE} [ALL] [channel_option]

channel_option:
    FOR CHANNEL channel

RESET REPLICA | SLAVE では、レプリカはソースバイナリログ内の位置を忘れます。 MySQL 8.0.22 から、RESET SLAVE のかわりに RESET REPLICA を使用します。これは、そのリリースから非推奨になりました。 MySQL 8.0.22 より前のリリースでは、RESET SLAVE を使用します。

このステートメントはクリーンスタートに使用されます。レプリケーションメタデータリポジトリをクリアし、すべてのリレーログファイルを削除して、新しいリレーログファイルを開始します。 また、CHANGE REPLICATION SOURCE TO ステートメント (MySQL 8.0.23 から) または CHANGE MASTER TO ステートメント (MySQL 8.0.23 より前) の SOURCE_DELAY | MASTER_DELAY オプションで指定されたレプリケーション遅延を 0 にリセットします。

注記

レプリケーション SQL スレッドによって完全に実行されていない場合でも、リレーログファイルはすべて削除されます。 (STOP REPLICA | SLAVE ステートメントを発行した場合、またはレプリカの負荷が高い場合、これはレプリカに存在する可能性があります。)

GTID が使用されている (gtid_mode が ON) サーバーの場合、RESET REPLICA | SLAVE を発行しても GTID 実行履歴には影響しません。 このステートメントでは、gtid_executed、gtid_purged または mysql.gtid_executed テーブルの値は変更されません。 GTID 実行履歴をリセットする必要がある場合は、GTID 対応サーバーがバイナリロギングが無効になっているレプリカであっても、RESET MASTER を使用します。

RESET REPLICA | SLAVE には、RELOAD 権限が必要です。

RESET REPLICA | SLAVE を使用するには、レプリケーション SQL スレッドおよびレプリケーション I/O スレッドを停止する必要があるため、実行中のレプリカでは、RESET REPLICA | SLAVE を発行する前に STOP REPLICA | SLAVE を使用します。 グループレプリケーショングループメンバーで RESET REPLICA | SLAVE を使用するには、メンバーステータスが OFFLINE である必要があります。つまり、プラグインはロードされますが、メンバーは現在どのグループにも属していません。 グループメンバーは、STOP GROUP REPLICATION ステートメントを使用してオフラインにできます。

オプションの FOR CHANNEL channel 句を使用すると、ステートメントが適用されるレプリケーションチャネルの名前を指定できます。 FOR CHANNEL channel 句を指定すると、RESET REPLICA | SLAVE ステートメントが特定のレプリケーションチャネルに適用されます。 FOR CHANNEL channel 句を ALL オプションと組み合せると、指定したチャネルが削除されます。 チャネルが指定されておらず、追加のチャネルが存在しない場合、ステートメントはデフォルトチャネルに適用されます。 複数のレプリケーションチャネルが存在する場合に FOR CHANNEL channel 句なしで RESET REPLICA | SLAVE ALL ステートメントを発行すると、all レプリケーションチャネルが削除され、デフォルトチャネルのみが再作成されます。 詳しくはセクション17.2.2「レプリケーションチャネル」をご覧ください。

RESET REPLICA | SLAVE では、ソースホスト名とポート、レプリケーションユーザーアカウントとそのパスワード、PRIVILEGE_CHECKS_USER アカウント、REQUIRE_ROW_FORMAT オプション、REQUIRE_TABLE_PRIMARY_KEY_CHECK オプション、ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS オプションなどのレプリケーション接続パラメータは変更されません。 レプリケーション接続パラメータを変更する場合は、サーバーの起動後に CHANGE REPLICATION SOURCE TO ステートメント (MySQL 8.0.23 の場合) または CHANGE MASTER TO ステートメント (MySQL 8.0.23 の場合) を使用します。 すべてのレプリケーション接続パラメータを削除する場合は、RESET REPLICA | SLAVE ALL を使用します。 RESET REPLICA | SLAVE ALL では、CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO によって設定された IGNORE_SERVER_IDS リストもクリアされます。 RESET REPLICA | SLAVE ALL を使用している場合、インスタンスをレプリカとして再度使用するには、サーバーの起動後に CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO ステートメントを発行して、新しい接続パラメータを指定する必要があります。

RESET REPLICA | SLAVE を発行した後、START REPLICA | SLAVE を発行する前に予期しないサーバーの終了または意図的な再起動が発生した場合、レプリケーション接続パラメータの保存は、レプリケーションメタデータに使用されるリポジトリによって異なります:

• master_info_repository=TABLE および relay_log_info_repository=TABLE がサーバーに設定されている場合 (MySQL 8.0 からのデフォルト設定)、レプリケーション接続パラメータは、InnoDB テーブル mysql.slave_master_info および mysql.slave_relay_log_info のクラッシュセーフ RESET REPLICA | SLAVE 操作の一部として保持されます。 これらはメモリーにも保持されます。 RESET REPLICA | SLAVE の発行後、START REPLICA | SLAVE の発行前に予期しないサーバーの終了または意図的な再起動が発生した場合、レプリケーション接続パラメータがテーブルから取得され、チャネルに再適用されます。 この状況は、接続メタデータリポジトリの場合は MySQL 8.0.13 から、アプライヤメタデータリポジトリの場合は MySQL 8.0.19 から適用されます。

• MySQL 8.0 から非推奨になった master_info_repository=FILE および relay_log_info_repository=FILE がサーバーに設定されている場合、または MySQL Server リリースが前述のリリースより前の場合、レプリケーション接続パラメータはメモリーにのみ保持されます。 予期しないサーバーの終了または故意の再起動が原因で、RESET REPLICA | SLAVE の発行直後にレプリカ mysqld が再起動された場合、接続パラメータは失われます。 その場合は、START REPLICA | SLAVE を発行する前に、サーバーが接続パラメータの再指定を開始した後で、(MySQL 8.0.23 から) CHANGE REPLICATION SOURCE TO ステートメントまたは CHANGE MASTER TO ステートメントを発行する必要があります。

RESET REPLICA | SLAVE では、ステートメントの影響を受けるチャネルのレプリケーションフィルタ設定 (--replicate-ignore-table など) は変更されません。 ただし、RESET REPLICA | SLAVE ALL では、ステートメントによって削除されたチャネルに設定されたレプリケーションフィルタが削除されます。 削除されたチャネルが再作成されると、レプリカに指定されたグローバルレプリケーションフィルタがそれらにコピーされ、チャネル固有のレプリケーションフィルタは適用されません。 詳細は、セクション17.2.5.4「レプリケーションチャネルベースのフィルタ」 を参照してください。

RESET REPLICA | SLAVE では、進行中のトランザクションが暗黙的にコミットされます。 セクション13.3.3「暗黙的なコミットを発生させるステートメント」を参照してください。

レプリケーション SQL スレッドが停止時に一時テーブルのレプリケート中で、RESET REPLICA | SLAVE が発行された場合、レプリケートされた一時テーブルはレプリカで削除されます。

RESET REPLICA | SLAVE はハートビート期間または SSL_VERIFY_SERVER_CERT をリセットしません。

注記

NDB Cluster レプリカ SQL ノードで使用すると、RESET REPLICA | SLAVE は mysql.ndb_apply_status テーブルをクリアします。 このステートメントを使用する場合、ndb_apply_status は NDB ストレージエンジンを使用するため、クラスタに接続されているすべての SQL ノードによって共有されることに注意してください。

この動作をオーバーライドするには、RESET REPLICA | SLAVE を実行する前に SET GLOBAL @@ ndb_clear_apply_status=OFF を発行します。このような場合、レプリカは ndb_apply_status テーブルをパージしません。