PDF (US Ltr)
- 36.1Mb
PDF (A4)
- 36.2Mb
このページは機械翻訳したものです。
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 句を使用すると、ステートメントが適用されるレプリケーションチャネルの名前を指定できます。 channelFOR CHANNEL 句を指定すると、channelCHANGE MASTER TO ステートメントが特定のレプリケーションチャネルに適用され、新しいチャネルの追加または既存のチャネルの変更に使用されます。 たとえば、channel2 という新しいチャネルを追加するには、次のようにします:
CHANGE MASTER TO MASTER_HOST=host1, MASTER_PORT=3002 FOR CHANNEL 'channel2'句が指定されておらず、追加のチャネルが存在しない場合、ステートメントはデフォルトチャネルに適用されます。
複数のレプリケーションチャネルを使用する場合、CHANGE MASTER TO ステートメントで FOR CHANNEL 句を使用してチャネルを指定しないと、エラーが発生します。 詳しくはセクション17.2.2「レプリケーションチャネル」をご覧ください。
channel
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 を割り当てます。uuidserver_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またはuuidgtid_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 から 231-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_HOSTまたはMASTER_PORTを指定した場合、レプリカは、ソースサーバーが以前とは異なることを前提とします (オプション値が現在の値と同じであっても)。) この場合、ソースバイナリログファイルの名前と位置の古い値は適用できなくなるため、ステートメントにMASTER_LOG_FILEとMASTER_LOG_POSを指定しないと、MASTER_LOG_FILE=''とMASTER_LOG_POS=4は暗黙的に追加されます。 -
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_,xxxMASTER_TLS_xxx レプリカが暗号化および暗号化を使用してレプリケーション接続を保護する方法を指定します。 これらのオプションは、SSL サポートなしでコンパイルされたレプリカでも変更できます。 これらはソースメタデータリポジトリに保存されますが、レプリカで SSL サポートが有効になっていない場合は無視されます。
MASTER_SSL_およびxxxMASTER_TLS_オプションは、暗号化接続のコマンドオプション で説明されているxxx--ssl-およびxxx--tls-クライアントオプションと同じ機能を実行します。 2 つのオプションセット間の対応、およびxxxMASTER_SSL_オプションとxxxMASTER_TLS_オプションを使用したセキュアな接続の設定については、セクション17.3.1「暗号化接続を使用するためのレプリケーションの設定」 を参照してください。xxx-
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_sourceUDF を使用して管理する、指定されたソースリストから選択された代替ソースにレプリカを再接続します。 サーバーの管理対象グループを追加および削除するには、かわりにasynchronous_connection_failover_add_managedおよびasynchronous_connection_failover_delete_managedUDF を使用します。 詳細は、セクション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 |