13.4.2.5 START SLAVE 構文

START SLAVE [thread_types] [until_option] [connection_options]

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
          |   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']


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)

thread_type オプションのない START SLAVE は、両方のスレーブスレッドを開始します。I/O スレッドはマスターサーバーからのイベントを読み取り、それをリレーログ内に格納します。SQL スレッドはリレーログからのイベントを読み取り、それを実行します。START SLAVE には、SUPER 権限が必要です。

START SLAVE は、スレーブスレッドの開始に成功すると、エラーなしで復帰します。ただし、その場合でも、それらのスレーブスレッドは開始したあとに (たとえば、マスターに接続できない、そのバイナリログを読み取れない、またはその他の何らかの問題のために) 停止する可能性があります。START SLAVE では、これについての警告が発生されません。スレーブのエラーログでスレーブスレッドによって生成されたエラーメッセージをチェックするか、または SHOW SLAVE STATUS を使用してスレーブスレッドが正常に実行されていることをチェックする必要があります。

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

MySQL 5.6.11 からは、このステートメントを発行する前に、gtid_next を AUTOMATIC に設定する必要があります (Bug #16062608)。

MySQL 5.6.4 以降では、次のリストで説明されているように、START SLAVE を USER、PASSWORD、DEFAULT_AUTH および PLUGIN_DIR オプションとともに使用したプラガブルなユーザーパスワード認証がサポートされます。

• USER: ユーザー名。PASSWORD が使用されている場合は、空または NULL 文字列に設定したり、未設定のままにしたりすることはできません。

• PASSWORD: パスワード。

• DEFAULT_AUTH: プラグインの名前。デフォルトは MySQL ネイティブ認証です。

• PLUGIN_DIR: プラグインの場所。

MySQL 5.6.4 からは、USER、PASSWORD、DEFAULT_AUTH、PLUGIN_DIR のいずれかを指定するときは、IO_THREAD オプションも同時に指定されていないかぎり、SQL_THREAD オプションを使用できません (Bug #13083642)。

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

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

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

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

たとえば、START SLAVE SQL_THREAD UNTIL SQL_BEFORE_GTIDS = 3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56 を指定すると、スレーブ SQL スレッドはシーケンス番号 11 を持つトランザクションを見つけるまで、server_uuid が 3E11FA47-71CA-11E1-9E33-C80AA9429562 であるマスターから発信されているすべてのトランザクションを処理したあと、このトランザクションを処理することなく停止します。つまり、シーケンス番号 10 を持つトランザクションまでのすべてのトランザクションが処理されます。これに対して、START SLAVE SQL_THREAD UNTIL SQL_AFTER_GTIDS = 3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56 を実行すると、スレーブ SQL スレッドは 11 から 56 までのシーケンス番号を持つすべてのトランザクションを含む、マスターから今指定されたすべてのトランザクションを取得したあと、追加のどのトランザクションも処理することなく停止します。つまり、シーケンス番号 56 を持つトランザクションは、スレーブ SQL スレッドによってフェッチされた最後のトランザクションになります。

MySQL 5.6.14 より前は、示されたトランザクションが完了しても SQL_AFTER_GTIDS はスレーブを停止せず、別の GTID イベントが受信されるまで待機しました (Bug #14767986)。

注記

SQL_BEFORE_GTIDS および SQL_AFTER_GTIDS キーワードは MySQL 5.6.5 サーバー内に存在します。ただし、そのどちらのキーワードも、そのバージョンでは START SLAVE [SQL_THREAD | IO_THREAD] UNTIL のオプションとして正しく機能せず、サポートされたのは MySQL 5.6.6 からのみでした。(Bug#13810456)

START SLAVE UNTIL SQL_AFTER_MTS_GAPS は、MySQL 5.6.6 以降で使用できます。このステートメントを発行すると、マルチスレッドスレーブの SQL スレッドはリレーログ内にそれ以上ギャップが見つからなくなるまで実行してから、停止します。このステートメントは SQL_THREAD オプションを受け取ることができますが、ステートメントの効果は変更されないままです。スレーブ I/O スレッドには影響を与えません (また、IO_THREAD オプションとともに使用することはできません)。START SLAVE UNTIL SQL_AFTER_MTS_GAPS は、スレーブがマルチスレッドモードでエラーで失敗したあと、そのスレーブをマルチスレッドモードからシングルスレッドモードに切り替える前に (つまり、slave_parallel_workers を 0 以外の正の値から元の 0 にリセットするときに) 使用するようにしてください。

失敗したマルチスレッドスレーブをシングルスレッドモードに変更するには、次の一連のステートメントを示されている順序で発行できます。

START SLAVE UNTIL SQL_AFTER_MTS_GAPS;

SET @@GLOBAL.slave_parallel_workers = 0;

START SLAVE SQL_THREAD;

失敗したマルチスレッドスレーブを relay_log_recovery が有効になった状態で実行していた場合は、START SLAVE UNTIL SQL_AFTER_MTS_GAPS を発行してから CHANGE MASTER TO を実行する必要があります。そうしないと、後者のステートメントが失敗します。

注記

実行中の START SLAVE ... ステートメントのテキスト全体 (使用された USER または PASSWORD 値を含む) を SHOW PROCESSLIST の出力で表示できます。これはまた、実行中の CHANGE MASTER TO ステートメントのテキスト (MASTER_USER または MASTER_PASSWORD に使用されたすべての値を含む) にも当てはまります。

START SLAVE は、I/O スレッドと SQL スレッドの両方が開始されたあと、ユーザーに肯定応答を送信します。ただし、I/O スレッドはまだ接続していない可能性があります。このため、正常な START SLAVE により SHOW SLAVE STATUS は Slave_SQL_Running=Yes を示しますが、これによって Slave_IO_Running=Yes が保証されるわけではありません (Slave_IO_Running=Yes は I/O スレッドが実行中でかつ接続されている場合だけであるため)。詳細は、セクション13.7.5.35「SHOW SLAVE STATUS 構文」およびセクション17.1.5.1「レプリケーションステータスの確認」を参照してください。

どちらのスレッドを開始するかを指定するために、このステートメントに IO_THREAD および SQL_THREAD オプションを追加できます。MySQL 5.6.4 以降では、USER、PASSWORD、DEFAULT_AUTH、PLUGIN_DIR のいずれかを指定するときは、IO_THREAD オプションも同時に指定されていないかぎり、SQL_THREAD オプションが許可されません (Bug #13083642)。

UNTIL 句 (前の文法では until_option) を追加することにより、スレーブを起動し、SQL スレッドが MASTER_LOG_POS および MASTER_LOG_FILE オプションで指定されているマスターバイナリログ内の特定のポイント、または RELAY_LOG_POS および RELAY_LOG_FILE オプションで示されているスレーブリレーログ内の特定のポイントに達するまで実行するように指定できます。SQL スレッドは、指定されたポイントに達すると停止します。このステートメントで SQL_THREAD オプションが指定されている場合、このオプションは SQL スレッドのみを開始します。それ以外の場合は、両方のスレーブスレッドを開始します。SQL スレッドが実行中である場合、UNTIL 句は無視され、警告が発行されます。UNTIL 句を IO_THREAD オプションとともに使用することはできません。

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

UNTIL 句は、SQL_AFTER_MTS_GAPS も同時に使用している場合を除き、マルチスレッドスレーブではサポートされません。MySQL 5.6.6 より前は、UNTIL はマルチスレッドスレーブではまったくサポートされていませんでした。

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

• ログファイル名とそのファイル内の位置の両方

• (MySQL 5.6.6 以降:) SQL_BEFORE_GTIDS または SQL_AFTER_GTIDS のいずれか

• (MySQL 5.6.6 以降:) SQL_AFTER_MTS_GAPS

マスターとリレーログのオプションを混在させないでください。MySQL 5.6.6 以降では、ログファイルのオプションを GTID オプションと混在させないでください。

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

ログファイルと位置を指定する場合は、SQL スレッドのみがこのステートメントの影響を受けるにもかかわらず、START SLAVE ... UNTIL で IO_THREAD オプションを使用できます。このような場合、IO_THREAD オプションは無視されます。前の制限は、MySQL 5.6.6 で導入された 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 SLAVE STATUS ステートメントには、UNTIL 条件の現在の値を表示する出力フィールドが含まれています。

非常に古いバージョンの MySQL (4.0.5 より前) では、このステートメントは SLAVE START と呼ばれていました。その構文は、MySQL 5.6.1 の時点で受け入れられなくなりました。