MySQL Server クローンプラグインは、MySQL 8.0.17 から入手できます。 グループ内の分散リカバリにリモートクローニング操作を使用する場合は、この機能をサポートするために、事前に既存のメンバーを設定してメンバーを結合する必要があります。 この関数をグループで使用しない場合は、設定しないでください。この場合、Group Replication はバイナリログからの状態転送のみを使用します。
クローニングを使用するには、リモートクローニング操作をサポートするために、少なくとも 1 つの既存のグループメンバーと参加メンバーを事前に設定する必要があります。 少なくとも、クローンプラグインをドナーにインストールしてメンバーに参加し、分散リカバリのためにレプリケーションユーザーに BACKUP_ADMIN 権限を付与し、group_replication_clone_threshold システム変数を適切なレベルに設定する必要があります。 ドナーの最大可用性を確保するには、リモートクローニング操作をサポートするように、現在および将来のすべてのグループメンバーを設定することをお薦めします。
リモートクローニング操作では、ドナーからデータを転送する前に、結合メンバーからユーザー作成のテーブルスペースおよびデータが削除されることに注意してください。 進行中に操作が停止した場合、結合メンバーに部分データが残されるか、データが残されない可能性があります。 これを修復するには、Group Replication が自動的に行うリモートクローニング操作を再試行します。
クローンプラグインを設定および構成する完全な手順については、セクション5.6.7「クローンプラグイン」 を参照してください。 リモートクローニング操作の詳細な前提条件については、セクション5.6.7.3「リモートデータのクローニング」 を参照してください。 Group Replication の場合、次の重要なポイントと相違点に注意してください:
ドナー (既存のグループメンバー) および受信者 (参加メンバー) にクローンプラグインがインストールされ、アクティブである必要があります。 これを行う手順は、セクション5.6.7.1「クローンプラグインのインストール」 を参照してください。
ドナーと受信者は、同じオペレーティングシステム上で実行され、同じ MySQL Server バージョン (MySQL 8.0.17 以上でクローンプラグインをサポートする必要があります) である必要があります。 したがって、クローニングは、メンバーが異なる MySQL Server バージョンを実行するグループには適していません。
ドナーと受信者は Group Replication プラグインをインストールしてアクティブにする必要があり、ドナーでアクティブなその他のプラグイン (キーリングプラグインなど) も受信者でアクティブにする必要があります。
分散リカバリが SSL (
group_replication_recovery_use_ssl=ON) を使用するように構成されている場合、グループレプリケーションはリモートクローニング操作にこの設定を適用します。 Group Replication は、クローン SSL オプション (clone_ssl_ca、clone_ssl_certおよびclone_ssl_key) の設定を、対応する Group Replication 分散リカバリオプション (group_replication_recovery_ssl_ca、group_replication_recovery_ssl_certおよびgroup_replication_recovery_ssl_key) の設定と一致するように自動的に構成します。レプリケーショングループに参加するために、
clone_valid_donor_listシステム変数に有効なドナーのリストを設定する必要はありません。 グループレプリケーションは、既存のグループメンバーからドナーを選択した後、この設定を自動的に構成します。 リモートクローニング操作では、サーバー SQL プロトコルのホスト名とポートが使用されることに注意してください。クローンプラグインには、リモートクローニング操作のネットワーク負荷およびパフォーマンスへの影響を管理するための多数のシステム変数があります。 グループレプリケーションではこれらの設定は構成されないため、必要に応じて設定したり、デフォルト設定を許可できます。 リモートクローニング操作を分散リカバリに使用する場合は、Group Replication 圧縮設定ではなくクローンプラグインの
clone_enable_compression設定が操作に適用されることに注意してください。受信者に対してリモートクローニング操作を起動するために、グループレプリケーションでは、
CLONE_ADMIN権限がすでにある内部mysql.sessionユーザーが使用されるため、これを設定する必要はありません。-
リモートクローニング操作のドナーのクローンユーザーとして、Group Replication では分散リカバリ用に設定したレプリケーションユーザー (セクション18.2.1.3「分散リカバリのユーザー資格証明」 で説明) が使用されます。 したがって、クローニングをサポートするすべてのグループメンバーに対して、このレプリケーションユーザーに
BACKUP_ADMIN権限を付与する必要があります。 また、グループレプリケーション用にメンバーを構成する場合は、レプリケーションユーザーにメンバーへの参加権限を付与します。これは、メンバーがグループに参加した後にドナーとして機能できるためです。 すべてのグループメンバーで分散リカバリに同じレプリケーションユーザーが使用されます。 既存のメンバーに対してこの権限をレプリケーションユーザーに付与するには、バイナリロギングを無効にして各グループメンバーに対して、またはバイナリロギングを有効にしているグループメンバーに対して、次のステートメントを発行します:GRANT BACKUP_ADMIN ON *.* TO rpl_user@'%'; START GROUP_REPLICATIONを使用して、以前にCHANGE REPLICATION SOURCE TO|CHANGE MASTER TOを使用してユーザー資格証明を提供したサーバー上のレプリケーションユーザー資格証明を指定する場合は、リモートクローニング操作を実行する前に、必ずレプリケーションメタデータリポジトリからユーザー資格証明を削除してください。 また、結合メンバーにgroup_replication_start_on_boot=OFFが設定されていることを確認します。 その手順は、セクション18.5.3「分散リカバリ接続の保護」を参照してください。 ユーザー資格証明の設定を解除しない場合、リモートクローニング操作中に参加メンバーに転送されます。 その後、元のメンバーまたはそこからクローニングされたメンバーのいずれかで、group_replication_recoveryチャネルが誤って格納された資格証明で起動される可能性があります。 サーバー起動時のグループレプリケーションの自動開始 (リモートクローニング操作後を含む) では、格納されたユーザー資格証明が使用され、オペレータがSTART GROUP_REPLICATIONコマンドで分散リカバリ資格証明を指定しなかった場合にも使用されます。
グループメンバーがクローニングをサポートするように設定されている場合、group_replication_clone_threshold システム変数は、分散リカバリでリモートクローニング操作を使用するためのしきい値をトランザクション数で指定します。 ドナー上のトランザクションと参加メンバー上のトランザクションの間のギャップがこの数より大きい場合は、技術的に可能であれば、参加メンバーへの状態転送にリモートクローニング操作が使用されます。 グループレプリケーションでは、既存のグループメンバーの gtid_executed セットに基づいて、しきい値を超えたかどうかが計算されます。 トランザクションのギャップが大きい場合にリモートクローニング操作を使用すると、事前にグループデータをサーバーに手動で転送せずに新しいメンバーをグループに追加できます。また、非常に古いメンバーをより効率的にキャッチアップできます。
group_replication_clone_threshold Group Replication システム変数のデフォルト設定は非常に高いため (GTID 内のトランザクションに許可されている最大シーケンス番号)、バイナリログからの状態転送が可能な場合は、クローニングが事実上非アクティブ化されます。 グループレプリケーションで、より適切な状態転送のリモートクローニング操作を選択できるようにするには、システム変数を設定して、クローニングを実行するトランザクションのギャップとしてトランザクション数を指定します。
アクティブグループの group_replication_clone_threshold には低い設定を使用しないでください。 リモートクローニング操作の進行中にしきい値を超える数のトランザクションがグループで発生した場合、参加メンバーは再起動後にリモートクローニング操作を再度トリガーし、これを無期限に続行できます。 この状況を回避するには、リモートクローニング操作にかかる時間内にグループ内で発生すると予想されるトランザクション数よりも大きい数をしきい値に設定してください。
ドナーバイナリログからの状態転送が不可能な場合、たとえば、参加メンバーに必要なトランザクションが既存のグループメンバーのバイナリログで使用できないため、グループレプリケーションはしきい値に関係なくリモートクローニング操作を実行しようとします。 グループレプリケーションは、既存のグループメンバーの gtid_purged セットに基づいてこれを識別します。 必要なトランザクションがどのメンバーバイナリログファイルでも使用できない場合、group_replication_clone_threshold システム変数を使用してクローニングを非アクティブ化することはできません。この状況では、クローニングは、結合するメンバーに手動でデータを転送する唯一の代替手段であるためです。
グループメンバーおよび参加メンバーがクローニング用に設定されている場合、グループレプリケーションによってリモートクローニング操作が管理されます。 データのサイズによっては、リモートクローニング操作の完了に時間がかかる場合があります。 プロセスの監視の詳細は、セクション5.6.7.9「クローニング操作の監視」 を参照してください。
状態の転送が完了すると、Group Replication は参加メンバーを再起動してプロセスを完了します。 START GROUP_REPLICATION ステートメントでレプリケーションユーザー資格証明を指定するなどの理由で、参加メンバーに group_replication_start_on_boot=OFF が設定されている場合は、この再起動後に START GROUP_REPLICATION を手動で再発行する必要があります。 グループレプリケーションの開始に必要な group_replication_start_on_boot=ON およびその他の設定が構成ファイルで設定されている場合、または SET PERSIST ステートメントを使用して設定されている場合は、介入する必要はなく、参加メンバーを自動的にオンラインにするプロセスが続行されます。
リモートクローニング手順に時間がかかる場合、MySQL 8.0.22 より前のリリースでは、その期間中にグループに対して蓄積された一連の動作保証情報が大きすぎて、参加メンバーに転送できなくなる可能性があります。 その場合、参加メンバーはエラーメッセージをログに記録し、グループには参加しません。 MySQL 8.0.22 から、Group Replication は、このシナリオを回避するために、適用されたトランザクションのガベージコレクションプロセスを異なる方法で管理します。 以前のリリースでは、このエラーが表示された場合、リモートクローニング操作の完了後、2 分間待ってガベージコレクションが行われるようにし、グループ証明情報のサイズを小さくしてください。 次に、結合メンバーに対して次のステートメントを発行して、前の一連の証明情報の適用を停止します:
RESET SLAVE FOR CHANNEL group_replication_recovery;
Or from MySQL 8.0.22:
RESET REPLICA FOR CHANNEL group_replication_recovery;リモートクローニング操作では、ドナーから受信者へのテーブルに保持されている設定およびデータがクローニングされます。 Group Replication は、Group Replication チャネルに特に関連する設定を管理します。 グループレプリケーションのローカルアドレスなどの構成ファイルに保持されているグループレプリケーションメンバー設定はクローニングされず、参加メンバーでは変更されません。 グループレプリケーションでは、SSL の使用に関連するチャネル設定も保持されるため、これらは個々のメンバーに固有です。
group_replication_recovery レプリケーションチャネルのドナーが使用するレプリケーションユーザー資格証明が CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO ステートメントを使用してレプリケーションメタデータリポジトリに格納されている場合、クローニング後にメンバーに転送されて使用され、そこで有効である必要があります。 格納された資格証明を使用すると、リモートクローニング操作によって状態転送を受信したすべてのグループメンバーは、分散リカバリのレプリケーションユーザーおよびパスワードを自動的に受信します。 START GROUP_REPLICATION ステートメントでレプリケーションユーザーの資格証明を指定すると、リモートクローニング操作の開始に使用されますが、クローニング後に参加メンバーに転送されず、メンバーによって使用されることはありません。 資格証明を新しいジョイナに転送せず、そこで記録する場合は、セクション18.5.3「分散リカバリ接続の保護」 の説明に従ってリモートクローニング操作を実行する前に資格証明の設定を解除し、かわりに START GROUP_REPLICATION を使用してそれらを指定してください。
レプリケーションアプライアンスを保護するために PRIVILEGE_CHECKS_USER アカウントが使用されている場合 (セクション17.3.3.2「グループレプリケーションチャネルの権限チェック」 を参照)、MySQL 8.0.19 から、ドナーの PRIVILEGE_CHECKS_USER アカウントおよび関連設定が結合メンバーにクローニングされます。 参加メンバーがブート時にグループレプリケーションを開始するように設定されている場合、適切なレプリケーションチャネルの権限チェックにアカウントが自動的に使用されます。 (MySQL 8.0.18 では、多くの制限により、グループレプリケーションチャネルで PRIVILEGE_CHECKS_USER アカウントを使用しないことをお薦めします。)
Group Replication は、分散リカバリのクローニング操作を開始および管理します。 クローニングをサポートするように設定されたグループメンバーは、ユーザーが手動で開始するクローニング操作にも参加できます。 たとえば、グループメンバーからドナーとしてクローニングして新しいサーバーインスタンスを作成するが、新しいサーバーインスタンスをすぐにグループに参加させない場合やそうでない場合があります。
クローニングをサポートするすべてのリリースで、グループレプリケーションを停止するグループメンバーを含むクローニング操作を手動で開始できます。 クローニングではドナーと受信者のアクティブなプラグインが一致する必要があるため、そのサーバーインスタンスをグループに参加させない場合でも、グループレプリケーションプラグインを他のサーバーインスタンスにインストールしてアクティブにする必要があります。 プラグインをインストールするには、次のステートメントを発行します:
INSTALL PLUGIN group_replication SONAME 'group_replication.so';
MySQL 8.0.20 より前のリリースでは、操作にグループレプリケーションが実行されているグループメンバーが含まれる場合、クローニング操作を手動で開始することはできません。 クローニング操作で受信者のデータが削除および置換されない場合は、MySQL 8.0.20 からこれを実行できます。 したがって、Group Replication が実行されている場合は、クローニング操作を開始するステートメントに DATA DIRECTORY 句を含める必要があります。