STOP {REPLICA | SLAVE} [thread_types] [channel_option]

thread_types:
    [thread_type [, thread_type] ... ]

thread_type: IO_THREAD | SQL_THREAD

channel_option:
    FOR CHANNEL channel

レプリケーションスレッドを停止します。 MySQL 8.0.22 から、STOP SLAVE のかわりに STOP REPLICA を使用します。これは非推奨になりました。 MySQL 8.0.22 より前のリリースでは、STOP SLAVE を使用します。

STOP REPLICA | SLAVE には、REPLICATION_SLAVE_ADMIN 権限 (または非推奨の SUPER 権限) が必要です。 推奨されるベストプラクティスは、レプリカサーバーを停止する前にレプリカで STOP REPLICA | SLAVE を実行することです (詳細は、セクション5.1.19「サーバーの停止プロセス」 を参照してください)。

START REPLICA | SLAVE と同様に、このステートメントを IO_THREAD および SQL_THREAD オプションとともに使用して、停止するレプリケーションスレッドの名前を指定できます。 グループレプリケーションアプライヤチャネル (group_replication_applier) にはレプリケーション I/O スレッドがなく、レプリケーション SQL スレッドのみがあることに注意してください。 したがって、SQL_THREAD オプションを使用すると、このチャネルは完全に停止します。

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

このステートメントを発行する前に、gtid_next を AUTOMATIC に設定する必要があります。

rpl_stop_slave_timeout システム変数を設定することで、STOP REPLICA | SLAVE がタイムアウトするまでの待機時間を制御できます。 これを使用すると、レプリカへの異なるクライアント接続を使用する STOP REPLICA | SLAVE と他の SQL ステートメントの間のデッドロックを回避できます。 タイムアウト値に達すると、発行元クライアントはエラーメッセージを返して待機を停止しますが、STOP REPLICA | SLAVE 命令は有効なままです。 レプリケーションスレッドがビジー状態でなくなると、STOP REPLICA | SLAVE ステートメントが実行され、レプリカが停止します。

一部の CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO ステートメントは、レプリケーションスレッドの状態に応じて、レプリカの実行中に許可されます。 ただし、このような場合、CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO ステートメントを実行する前の STOP REPLICA | SLAVE の使用は引き続きサポートされています。 詳細は、セクション13.4.2.3「CHANGE REPLICATION SOURCE TO ステートメント」、セクション13.4.2.1「CHANGE MASTER TO ステートメント」 および セクション17.4.8「フェイルオーバー中のソースの切替え」 を参照してください。

オプションの FOR CHANNEL channel 句を使用すると、ステートメントが適用されるレプリケーションチャネルの名前を指定できます。 FOR CHANNEL channel 句を指定すると、STOP REPLICA | SLAVE ステートメントが特定のレプリケーションチャネルに適用されます。 チャネルが指定されておらず、追加のチャネルが存在しない場合、ステートメントはデフォルトチャネルに適用されます。 複数のチャネルを使用しているときに STOP REPLICA | SLAVE ステートメントがチャネルを指定しない場合、このステートメントはすべてのチャネルの指定されたスレッドを停止します。 このステートメントは、group_replication_recovery チャネルでは使用できません。 詳しくはセクション17.2.2「レプリケーションチャネル」をご覧ください。

レプリカがマルチスレッド化されている場合 (slave_parallel_workers はゼロ以外の値)、リレーログから実行された一連のトランザクションのギャップはワーカースレッドの停止の一環として閉じられます。 STOP REPLICA | SLAVE ステートメントの実行中にレプリカが予期せず (ワーカースレッドのエラーや KILL を発行する別のスレッドが原因など) 停止した場合、リレーログから実行されたトランザクションの順序に一貫性がなくなる可能性があります。 詳しくはセクション17.5.1.34「レプリケーションとトランザクションの非一貫性」,をご覧ください。

ソースが行ベースのバイナリロギング形式を使用している場合、非トランザクションストレージエンジンを使用するテーブルをレプリケートするときは、レプリカサーバーをシャットダウンする前に、レプリカで STOP REPLICA | SLAVE または STOP REPLICA | SLAVE SQL_THREAD を実行するようにしてください。 現在のレプリケーションイベントグループが 1 つ以上の非トランザクションテーブルを変更した場合、レプリケーション SQL スレッドに対して KILL QUERY または KILL CONNECTION ステートメントを発行しないかぎり、STOP REPLICA | SLAVE はイベントグループが完了するまで最大 60 秒待機します。 タイムアウト後もイベントグループが不完全なままである場合は、エラーメッセージが記録されます。

ソースがステートメントベースのバイナリロギング形式を使用している場合、開いている一時テーブルがある間にソースを変更することは安全でない可能性があります。 これは、一時テーブルのステートメントベースレプリケーションが推奨されない理由の 1 つです。 レプリカに一時テーブルがあるかどうかは、Slave_open_temp_tables の値で確認できます。ステートメントベースレプリケーションを使用する場合は、CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO を実行する前にこの値を 0 にする必要があります。 レプリカで開いている一時テーブルがある場合、STOP REPLICA | SLAVE の発行後に CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO ステートメントを発行すると、ER_WARN_OPEN_TEMP_TABLES_MUST_BE_ZERO 警告が表示されます。