MySQL 8.0 リファレンスマニュアル

5.6.7.6 レプリケーション用のクローニング

クローンプラグインはレプリケーションをサポートします。 クローニング操作では、クローニングデータに加えて、ドナーからレプリケーション座標が抽出されて受信者に転送されるため、グループレプリケーションメンバーおよびレプリカのプロビジョニングにクローンプラグインを使用できます。 プロビジョニングにクローンプラグインを使用すると、多数のトランザクションをレプリケートするよりもはるかに高速かつ効率的になります。

グループレプリケーションメンバーは、分散リカバリのオプションとしてクローンプラグインを使用するように構成することもできます。この場合、メンバーを結合すると、既存のグループメンバーからグループデータを取得する最も効率的な方法が自動的に選択されます。 詳細は、セクション18.4.3.2「分散リカバリのためのクローニング」を参照してください。

クローニング操作中に、バイナリログの位置 (ファイル名、オフセット) と gtid_executed GTID セットの両方が抽出され、ドナー MySQL サーバーインスタンスから受信者に転送されます。 このデータを使用すると、レプリケーションストリーム内の一貫した位置でレプリケーションを開始できます。 ファイルに保持されているバイナリログおよびリレーログは、ドナーから受信者にコピーされません。 レプリケーションを開始するには、受信者がドナーをキャッチアップするために必要なバイナリログを、データがクローニングされてからレプリケーションが開始されるまでパージしないでください。 必要なバイナリログが使用できない場合は、レプリケーションハンドシェイクエラーが報告されます。 したがって、クローニングされたインスタンスは、必要なバイナリログがパージされたり、新しいメンバーが大幅に遅れたりしないように、過剰な遅延なしでレプリケーショングループに追加する必要があり、リカバリ時間が長くなります。

  • クローニングされた MySQL サーバーインスタンスで次のクエリーを発行して、受信者に転送されたバイナリログの位置を確認します: 

    mysql> SELECT BINLOG_FILE, BINLOG_POSITION FROM performance_schema.clone_status;

  • クローニングされた MySQL サーバーインスタンスで次のクエリーを発行して、受信者に転送された gtid_executed GTID セットを確認します: 

    mysql> SELECT @@GLOBAL.GTID_EXECUTED;

MySQL 8.0 のデフォルトでは、レプリケーションメタデータリポジトリは、クローニング操作中にドナーから受信者にコピーされるテーブルに保持されます。 レプリケーションメタデータリポジトリには、クローニング操作後にレプリケーションを正しく再開するために使用できるレプリケーション関連の構成設定が保持されます。

  • MySQL 8.0.17 および 8.0.18 では、mysql.slave_master_info テーブル (接続メタデータリポジトリ) のみがコピーされます。

  • MySQL 8.0.19 から、mysql.slave_relay_log_info (アプライヤメタデータリポジトリ) テーブルおよび mysql.slave_worker_info (アプライヤワーカーメタデータリポジトリ) テーブルもコピーされます。

各テーブルに含まれる内容のリストは、セクション17.2.4.2「レプリケーションメタデータリポジトリ」 を参照してください。 設定 master_info_repository=FILE および relay_log_info_repository=FILE がサーバーで使用されている場合 (MySQL 8.0 ではデフォルトではなく、非推奨です)、レプリケーションメタデータリポジトリはクローニングされず、TABLE が設定されている場合にのみクローニングされます。

レプリケーション用にクローニングするには、次のステップを実行します:

  1. グループレプリケーション用の新しいグループメンバーの場合は、セクション18.2.1.6「グループへのインスタンスの追加」 の手順に従って、まずグループレプリケーション用の MySQL Server インスタンスを構成します。 また、セクション18.4.3.2「分散リカバリのためのクローニング」 で説明されているクローニングの前提条件も設定します。 結合メンバーに対して START GROUP_REPLICATION を発行すると、クローニング操作はグループレプリケーションによって自動的に管理されるため、操作を手動で実行する必要はなく、結合メンバーに対してこれ以上の設定ステップを実行する必要もありません。

  2. ソース/レプリカ MySQL レプリケーショントポロジ内のレプリカの場合、まずドナー MySQL サーバーインスタンスから受信者に手動でデータをクローニングします。 ドナーは、レプリケーショントポロジのソースまたはレプリカである必要があります。 クローニングの手順は、セクション5.6.7.3「リモートデータのクローニング」 を参照してください。

  3. クローニング操作が正常に完了した後、ドナーに存在する受信者 MySQL サーバーインスタンスで同じレプリケーションチャネルを使用する場合は、ソース/レプリカ MySQL レプリケーショントポロジでレプリケーションを自動的に再開できるかどうか、および手動で設定する必要があるかどうかを確認します。

    • GTID ベースのレプリケーションでは、受信者が gtid_mode=ON を使用して構成され、gtid_mode=ON、ON_PERMISSIVE または OFF_PERMISSIVE を使用してドナーからクローニングされた場合、ドナーからの gtid_executed GTID セットが受信者に適用されます。 トポロジ内にすでに存在するレプリカから受信者がクローニングされている場合、GTID 自動配置を使用する受信者のレプリケーションチャネルは、チャネルの起動時にクローニング操作後にレプリケーションを自動的に再開できます。 これらの同じチャネルを使用するだけの場合は、手動設定を実行する必要はありません。

    • バイナリログファイルの位置ベースのレプリケーションでは、受信者が MySQL 8.0.17 または 8.0.18 にいる場合、ドナーからのバイナリログの位置は受信者に適用されず、パフォーマンススキーマ clone_status テーブルにのみ記録されます。 したがって、バイナリログファイルの位置ベースのレプリケーションを使用する受信者のレプリケーションチャネルは、クローニング操作後にレプリケーションを再開するように手動で設定する必要があります。 サーバーの起動時にレプリケーションを自動的に開始するようにこれらのチャネルが構成されていないことを確認します。これらのチャネルにはまだバイナリログの位置がなく、最初からレプリケーションを開始しようとしていないためです。

    • バイナリログファイルの位置ベースのレプリケーションでは、受信者が MySQL 8.0.19 以上の場合、ドナーからのバイナリログの位置が受信者に適用されます。 バイナリログファイルの位置ベースのレプリケーションを使用する受信者のレプリケーションチャネルは、複製されたリレーログ情報を使用してリレーログリカバリプロセスの実行を自動的に試みてから、レプリケーションを再開します。 シングルスレッドレプリカ (slave_parallel_workers が 0 に設定されている) の場合、他の問題がなければリレーログリカバリは成功し、チャネルはそれ以上の設定なしでレプリケーションを再開できます。 マルチスレッドレプリカ (slave_parallel_workers が 0 より大きい) の場合、通常は自動的に完了できないため、リレーログリカバリが失敗する可能性があります。 この場合、エラーメッセージが発行され、チャネルを手動で設定する必要があります。

  4. クローニングされたレプリケーションチャネルを手動で設定する必要がある場合、または受信者で異なるレプリケーションチャネルを使用する必要がある場合は、次の手順で、受信者 MySQL サーバーインスタンスをレプリケーショントポロジに追加するためのサマリーおよび省略された例を示します。 レプリケーション設定に適用される詳細な手順も参照してください。

    • GTID ベースのトランザクションをレプリケーションデータソースとして使用する MySQL レプリケーショントポロジに受信者 MySQL サーバーインスタンスを追加するには、セクション17.1.3.4「GTID を使用したレプリケーションのセットアップ」 の手順に従って、必要に応じてインスタンスを構成します。 次の省略例に示すように、インスタンスのレプリケーションチャネルを追加します。 (MySQL 8.0.23 の) CHANGE REPLICATION SOURCE TO ステートメントまたは (MySQL 8.0.23 の前の)CHANGE MASTER TO ステートメントで、ソースのホストアドレスおよびポート番号を定義し、SOURCE_AUTO_POSITION | MASTER_AUTO_POSITION オプションを有効にする必要があります: 

      mysql> CHANGE MASTER TO MASTER_HOST = 'source_host_name', MASTER_PORT = source_port_num,
       ...
       MASTER_AUTO_POSITION = 1,
       FOR CHANNEL 'setup_channel';
mysql> START SLAVE USER = 'user_name' PASSWORD = 'password' FOR CHANNEL 'setup_channel';

Or from MySQL 8.0.22 and 8.0.23:

mysql> CHANGE SOURCE TO SOURCE_HOST = 'source_host_name', SOURCE_PORT = source_port_num,
       ...
       SOURCE_AUTO_POSITION = 1,
       FOR CHANNEL 'setup_channel';
mysql> START REPLICA USER = 'user_name' PASSWORD = 'password' FOR CHANNEL 'setup_channel';

    • バイナリログファイルの位置ベースのレプリケーションを使用する MySQL レプリケーショントポロジに受信者 MySQL サーバーインスタンスを追加するには、セクション17.1.2「バイナリログファイルの位置ベースのレプリケーションの設定」 の手順に従って、必要に応じてインスタンスを構成します。 クローニング操作中に受信者に転送されたバイナリログ位置を使用して、次の省略例に示すように、インスタンスのレプリケーションチャネルを追加します: 

      mysql> SELECT BINLOG_FILE, BINLOG_POSITION FROM performance_schema.clone_status;
mysql> CHANGE MASTER TO MASTER_HOST = 'source_host_name', MASTER_PORT = source_port_num,
       ...
       MASTER_LOG_FILE = 'source_log_name',
       MASTER_LOG_POS = source_log_pos,
       FOR CHANNEL 'setup_channel';
mysql> START SLAVE USER = 'user_name' PASSWORD = 'password' FOR CHANNEL 'setup_channel';

Or from MySQL 8.0.22 and 8.0.23:

mysql> SELECT BINLOG_FILE, BINLOG_POSITION FROM performance_schema.clone_status;
mysql> CHANGE SOURCE TO SOURCE_HOST = 'source_host_name', SOURCE_PORT = source_port_num,
       ...
       SOURCE_LOG_FILE = 'source_log_name',
       SOURCE_LOG_POS = source_log_pos,
       FOR CHANNEL 'setup_channel';
mysql> START REPLICA USER = 'user_name' PASSWORD = 'password' FOR CHANNEL 'setup_channel';

関連キーワード: 　サーバー, 受信, バイナリ, インスタンス, ログ, 設定, 操作, 変数, チャネル, 構成
PREV   HOME   UP   NEXT