MySQL :: MySQL 8.0 リファレンスマニュアル :: 13.4.2.1 CHANGE MASTER TO ステートメント

8.0 English
5.7 English

MySQL 8.0 リファレンスマニュアル / ... / CHANGE MASTER TO ステートメント

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

13.4.2.1 CHANGE MASTER TO ステートメント

CHANGE MASTER TO option [, option] ... [ channel_option ]

option: {
    MASTER_BIND = 'interface_name'
  | MASTER_HOST = 'host_name'
  | MASTER_USER = 'user_name'
  | MASTER_PASSWORD = 'password'
  | MASTER_PORT = port_num
  | PRIVILEGE_CHECKS_USER = {'account' | NULL}
  | REQUIRE_ROW_FORMAT = {0|1}
  | REQUIRE_TABLE_PRIMARY_KEY_CHECK = {STREAM | ON | OFF}
  | ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS = {OFF | LOCAL | uuid}
  | MASTER_LOG_FILE = 'source_log_name'
  | MASTER_LOG_POS = source_log_pos
  | MASTER_AUTO_POSITION = {0|1}
  | RELAY_LOG_FILE = 'relay_log_name'
  | RELAY_LOG_POS = relay_log_pos
  | MASTER_HEARTBEAT_PERIOD = interval
  | MASTER_CONNECT_RETRY = interval
  | MASTER_RETRY_COUNT = count
  | SOURCE_CONNECTION_AUTO_FAILOVER = {0|1}
  | MASTER_DELAY = interval
  | MASTER_COMPRESSION_ALGORITHMS = 'value'
  | MASTER_ZSTD_COMPRESSION_LEVEL = level
  | MASTER_SSL = {0|1}
  | MASTER_SSL_CA = 'ca_file_name'
  | MASTER_SSL_CAPATH = 'ca_directory_name'
  | MASTER_SSL_CERT = 'cert_file_name'
  | MASTER_SSL_CRL = 'crl_file_name'
  | MASTER_SSL_CRLPATH = 'crl_directory_name'
  | MASTER_SSL_KEY = 'key_file_name'
  | MASTER_SSL_CIPHER = 'cipher_list'
  | MASTER_SSL_VERIFY_SERVER_CERT = {0|1}
  | MASTER_TLS_VERSION = 'protocol_list'
  | MASTER_TLS_CIPHERSUITES = 'ciphersuite_list'
  | MASTER_PUBLIC_KEY_PATH = 'key_file_name'
  | GET_MASTER_PUBLIC_KEY = {0|1}
  | NETWORK_NAMESPACE = 'namespace'
  | IGNORE_SERVER_IDS = (server_id_list)
}

channel_option:
    FOR CHANNEL channel

server_id_list:
    [server_id [, server_id] ... ]

CHANGE MASTER TO は、レプリカサーバーがソースへの接続およびソースからのデータの読取りに使用するパラメータを変更します。また、レプリケーションメタデータリポジトリの内容も更新されます (セクション17.2.4「リレーログおよびレプリケーションメタデータリポジトリ」を参照)。 MySQL 8.0.23 から、CHANGE MASTER TO のかわりに CHANGE REPLICATION SOURCE TO を使用します。これは、そのリリースから非推奨になりました。 MySQL 8.0.23 より前のリリースでは、CHANGE MASTER TO を使用します。

レプリケーション SQL スレッドおよびレプリケーション I/O スレッドの状態に応じて、最初に停止せずに、実行中のレプリカに対して CHANGE MASTER TO ステートメントを発行できます。このような使用を制御するルールは、このセクションの後半で説明します。 CHANGE MASTER TO には、REPLICATION_SLAVE_ADMIN 権限 (または非推奨の SUPER 権限) が必要です。

マルチスレッドのレプリカを使用する場合 (つまり、slave_parallel_workers が 0 より大きい場合)、レプリカを停止すると、レプリカが意図的に停止されたかどうかに関係なく、リレーログから実行された一連のトランザクションで「「ギャップ」」が発生する可能性があります。このようなギャップが存在する場合、CHANGE MASTER TO の発行は失敗します。この状況の解決策は、ギャップを確実に閉じる START REPLICA | SLAVE UNTIL SQL_AFTER_MTS_GAPS を発行することです。

オプションの FOR CHANNEL channel 句を使用すると、ステートメントが適用されるレプリケーションチャネルの名前を指定できます。 FOR CHANNEL channel 句を指定すると、CHANGE MASTER TO ステートメントが特定のレプリケーションチャネルに適用され、新しいチャネルの追加または既存のチャネルの変更に使用されます。たとえば、channel2 という新しいチャネルを追加するには、次のようにします:

CHANGE MASTER TO MASTER_HOST=host1, MASTER_PORT=3002 FOR CHANNEL 'channel2'

句が指定されておらず、追加のチャネルが存在しない場合、ステートメントはデフォルトチャネルに適用されます。

複数のレプリケーションチャネルを使用する場合、CHANGE MASTER TO ステートメントで FOR CHANNEL channel 句を使用してチャネルを指定しないと、エラーが発生します。詳しくはセクション17.2.2「レプリケーションチャネル」をご覧ください。

MASTER_HOST およびその他の CHANGE MASTER TO オプションに使用される値では、改行 (\n または 0x0A) 文字がチェックされます。このような文字がこれらの値に存在すると、ER_MASTER_INFO でステートメントが失敗します。

CHANGE MASTER TO を起動すると、MASTER_HOST, MASTER_PORT, MASTER_LOG_FILE および MASTER_LOG_POS の以前の値が、実行前のレプリカ状態に関するその他の情報とともにエラーログに書き込まれます。

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

CHANGE MASTER TO ステートメントの一部のオプションでは、CHANGE MASTER TO ステートメント (およびその後の START REPLICA | SLAVE ステートメント) を発行する前に、STOP REPLICA | SLAVE ステートメントを発行する必要があります。場合によっては、レプリケーション SQL スレッドまたはレプリケーション I/O スレッドのどちらか一方のみを停止する必要があります:

SQL スレッドが停止すると、レプリケーション I/O スレッドが実行されている場合でも、RELAY_LOG_FILE、RELAY_LOG_POS および MASTER_DELAY オプションの任意の組合せを使用して CHANGE MASTER TO を実行できます。 I/O スレッドの実行中は、このステートメントでほかのオプションを使用できません。
I/O スレッドが停止すると、SQL スレッドが実行されている場合でも、このステートメント (任意の組合せで) except RELAY_LOG_FILE, RELAY_LOG_POS, MASTER_DELAY または MASTER_AUTO_POSITION = 1 のオプションを使用して CHANGE MASTER TO を実行できます。
MASTER_AUTO_POSITION = 1 または ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS を使用する CHANGE MASTER TO ステートメントを発行する前に、SQL スレッドと I/O スレッドの両方を停止する必要があります。

SHOW REPLICA | SLAVE STATUS を使用して、レプリケーション SQL スレッドおよびレプリケーション I/O スレッドの現在の状態を確認できます。 Group Replication applier チャネル (group_replication_applier) には I/O スレッドがなく、SQL スレッドのみがあることに注意してください。

詳細は、セクション17.4.8「フェイルオーバー中のソースの切替え」を参照してください。

ステートメントベースレプリケーションおよび一時テーブルを使用している場合は、STOP REPLICA | SLAVE ステートメントのあとの CHANGE MASTER TO ステートメントがレプリカ上の一時テーブルの背後に残る可能性があります。これが発生するたびに警告 (ER_WARN_OPEN_TEMP_TABLES_MUST_BE_ZERO) が発行されるようになりました。このような場合は、このような CHANGE MASTER TO ステートメントを実行する前に、Slave_open_temp_tables システムステータス変数の値が 0 であることを確認することで回避できます。

CHANGE MASTER TO は、ソースのスナップショットがあり、スナップショットの時刻に対応するソースバイナリログ座標を記録している場合にレプリカを設定する際に役立ちます。スナップショットをレプリカにロードしてソースと同期した後、レプリカで CHANGE MASTER TO MASTER_LOG_FILE='log_name', MASTER_LOG_POS=log_pos を実行して、レプリカがソースバイナリログの読取りを開始する座標を指定できます。

次の例では、レプリカが使用するソースサーバーを変更し、レプリカが読取りを開始するソースバイナリログ座標を確立します:

CHANGE MASTER TO
  MASTER_HOST='source2.example.com',
  MASTER_USER='replication',
  MASTER_PASSWORD='password',
  MASTER_PORT=3306,
  MASTER_LOG_FILE='source2-bin.001',
  MASTER_LOG_POS=4,
  MASTER_CONNECT_RETRY=10;

次の例は、使用される頻度の低い操作を示しています。これは、なんらかの理由で再実行するリレーログファイルがレプリカに存在する場合に使用されます。これを行うには、ソースにアクセスできる必要はありません。 CHANGE MASTER TO のみを使用し、SQL スレッド (START REPLICA | SLAVE SQL_THREAD) を起動する必要があります:

CHANGE MASTER TO
  RELAY_LOG_FILE='replica-relay-bin.006',
  RELAY_LOG_POS=4025;

CHANGE MASTER TO ステートメントで指定しないオプションは、次の説明に示す場合を除き、その値を保持します。そのため、ほとんどの場合、変更されないオプションを指定する必要はありません。

ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS

レプリケーションチャネルが GTID を持たないレプリケートされたトランザクションに GTID を割り当て、GTID ベースのレプリケーションを使用しないソースから使用するレプリカへのレプリケーションを有効にします。マルチソースレプリカの場合、ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS を使用するチャネルと使用しないチャネルを混在させることができます。デフォルトは OFF で、この機能は使用されません。

LOCAL は、レプリカ独自の UUID (server_uuid 設定) を含む GTID を割り当てます。uuid は、レプリケーションソースサーバーの server_uuid 設定など、指定された UUID を含む GTID を割り当てます。非ローカル UUID を使用すると、レプリカで発生したトランザクションと、ソースで発生したトランザクション、およびマルチソースレプリカの場合は異なるソースで発生したトランザクションを区別できます。選択した UUID は、レプリカ自体での使用にのみ意味があります。ソースによって送信されたトランザクションのいずれかに GTID がすでにある場合、その GTID は保持されます。

Group Replication に固有のチャネルでは ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS を使用できませんが、Group Replication グループメンバーであるサーバーインスタンス上の別のソースの非同期レプリケーションチャネルでは使用できます。その場合、GTID を作成するための UUID として Group Replication グループ名を指定しないでください。

ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS を LOCAL または uuid に設定するには、レプリカに gtid_mode=ON が設定されている必要があり、後で変更することはできません。このオプションは、バイナリログファイルの位置ベースのレプリケーションを持つソースで使用されるため、チャネルに MASTER_AUTO_POSITION=1 を設定することはできません。このオプションを設定する前に、レプリケーション SQL スレッドとレプリケーション I/O スレッドの両方を停止する必要があります。

重要

フェイルオーバーが必要な場合、どのチャネルでも ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS を使用して設定されたレプリカを昇格させてレプリケーションサーバーを置き換えることはできず、レプリカから作成されたバックアップを使用してレプリケーションサーバーをリストアすることはできません。同じ制限が、任意のチャネルで ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS を使用する他のレプリカの置換またはリストアにも適用されます。

その他の制限および詳細は、セクション17.1.3.6「GTID のないソースから GTID のあるレプリカへのレプリケーション」を参照してください。

GET_MASTER_PUBLIC_KEY

ソースから公開キーをリクエストすることで、RSA キーペアベースのパスワード交換を有効にします。このオプションは、caching_sha2_password 認証プラグインで認証されるレプリカに適用されます。このプラグインを使用して認証されるアカウントによる接続の場合、ソースはリクエストされないかぎり公開キーを送信しないため、クライアントでリクエストまたは指定する必要があります。 MASTER_PUBLIC_KEY_PATH が指定され、有効な公開キーファイルが指定されている場合は、GET_MASTER_PUBLIC_KEY よりも優先されます。 caching_sha2_password プラグイン (MySQL 8.0 のデフォルト) で認証されるレプリケーションユーザーアカウントを使用していて、セキュアな接続を使用していない場合は、このオプションまたは MASTER_PUBLIC_KEY_PATH オプションを指定して、RSA 公開キーをレプリカに提供する必要があります。

IGNORE_SERVER_IDS

レプリカが指定されたサーバーから発生したイベントを無視するようにします。このオプションは、0 個以上のサーバー ID のコンマ区切りリストを取ります。サーバーからのログローテーションおよび削除イベントは無視されず、リレーログに記録されます。

循環レプリケーションでは、発信元のサーバーは通常、独自のイベントのターミネータとして機能するため、これらのイベントが複数回適用されることはありません。そのため、このオプションは、循環内のいずれかのサーバーが削除されたときの循環レプリケーションで役立ちます。 1、2、3、および 4 のサーバー ID を持つ 4 台のサーバーを含む循環レプリケーションセットアップが存在するとき、サーバー 3 に障害が発生したとします。サーバー 2 からサーバー 4 へのレプリケーションを開始してギャップを埋める場合、サーバー 4 で発行する CHANGE MASTER TO ステートメントに IGNORE_SERVER_IDS = (3) を含めて、サーバー 3 の代わりにサーバー 2 をソースとして使用するように指示できます。それにより、サーバー 4 は、使用されなくなっているサーバーで発信されたすべてのステートメントを無視し、伝播しなくなります。

IGNORE_SERVER_IDS にサーバーの独自の ID が含まれているときに、--replicate-same-server-id オプションが有効な状態でそのサーバーが起動された場合は、エラーが発生します。

注記

レプリケーションにグローバルトランザクション識別子 (GTID) が使用されている場合、すでに適用されているトランザクションは自動的に無視されるため、IGNORE_SERVER_IDS 関数は必須ではなく、非推奨です。サーバーに gtid_mode=ON が設定されている場合、CHANGE MASTER TO ステートメントに IGNORE_SERVER_IDS オプションを含めると、非推奨の警告が発行されます。

ソースメタデータリポジトリおよび SHOW REPLICA | SLAVE STATUS の出力では、現在無視されているサーバーのリストが提供されます。詳細は、セクション17.2.4.2「レプリケーションメタデータリポジトリ」およびセクション13.7.7.35「SHOW REPLICA | SLAVE STATUS ステートメント」を参照してください。

IGNORE_SERVER_IDS オプションを指定せずに CHANGE MASTER TO ステートメントを発行した場合、既存のリストは保持されます。無視されるサーバーのリストをクリアするには、このオプションを空のリストとともに使用する必要があります。

CHANGE MASTER TO IGNORE_SERVER_IDS = ();

RESET REPLICA | SLAVE ALL により、IGNORE_SERVER_IDS がクリアされます。

注記

IGNORE_SERVER_IDS で既存のサーバー ID が設定されているチャネルがある場合、SET GTID_MODE=ON が発行されると、非推奨の警告が発行されます。 GTID ベースのレプリケーションを開始する前に、関係するサーバー上の無視されたすべてのサーバー ID リストを確認してクリアします。無視された ID がある場合は、SHOW REPLICA | SLAVE STATUS ステートメントにリストが表示されます。非推奨の警告が表示された場合でも、空のリストを指定した IGNORE_SERVER_IDS オプションを含む CHANGE MASTER TO ステートメントを発行することで、gtid_mode=ON の設定後にリストをクリアできます。

MASTER_AUTO_POSITION

GTID ベースのレプリケーションを使用してレプリカがソースに接続しようとします。このオプションは、レプリケーション SQL スレッドとレプリケーション I/O スレッドの両方が停止している場合にのみ、CHANGE MASTER TO で使用できます。

レプリカとソースの両方で GTID が有効になっている必要があります (レプリカでは GTID_MODE=ON、ON_PERMISSIVE,または OFF_PERMISSIVE、ソースでは GTID_MODE=ON)。接続には自動配置が使用されるため、MASTER_LOG_FILE および MASTER_LOG_POS で表される座標は使用されず、これらのオプションのいずれかまたは両方を MASTER_AUTO_POSITION = 1 とともに使用するとエラーが発生します。レプリカでマルチソースレプリケーションが有効になっている場合は、適用可能なレプリケーションチャネルごとに MASTER_AUTO_POSITION = 1 オプションを設定する必要があります。

MASTER_AUTO_POSITION = 1 が設定されている場合、レプリカは初期接続ハンドシェイクで、すでに受信、コミット、またはその両方を行ったトランザクションを含む GTID セットを送信します。ソースは、GTID がレプリカによって送信される GTID セットに含まれていないバイナリログに記録されたすべてのトランザクションを送信することによって応答します。この交換により、レプリカがまだ記録またはコミットしていない GTID を持つトランザクションのみがソースから送信されるようになります。ダイヤモンドトポロジの場合と同様に、レプリカが複数のソースからトランザクションを受信する場合、自動スキップ機能によってトランザクションが 2 回適用されないようにします。レプリカによって送信される GTID セットの計算方法の詳細は、セクション17.1.3.3「GTID 自動配置」を参照してください。

ソースによって送信されるべきトランザクションのいずれかがソースバイナリログからパージされているか、別の方法で gtid_purged システム変数の GTID セットに追加されている場合、ソースはエラー ER_MASTER_HAS_PURGED_REQUIRED_GTIDS をレプリカに送信し、レプリケーションは開始しません。欠落しているパージ済トランザクションの GTID が識別され、警告メッセージ ER_FOUND_MISSING_GTIDS のソースエラーログにリストされます。また、トランザクションの交換中に、レプリカが GTID 内のソース UUID を持つトランザクションを記録またはコミットしたが、ソース自体がそれらをコミットしていないことが判明した場合、ソースはレプリカにエラー ER_SLAVE_HAS_MORE_GTIDS_THAN_MASTER を送信し、レプリケーションは開始しません。これらの状況の処理方法の詳細は、セクション17.1.3.3「GTID 自動配置」を参照してください。

レプリケーションが GTID 自動配置を有効にして実行されているかどうかを確認するには、パフォーマンススキーマの replication_connection_status テーブルまたは SHOW REPLICA | SLAVE STATUS の出力を確認します。 MASTER_AUTO_POSITION オプションを再度無効にすると、レプリカはファイルベースレプリケーションに戻ります。その場合は、MASTER_LOG_FILE または MASTER_LOG_POS オプションのいずれかまたは両方も指定する必要があります。

MASTER_BIND

複数のネットワークインタフェースを持つレプリカで使用するために、ソースへの接続に選択するレプリカネットワークインタフェースを決定します。このオプションで構成されたアドレスは、SHOW REPLICA | SLAVE STATUS からの出力の Master_Bind カラムに表示されます (存在する場合)。ソースメタデータリポジトリテーブル mysql.slave_master_info では、値は Master_bind カラムとして表示されます。レプリカを特定のネットワークインタフェースにバインドする機能は、NDB Cluster でもサポートされています。

MASTER_COMPRESSION_ALGORITHMS

レプリケーションソースサーバーへの接続に許可される圧縮アルゴリズムを指定します。使用可能なアルゴリズムは、protocol_compression_algorithms システム変数の場合と同じです。デフォルト値は uncompressed です。 MASTER_COMPRESSION_ALGORITHMS は、MySQL 8.0.18 の時点で使用可能です。

MASTER_COMPRESSION_ALGORITHMS の値は、slave_compressed_protocol システム変数が無効な場合にのみ適用されます。 slave_compressed_protocol が有効な場合は、MASTER_COMPRESSION_ALGORITHMS よりも優先され、ソースとレプリカの両方がそのアルゴリズムをサポートしている場合は、ソースへの接続で zlib 圧縮が使用されます。詳細は、セクション4.2.8「接続圧縮制御」を参照してください。

binlog_transaction_compression システム変数によってアクティブ化されるバイナリログトランザクション圧縮 (MySQL 8.0.20 で使用可能) を使用して帯域幅を節約することもできます。これを接続圧縮と組み合せて行うと、接続圧縮ではデータを処理する機会は少なくなりますが、ヘッダーと、圧縮されていないイベントおよびトランザクションペイロードは圧縮できます。バイナリログのトランザクション圧縮の詳細は、セクション5.4.4.5「バイナリログトランザクション圧縮」を参照してください。

MASTER_CONNECT_RETRY

ソースへの接続がタイムアウトした後にレプリカが試行する再接続の間隔を指定します。試行は、MASTER_RETRY_COUNT オプションによって制限されます。両方のデフォルト設定が使用されている場合、レプリカは再接続試行 (MASTER_CONNECT_RETRY=60) の間 60 秒待機し、60 日間 (MASTER_RETRY_COUNT=86400) 再接続を試行し続けます。これらの値はソースメタデータリポジトリに記録され、replication_connection_configuration「パフォーマンススキーマ」テーブルに表示されます。

MASTER_DELAY

レプリカが遅延する必要があるソースからの遅延秒数を指定します。ソースから受信したイベントは、ソースでの実行より少なくとも interval 秒後に実行されません。デフォルトは 0 です。 interval が 0 から 2³¹-1 までの範囲の負ではない整数でない場合は、エラーが発生します。詳細は、セクション17.4.11「遅延レプリケーション」を参照してください。 MASTER_DELAY オプションを使用する CHANGE MASTER TO ステートメントは、レプリケーション SQL スレッドの停止時に実行中のレプリカで実行できます。

MASTER_HEARTBEAT_PERIOD

ハートビート間隔を制御します。これにより、接続がまだ良好な場合に、データが存在しないときに接続タイムアウトが発生しなくなります。ハートビートシグナルは、その秒数が経過するとレプリカに送信され、ソースバイナリログがイベントで更新されるたびに待機期間がリセットされます。したがって、ハートビートは、これより長い期間バイナリログファイルに未送信のイベントがない場合にのみ、ソースによって送信されます。

ハートビート間隔 interval は、0 から 4294967 秒の範囲の小数値およびミリ秒単位の解像度です。ゼロ以外の最小値は 0.001 です。 interval を 0 に設定すると、ハートビートが完全に無効になります。ハートビート間隔のデフォルトは、slave_net_timeout システム変数の値の半分です。ソースメタデータリポジトリに記録され、replication_connection_configuration「パフォーマンススキーマ」テーブルに表示されます。 RESET REPLICA | SLAVE を発行すると、ハートビート間隔がデフォルト値にリセットされます。

slave_net_timeout システム変数は、レプリカがソースからのデータまたはハートビートシグナルのいずれかを待機する秒数を指定します。この秒数を過ぎると、レプリカは接続が切断されたとみなし、読取りを中断して再接続を試行します。デフォルト値は 60 秒 (1 分) です。 slave_net_timeout の値またはデフォルト設定を変更しても、明示的に設定されているか、以前に計算されたデフォルトを使用しているかにかかわらず、ハートビート間隔は自動的には変更されないことに注意してください。 @@GLOBAL.slave_net_timeout を現在のハートビート間隔より小さい値に設定すると、警告が発行されます。 slave_net_timeout が変更された場合は、接続タイムアウトの前にハートビートシグナルが発生するように、CHANGE MASTER TO を発行してハートビート間隔を適切な値に調整する必要もあります。これを行わない場合、ハートビートシグナルは効果がなく、ソースからデータを受信しない場合、レプリカは再接続を繰り返し試行してゾンビダンプスレッドを作成できます。

MASTER_HOST

レプリケーションソースサーバーのホスト名または IP アドレス。レプリカはこれを使用してソースに接続します。

MASTER_HOST または MASTER_PORT を指定した場合、レプリカは、ソースサーバーが以前とは異なることを前提とします (オプション値が現在の値と同じであっても)。) この場合、ソースバイナリログファイルの名前と位置の古い値は適用できなくなるため、ステートメントに MASTER_LOG_FILE と MASTER_LOG_POS を指定しないと、MASTER_LOG_FILE=''と MASTER_LOG_POS=4 は暗黙的に追加されます。

MASTER_HOST='' を設定する (つまり、その値を明示的に空の文字列に設定する) ことは、MASTER_HOST をまったく設定しないことと同じではありません。 MASTER_HOST を空の文字列に設定しようとすると、エラーで失敗します。

MASTER_LOG_FILE, MASTER_LOG_POS

バイナリログファイル名、およびレプリケーション I/O スレッドが次回のスレッド起動時にソースバイナリログからの読み取りを開始するそのファイル内の場所。バイナリログファイルの位置ベースのレプリケーションを使用している場合は、これらのオプションを指定します。 MASTER_LOG_FILE には、ソースサーバーで使用可能な特定のバイナリログファイル (MASTER_LOG_FILE='binlog.000145'など) の数値接尾辞が含まれている必要があります。 MASTER_LOG_POS は、レプリカがそのファイルの読取りを開始する数値位置です。 MASTER_LOG_POS=4 は、バイナリログファイルでイベントの開始を表します。

MASTER_LOG_FILE または MASTER_LOG_POS のどちらかを指定する場合は、RELAY_LOG_FILE や RELAY_LOG_POS を指定できません。 MASTER_LOG_FILE または MASTER_LOG_POS のいずれかを指定する場合は、GTID ベースのレプリケーション用の MASTER_AUTO_POSITION = 1 も指定できません。

MASTER_LOG_FILE も MASTER_LOG_POS も指定されていない場合、レプリカは CHANGE MASTER TO が発行される前のレプリケーション SQL スレッドの最後の座標を使用します。これにより、レプリケーション SQL スレッドがレプリケーション I/O スレッドと比較して遅延していても、レプリケーションの不連続性がなくなります。

MASTER_PASSWORD

レプリケーションソースサーバーへの接続に使用するレプリケーションユーザーアカウントのパスワード。 MASTER_PASSWORD を指定する場合は、MASTER_USER も必要です。

CHANGE MASTER TO ステートメントでレプリケーションユーザーアカウントに使用されるパスワードの長さは、32 文字に制限されています。 32 文字を超えるパスワードを使用しようとすると、CHANGE MASTER TO で障害が発生します。

MASTER_PORT

レプリカがレプリケーションソースサーバーへの接続に使用する TCP/IP ポート番号。

注記

レプリケーションでは、Unix ソケットファイルを使用できません。 TCP/IP を使用してレプリケーションソースサーバーに接続できる必要があります。

MASTER_PUBLIC_KEY_PATH

ソースが必要とする公開キーのレプリカ側のコピーを含むファイルへのパス名を指定することで、RSA キーペアベースのパスワード交換を有効にします。ファイルは PEM 形式である必要があります。このオプションは、sha256_password または caching_sha2_password 認証プラグインで認証されるレプリカに適用されます。 (sha256_password の場合、MASTER_PUBLIC_KEY_PATH は、MySQL が OpenSSL を使用して構築された場合にのみ使用できます。) caching_sha2_password プラグイン (MySQL 8.0 のデフォルト) で認証されるレプリケーションユーザーアカウントを使用していて、セキュアな接続を使用していない場合は、このオプションまたは GET_MASTER_PUBLIC_KEY=1 オプションを指定して、RSA 公開キーをレプリカに提供する必要があります。

MASTER_RETRY_COUNT

slave_net_timeout システム変数によって決定される、ソースへの接続がタイムアウトした後にレプリカが行う再接続の最大試行回数を設定します。レプリカを再接続する必要がある場合、タイムアウトの直後に最初の再試行が行われます。試行の間隔は、MASTER_CONNECT_RETRY オプションで指定します。両方のデフォルト設定が使用されている場合、レプリカは再接続試行 (MASTER_CONNECT_RETRY=60) の間 60 秒待機し、60 日間 (MASTER_RETRY_COUNT=86400) 再接続を試行し続けます。これらの値はソースメタデータリポジトリに記録され、replication_connection_configuration「パフォーマンススキーマ」テーブルに表示されます。 MASTER_RETRY_COUNT は、--master-retry-count サーバーの起動オプションより優先されます。

MASTER_SSL_xxx, MASTER_TLS_xxx

レプリカが暗号化および暗号化を使用してレプリケーション接続を保護する方法を指定します。これらのオプションは、SSL サポートなしでコンパイルされたレプリカでも変更できます。これらはソースメタデータリポジトリに保存されますが、レプリカで SSL サポートが有効になっていない場合は無視されます。 MASTER_SSL_xxx および MASTER_TLS_xxx オプションは、暗号化接続のコマンドオプションで説明されている --ssl-xxx および --tls-xxx クライアントオプションと同じ機能を実行します。 2 つのオプションセット間の対応、および MASTER_SSL_xxx オプションと MASTER_TLS_xxx オプションを使用したセキュアな接続の設定については、セクション17.3.1「暗号化接続を使用するためのレプリケーションの設定」を参照してください。

MASTER_USER

レプリケーションソースサーバーへの接続に使用するレプリケーションユーザーアカウントのユーザー名。

重要

caching_sha2_password プラグインで認証するレプリケーションユーザーアカウントを使用してソースに接続するには、セクション17.3.1「暗号化接続を使用するためのレプリケーションの設定」の説明に従ってセキュアな接続を設定するか、RSA キーペアを使用したパスワード交換をサポートするように暗号化されていない接続を有効にする必要があります。 caching_sha2_password 認証プラグインは、MySQL 8.0 から作成された新規ユーザーのデフォルトです (詳細は、セクション6.4.1.2「SHA-2 プラガブル認証のキャッシュ」を参照)。レプリケーション用に作成または使用するユーザーアカウントがこの認証プラグインを使用しており、セキュアな接続を使用していない場合は、正常に接続するために RSA キーペアベースのパスワード交換を有効にする必要があります。これは、MASTER_PUBLIC_KEY_PATH オプションまたはこのステートメントの GET_MASTER_PUBLIC_KEY=1 オプションを使用して実行できます。

MASTER_USER=''を指定して空のユーザー名を設定することはできますが、レプリケーションチャネルは空のユーザー名で開始できません。 MySQL 8.0.21 より前のリリースでは、セキュリティ上の目的で以前に使用した資格証明をレプリケーションメタデータリポジトリからクリアする必要がある場合にのみ、空の MASTER_USER ユーザー名を設定します。これらのリリースでは、リポジトリから空のユーザー名が読み取られた場合 (グループレプリケーションチャネルの自動再起動時など)、デフォルトのユーザー名を置換できるバグのため、後でチャネルを使用しないでください。 MySQL 8.0.21 からは、レプリケーションチャネルを開始する START REPLICA | SLAVE ステートメントまたは START GROUP_REPLICATION ステートメントを使用して常にユーザー資格証明を指定する場合、空の MASTER_USER ユーザー名を設定し、後でチャネルを使用できます。このアプローチでは、レプリケーションチャネルを再起動するためにオペレータの介入が常に必要ですが、ユーザー資格証明はレプリケーションメタデータリポジトリに記録されません。

実行中の CHANGE MASTER TO ステートメントのテキスト (MASTER_USER と MASTER_PASSWORD の値を含む) は、並列 SHOW PROCESSLIST ステートメントの出力で確認できます。 (START REPLICA | SLAVE ステートメントの完全なテキストは、SHOW PROCESSLIST にも表示されます。)

MASTER_ZSTD_COMPRESSION_LEVEL

zstd 圧縮アルゴリズムを使用するレプリケーションソースサーバーへの接続に使用する圧縮レベル。許可されるレベルは 1 から 22 で、大きい値は圧縮レベルの増加を示します。デフォルトの zstd 圧縮レベルは 3 です。圧縮レベルの設定は、zstd 圧縮を使用しない接続には影響しません。 MASTER_ZSTD_COMPRESSION_LEVEL は、MySQL 8.0.18 の時点で使用可能です。詳細は、セクション4.2.8「接続圧縮制御」を参照してください。

NETWORK_NAMESPACE

レプリケーションソースサーバーへの TCP/IP 接続に使用するネットワークネームスペース。このオプションを省略すると、レプリカからの接続にはデフォルト (グローバル) 名前空間が使用されます。ネットワークネームスペースのサポートを実装していないプラットフォームでは、レプリカがソースに接続しようとすると障害が発生します。ネットワークネームスペースの詳細は、セクション5.1.14「ネットワークネームスペースのサポート」を参照してください。 NETWORK_NAMESPACE は、MySQL 8.0.22 の時点で使用可能です。

PRIVILEGE_CHECKS_USER

指定されたチャネルのセキュリティコンテキストを提供するユーザーアカウントを指定します。 NULL(デフォルト) は、セキュリティコンテキストが使用されないことを意味します。 PRIVILEGE_CHECKS_USER は、MySQL 8.0.18 の時点で使用可能です。

ユーザーアカウントのユーザー名とホスト名は、セクション6.2.4「アカウント名の指定」で説明されている構文に従う必要があり、ユーザーは匿名ユーザー (ユーザー名が空白) または CURRENT_USER であってはなりません。アカウントには、REPLICATION_APPLIER 権限と、チャネルでレプリケートされたトランザクションを実行するために必要な権限が必要です。アカウントに必要な権限の詳細は、セクション17.3.3「レプリケーション権限チェック」を参照してください。レプリケーションチャネルを再起動すると、その時点から権限チェックが適用されます。チャネルを指定せず、他のチャネルが存在しない場合は、ステートメントがデフォルトチャネルに適用されます。

PRIVILEGE_CHECKS_USER が設定されており、これを強制するように REQUIRE_ROW_FORMAT を設定できる場合は、行ベースのバイナリロギングを使用することを強くお勧めします。たとえば、実行中のレプリカでチャネル channel_1 に対する権限チェックを開始するには、次のステートメントを発行します:

mysql> STOP REPLICA | SLAVE FOR CHANNEL 'channel_1';
mysql> CHANGE MASTER TO
         PRIVILEGE_CHECKS_USER = 'priv_repl'@'%.example.com',
         REQUIRE_ROW_FORMAT = 1,
         FOR CHANNEL 'channel_1';
mysql> START REPLICA | SLAVE FOR CHANNEL 'channel_1';

RELAY_LOG_FILE, RELAY_LOG_POS

次回のスレッド起動時にレプリケーション SQL スレッドがレプリカリレーログからの読取りを開始するリレーログファイル名およびそのファイル内の場所。 MASTER_LOG_FILE または MASTER_LOG_POS を使用している場合、これらのオプションは使用できません。

RELAY_LOG_FILE では、絶対パスまたは相対パスのいずれかを使用でき、MASTER_LOG_FILE と同じベース名を使用します。 RELAY_LOG_FILE、RELAY_LOG_POS またはその両方のオプションを使用する CHANGE MASTER TO ステートメントは、レプリケーション SQL スレッドの停止時に実行中のレプリカで実行できます。少なくともいずれかのレプリケーション SQL スレッドとレプリケーション I/O スレッドが実行されている場合、リレーログは保持されます。両方のスレッドが停止すると、RELAY_LOG_FILE または RELAY_LOG_POS のいずれかが指定されていないかぎり、すべてのリレーログファイルが削除されます。 Group Replication applier チャネル (group_replication_applier) には I/O スレッドがなく、SQL スレッドのみがあることに注意してください。このチャネルでは、SQL スレッドの停止時にリレーログは保持されません。

REQUIRE_ROW_FORMAT

レプリケーションチャネルによる行ベースのレプリケーションイベントの処理のみを許可します。このオプションにより、レプリケーションアプライアンスは一時テーブルの作成や LOAD DATA INFILE リクエストの実行などのアクションを実行できなくなり、チャネルのセキュリティが向上します。グループレプリケーションチャネルは REQUIRE_ROW_FORMAT セットで自動的に作成され、これらのチャネルのオプションは変更できません。詳細は、セクション17.3.3「レプリケーション権限チェック」を参照してください。 REQUIRE_ROW_FORMAT は、MySQL 8.0.19 の時点で使用可能です。

REQUIRE_TABLE_PRIMARY_KEY_CHECK

レプリカが主キーチェック用に独自のポリシーを選択できるようにします。レプリケーションチャネルのオプションが ON に設定されている場合、レプリカはレプリケーション操作で常に sql_require_primary_key システム変数に値 ON を使用し、主キーが必要です。このオプションが OFF に設定されている場合、レプリカはレプリケーション操作で sql_require_primary_key システム変数に常に値 OFF を使用するため、ソースで必要な場合でも主キーは必要ありません。 REQUIRE_TABLE_PRIMARY_KEY_CHECK オプションが STREAM(デフォルト) に設定されている場合、レプリカは各トランザクションのソースからレプリケートされた値を使用します。 REQUIRE_TABLE_PRIMARY_KEY_CHECK は、MySQL 8.0.20 の時点で使用可能です。

マルチソースレプリケーションの場合、REQUIRE_TABLE_PRIMARY_KEY_CHECK を ON または OFF に設定すると、レプリカは異なるソースのレプリケーションチャネル間で動作を正規化し、sql_require_primary_key システム変数の一貫性のある設定を維持できます。 ON を使用すると、複数のソースが同じテーブルセットを更新する場合に、主キーの偶発的な損失から保護されます。 OFF を使用すると、主キーを操作できるソースを、操作できないソースと連携させることができます。

PRIVILEGE_CHECKS_USER が設定されている場合、REQUIRE_TABLE_PRIMARY_KEY_CHECK を ON または OFF に設定することは、制限付きセッション変数を設定するためのセッション管理レベルの権限がユーザーアカウントに必要ないことを意味します。これは、sql_require_primary_key の値を各トランザクションのソース設定と一致するように変更するために必要です。詳細は、セクション17.3.3「レプリケーション権限チェック」を参照してください。

SOURCE_CONNECTION_AUTO_FAILOVER

1 つ以上の代替レプリケーションサーバーが使用可能な場合 (レプリケートされたデータを共有する複数の MySQL サーバーまたはサーバーグループが存在する場合)、レプリケーションチャネルの非同期接続フェイルオーバーメカニズムをアクティブ化します。 SOURCE_CONNECTION_AUTO_FAILOVER は、MySQL 8.0.22 の時点で使用可能です。非同期接続フェイルオーバーメカニズムは、MASTER_CONNECT_RETRY および MASTER_RETRY_COUNT によって制御されている再接続試行を使い果たした後に引き継ぎます。 asynchronous_connection_failover_add_source および asynchronous_connection_failover_delete_source UDF を使用して管理する、指定されたソースリストから選択された代替ソースにレプリカを再接続します。サーバーの管理対象グループを追加および削除するには、かわりに asynchronous_connection_failover_add_managed および asynchronous_connection_failover_delete_managed UDF を使用します。詳細は、セクション17.4.9「非同期接続フェイルオーバーによるソースの切替え」を参照してください。

重要

GTID 自動配置が使用中 (MASTER_AUTO_POSITION = 1) の場合にのみ、SOURCE_CONNECTION_AUTO_FAILOVER = 1 を設定できます。
SOURCE_CONNECTION_AUTO_FAILOVER = 1 を設定する場合、一時的なネットワークの停止が原因で接続障害が発生した場合に、MASTER_RETRY_COUNT および MASTER_CONNECT_RETRY を、同じソースでの数回の再試行のみを許可する最小数に設定します。そうしないと、非同期接続フェイルオーバーメカニズムをすぐにアクティブ化できません。適切な値は MASTER_RETRY_COUNT=3 と MASTER_CONNECT_RETRY=10 です。これにより、レプリカは 10 秒間隔で接続を 3 回再試行します。
SOURCE_CONNECTION_AUTO_FAILOVER = 1 を設定する場合、レプリケーションメタデータリポジトリには、レプリケーションチャネルのソースリスト上のすべてのサーバーへの接続に使用できるレプリケーションユーザーアカウントの資格証明が含まれている必要があります。これらの資格証明は、MASTER_USER および MASTER_PASSWORD オプションを指定した CHANGE REPLICATION SOURCE TO ステートメントを使用して設定できます。詳細は、セクション17.4.9「非同期接続フェイルオーバーによるソースの切替え」を参照してください。

次の表は、文字列値のオプションに許可される最大長を示しています。

オプション	最大長
`MASTER_HOST`	255 (MySQL 8.0.17 より前の 60)
`MASTER_USER`	96
`MASTER_PASSWORD`	32
`MASTER_LOG_FILE`	511
`RELAY_LOG_FILE`	511
`MASTER_SSL_CA`	511
`MASTER_SSL_CAPATH`	511
`MASTER_SSL_CERT`	511
`MASTER_SSL_CRL`	511
`MASTER_SSL_CRLPATH`	511
`MASTER_SSL_KEY`	511
`MASTER_SSL_CIPHER`	511
`MASTER_TLS_VERSION`	511
`MASTER_TLS_CIPHERSUITES`	4000
`MASTER_PUBLIC_KEY_PATH`	511
`MASTER_COMPRESSION_ALGORITHMS`	99
`NETWORK_NAMESPACE`	64

PREV HOME UP NEXT