START {REPLICA | SLAVE} [thread_types] [until_option] [connection_options] [channel_option]

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

thread_type:
    IO_THREAD | SQL_THREAD

until_option:
    UNTIL {   {SQL_BEFORE_GTIDS | SQL_AFTER_GTIDS} = gtid_set
          |   MASTER_LOG_FILE = 'log_name', MASTER_LOG_POS = log_pos
          |   SOURCE_LOG_FILE = 'log_name', SOURCE_LOG_POS = log_pos
          |   RELAY_LOG_FILE = 'log_name', RELAY_LOG_POS = log_pos
          |   SQL_AFTER_MTS_GAPS  }

connection_options:
    [USER='user_name'] [PASSWORD='user_pass'] [DEFAULT_AUTH='plugin_name'] [PLUGIN_DIR='plugin_dir']


channel_option:
    FOR CHANNEL channel

gtid_set:
    uuid_set [, uuid_set] ...
    | ''

uuid_set:
    uuid:interval[:interval]...

uuid:
    hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhh

h:
    [0-9,A-F]

interval:
    n[-n]

    (n >= 1)

START REPLICA | SLAVE は、レプリケーションスレッドの一方または両方を起動します。 MySQL 8.0.22 から、START SLAVE のかわりに START REPLICA を使用します。これは、そのリリースから非推奨になりました。 MySQL 8.0.22 より前のリリースでは、START SLAVE を使用します。

thread_type オプションを指定しない START REPLICA | SLAVE は、両方のレプリケーションスレッドを起動します。 レプリケーション I/O スレッドは、ソースサーバーからイベントを読み取り、リレーログに格納します。 レプリケーション SQL スレッドは、リレーログからイベントを読み取り、それらを実行します。 START REPLICA | SLAVE には、REPLICATION_SLAVE_ADMIN 権限 (または非推奨の SUPER 権限) が必要です。

START REPLICA | SLAVE がレプリケーションスレッドの起動に成功すると、エラーなしで返されます。 ただし、その場合でも、レプリケーションスレッドが起動してから後で停止する可能性があります (たとえば、ソースへの接続やバイナリログの読取りなどの問題が管理されないため)。 START REPLICA | SLAVE では、これについての警告は表示されません。 レプリカエラーログでレプリケーションスレッドによって生成されたエラーメッセージを確認するか、SHOW REPLICA | SLAVE STATUS で正常に実行されていることを確認する必要があります。

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

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

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

どちらのスレッドを開始するかを指定するために、このステートメントに IO_THREAD および SQL_THREAD オプションを追加できます。 Group Replication applier チャネル (group_replication_applier) には I/O スレッドがなく、SQL スレッドのみがあることに注意してください。 このチャネルの起動時に IO_THREAD または SQL_THREAD オプションを指定しても利点はありません。

START REPLICA | SLAVE では、次のリストに示すように、USER, PASSWORD, DEFAULT_AUTH および PLUGIN_DIR オプションを使用したプラガブルユーザーパスワード認証がサポートされます:

IO_THREAD オプションも指定されていないかぎり、USER, PASSWORD, DEFAULT_AUTH または PLUGIN_DIR のいずれかを指定する場合は、SQL_THREAD オプションを使用できません。

詳細は、セクション6.2.17「プラガブル認証」を参照してください。

これらのいずれかのオプションとともにセキュアでない接続が使用されている場合、サーバーは次の警告を発行します: Sending passwords in plain text without SSL/TLS is extremely insecure

START REPLICA | SLAVE ... UNTIL では、グローバルトランザクション識別子 (GTID) で使用するための追加オプションが 2 つサポートされています (セクション17.1.3「グローバルトランザクション識別子を使用したレプリケーション」 を参照)。 これらの各オプションは、引数として 1 つ以上のグローバルトランザクション識別子のセット gtid_set を受け取ります (詳細は、GTID セットを参照してください)。

thread_type が指定されていない場合、START REPLICA | SLAVE UNTIL SQL_BEFORE_GTIDS は GTID が gtid_set にリストされている first トランザクションに到達するまで、レプリケーション SQL スレッドにトランザクションを処理させます。 START REPLICA | SLAVE UNTIL SQL_AFTER_GTIDS では、gtid_set の last トランザクションが両方のスレッドによって処理されるまで、レプリケーションスレッドがすべてのトランザクションを処理します。 つまり、START REPLICA | SLAVE UNTIL SQL_BEFORE_GTIDS は、レプリケーション SQL スレッドが gtid_set の最初の GTID に到達する前に発生したすべてのトランザクションを処理し、START REPLICA | SLAVE UNTIL SQL_AFTER_GTIDS は GTID がセットに含まれていないトランザクションが検出されるまで、レプリケーションスレッドがすべてのトランザクション (GTID が gtid_set で見つかったトランザクションを含む) を処理します。 SQL_BEFORE_GTIDS と SQL_AFTER_GTIDS はそれぞれ、SQL_THREAD および IO_THREAD オプションをサポートしますが、IO_THREAD を一緒に使用しても現在は何の効果もありません。

たとえば、START REPLICA | SLAVE SQL_THREAD UNTIL SQL_BEFORE_GTIDS = 3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56 では、順序番号 11 のトランザクションが見つかるまで、server_uuid が 3E11FA47-71CA-11E1-9E33-C80AA9429562 であるソースから発生したすべてのトランザクションがレプリケーション SQL スレッドによって処理され、このトランザクションは処理されずに停止されます。 つまり、シーケンス番号 10 を持つトランザクションまでのすべてのトランザクションが処理されます。 一方、START REPLICA | SLAVE SQL_THREAD UNTIL SQL_AFTER_GTIDS = 3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56 を実行すると、レプリケーション SQL スレッドは、順序番号 11 から 56 を持つすべてのトランザクションを含め、ソースから指定されたすべてのトランザクションを取得し、追加のトランザクションを処理せずに停止します。つまり、順序番号 56 を持つトランザクションは、レプリケーション SQL スレッドによって最後にフェッチされたトランザクションになります。

マルチスレッドレプリカを使用する場合 slave_preserve_commit_order=0 が設定されていると、次の場合にリレーログから実行された一連のトランザクションにギャップが生じる可能性があります:

マルチスレッドレプリカワーカースレッドをリレーログにギャップがなくなるまでのみ実行してから停止するには、START REPLICA | SLAVE UNTIL SQL_AFTER_MTS_GAPS ステートメントを使用します。 このステートメントは SQL_THREAD オプションを受け取ることができますが、ステートメントの効果は変更されないままです。 レプリケーション I/O スレッドには影響しません (IO_THREAD オプションとともに使用することはできません)。

リレーログから実行されるトランザクションのシーケンスにギャップがあるマルチスレッドレプリカで START REPLICA | SLAVE を発行すると、警告が生成されます。 このような状況で解決するには、START REPLICA | SLAVE UNTIL SQL_AFTER_MTS_GAPS を使用してから、RESET REPLICA | SLAVE を発行して残りのリレーログを削除します。 詳しくはセクション17.5.1.34「レプリケーションとトランザクションの非一貫性」をご覧ください。

失敗したマルチスレッドレプリカをシングルスレッドモードに変更するには、次に示す順序で次の一連のステートメントを発行します:

START {REPLICA | SLAVE} UNTIL SQL_AFTER_MTS_GAPS;

SET @@GLOBAL.slave_parallel_workers = 0;

START {REPLICA | SLAVE} SQL_THREAD;

レプリケーション I/O スレッドとレプリケーション SQL スレッドの両方が起動した後、START REPLICA | SLAVE はユーザーに確認を送信します。 ただし、レプリケーション I/O スレッドがまだ接続されていない可能性があります。 このため、START REPLICA | SLAVE が成功すると SHOW REPLICA | SLAVE STATUS に Replica_SQL_Running=Yes が表示されますが、Replica_IO_Running=Yes は保証されません (I/O スレッドがおよび接続済を実行している場合のみ Replica_IO_Running=Yes であるため)。 詳細は、セクション13.7.7.35「SHOW REPLICA | SLAVE STATUS ステートメント」およびセクション17.1.7.1「レプリケーションステータスの確認」を参照してください。

レプリケーション SQL スレッドがソースバイナリログまたはレプリカリレーログ内の特定のポイントに到達するまでレプリカを起動して実行するように指定するために、UNTIL 句 (前述の文法では until_option) を追加できます。 次のいずれかのオプションのペアを使用して、位置を指定します:

圧縮トランザクションペイロードの場合、位置は圧縮された Transaction_payload_event に基づいている必要があります。 SQL スレッドは、指定されたポイントに達すると停止します。 このステートメントで SQL_THREAD オプションが指定されている場合、このオプションは SQL スレッドのみを開始します。 それ以外の場合は、両方のレプリケーションスレッドを起動します。 SQL スレッドが実行中である場合、UNTIL 句は無視され、警告が発行されます。 UNTIL 句を IO_THREAD オプションとともに使用することはできません。

このセクションで前述したように、START REPLICA | SLAVE UNTIL では、SQL_BEFORE_GTIDS または SQL_AFTER_GTIDS のいずれかのオプションを使用して、特定の GTID または GTID のセットに対して相対的な停止ポイントを指定することもできます。 これらのオプションのいずれかを使用している場合は、SQL_THREAD または IO_THREAD、あるいはこれらの両方を指定できます。また、どちらも指定しないことも可能です。 SQL_THREAD のみを指定した場合、レプリケーション SQL スレッドのみがステートメントの影響を受けます。IO_THREAD のみを使用した場合、レプリケーション I/O スレッドのみが影響を受けます。 SQL_THREAD と IO_THREAD の両方が使用されている場合、またはそのどちらも使用されていない場合は、SQL スレッドと I/O スレッドの両方がこのステートメントの影響を受けます。

UNTIL 句では、次のいずれかを指定する必要があります。

ソースとリレーログオプションを混在させないでください。 ログファイルオプションと GTID オプションを混在させないでください。

UNTIL 句は、SQL_AFTER_MTS_GAPS も使用している場合を除き、マルチスレッドレプリカではサポートされません。 UNTIL が SQL_AFTER_MTS_GAPS のないマルチスレッドレプリカで使用されている場合、レプリカは、UNTIL 句で指定されたポイントに達するまで、レプリケーションのためにシングルスレッド (順次) モードで動作します。

UNTIL 条件は、後続の STOP REPLICA | SLAVE ステートメント、UNTIL 句を含まない START REPLICA | SLAVE ステートメント、またはサーバーの再起動によってリセットされます。

ログファイルと位置を指定する場合、このステートメントの影響を受けるのは SQL スレッドのみですが、START REPLICA | SLAVE ... UNTIL で IO_THREAD オプションを使用できます。 このような場合、IO_THREAD オプションは無視されます。 GTID オプション (SQL_BEFORE_GTIDS および SQL_AFTER_GTIDS) のいずれかを使用する場合、前述の制限は適用されません。GTID オプションでは、このセクションで前述した SQL_THREAD と IO_THREAD の両方がサポートされます。

UNTIL 句は、レプリケーションをデバッグしたり、レプリカがイベントをレプリケートしないようにする直前までレプリケーションを続行させる場合に役立ちます。 たとえば、ソースで無関係な DROP TABLE ステートメントが実行された場合、UNTIL を使用してレプリカにその時点まで実行するが、それ以上実行しないように指示できます。 イベントの内容を確認するには、ソースバイナリログまたはレプリカリレーログとともに mysqlbinlog を使用するか、SHOW BINLOG EVENTS ステートメントを使用します。

UNTIL を使用してレプリカプロセスのレプリケートされたクエリーをセクションに含める場合は、レプリカサーバーの起動時に SQL スレッドが実行されないように、--skip-slave-start オプションを指定してレプリカを起動することをお薦めします。 このオプションはおそらく、予期しないサーバーの再起動によって忘れてしまうことがないように、コマンド行ではなく、オプションファイルで使用することが最善です。

SHOW REPLICA | SLAVE STATUS ステートメントには、UNTIL 条件の現在の値を表示する出力フィールドが含まれます。