MySQL 分散リカバリ インスタンスの分析

1. 概要

MySQL サーバーが MGR クラスターに新規に参加または再参加するときは常に、クラスター内のさまざまなトランザクションに追いつき、このノードのデータが MGR クラスター内の最新データと同期していることを確認する必要があります。のクラスター。新しく追加したノードがクラスタ内のデータに追いついたり、クラスタに再参加したノードがクラスタ離脱時から現在までに異なるトランザクションデータに追いついたりするプロセスを分散リカバリと呼びます。

クラスタへの参加を申請したノードは、まずgroupreplicationapplierチャネルのリレーログを確認し、クラスタからまだ同期されていないノードのトランザクションデータを確認します。クラスタに再参加したノードの場合、ノードはクラスタを離脱してから再生されていないトランザクション データとクラスタ内の最新データを検索し、これらの非同期トランザクションを最初に適用します。クラスターに新しく追加されたノードの場合、完全なデータ リカバリをブート ノードから直接実行できます。

その後、新しく追加されたノードは、状態転送のためにクラスタ内の既存のオンライン ノード (ブート ノード) との接続を確立します。新しく追加されたノードは、クラスターに参加する前、またはクラスター内のブート ノードからクラスターを離脱した後に同期されていないデータを同期します。これらのさまざまなトランザクションは、クラスター内のブート ノードによって提供されます。次に、新しく追加されたノードは、クラスター内のブートストラップ ノードから同期された未適用のトランザクションを適用します。このとき、クラスターへの参加を申請しているノードは、状態転送プロセス中に新しいトランザクションによって書き込まれたデータをクラスターに適用します。 (このとき、クラスタ内で新たに書き込まれたデータはキャッシュキューに一時的に格納され、ディスクには書き込まれません。) この処理が完了すると、新しく追加したノードのデータは比較可能なレベルになります。クラスター全体のデータを含む状態になり、ノードはオンライン状態に設定されます。

注: クラスターに参加する新しいノードは、以前にこのクラスターに存在したことがあるかどうかに関係なく、まずオンライン ノードをランダムに選択して、ノード間のさまざまなトランザクションを同期します。そしてクラスター。

グループ レプリケーションでは、次の方法を使用して分散リカバリ時の状態転送を実装します。

クローン プラグインの機能を使用して、リモート クローン作成操作を実行します。プラグインは、MySQL 8.0.17 以降のサポートからダウンロードできます。この方法を使用するには、ブートノードと新しく参加するノードに事前にクローン作成プラグインがインストールされている必要があります。グループ レプリケーションは、必要なクローン プラグイン設定を自動的に構成し、リモート クローン操作を管理します。

ブート ノードのバイナリ ログからデータをコピーし、これらのトランザクションを新しく参加したノードに適用します。この方法では、ブート ノードと参加ノードの間に groupreplicationrecovery と呼ばれる標準の非同期レプリケーション チャネルが確立される必要があります。

参加ノードで STARTGROUP_REPLICATION を実行すると、グループ レプリケーションは状態転送に上記の方法の最適な組み合わせを自動的に選択します。これを行うために、グループ レプリケーションは、クラスター内のどの既存ノードがブート ノードとして使用するのに適しているか、参加ノードがブート ノードから必要とするトランザクションの数、およびバイナリ ログ ファイルにトランザクションが存在しなくなっているかどうかを確認します。クラスター内の任意のノード。参加ノードとブート ノードの間に大きなトランザクション ギャップがある場合、または必要なトランザクションの一部がブート ノードのバイナリ ログ ファイルにない場合、グループ レプリケーションはリモート クローン操作を通じて分散リカバリを開始します。大きなトランザクション ギャップがない場合、またはクローン プラグインがインストールされていない場合、グループ レプリケーションはブート ノードのバイナリ ログから状態を直接転送します。

リモート クローン操作中、参加ノード上の既存のデータは削除され、ブート ノード データのコピーに置き換えられます。リモート クローン作成操作が完了し、新しく参加したノードが再起動されると、ブート ノードのバイナリ ログからの状態転送が続行され、リモート クローン作成操作中にクラスターによって書き込まれた増分データが取得されます。

ブート ノードのバイナリ ログからの状態転送中に、新しく参加するノードは、ブート ノードのバイナリ ログから必要なトランザクションをコピーして適用し、バイナリ ログに新しい記録が記録されるまで、受信したトランザクションを適用します。クラスター。 (参加ノードがクラスターに正常に参加すると、対応するビュー変更イベントがバイナリ ログに記録されます。) このプロセス中、参加ノードはクラスターに適用される新しいトランザクション データをバッファーに入れます。バイナリ ログからの状態転送が完了すると、新しく参加したノードはバッファされたトランザクションを適用します。

参加ノードがクラスターのすべてのトランザクションで最新の状態になると、ノードはオンラインに設定され、通常のノードとしてクラスターに参加できるようになり、分散リカバリが完了します。

ps: バイナリ ログからの状態転送は、グループ レプリケーションを使用した分散リカバリの基本メカニズムであり、レプリケーション グループ内のブート ノードと結合ノードがクローン作成をサポートするように設定されていない場合に使用します。 。バイナリ ログからの状態転送は従来の非同期レプリケーションに基づいているため、クラスターに参加している MySQL サーバーにクラスターのデータがまったくない場合、またはデータが非常に古いバックアップから取得されている場合、回復に時間がかかる可能性があります。 . 最新データです。したがって、この場合、MySQL サーバーをクラスターに追加する前に、クラスター内に既に存在するノードのかなり新しいスナップショットを転送して、クラスターのデータを使用してサーバーをセットアップすることをお勧めします。これにより、分散リカバリに必要な時間が最小限に抑えられ、保持および転送するバイナリ ログ ファイルの数が少なくなるため、ブート ノードへの影響が軽減されます。

2. 分散リカバリのための接続

分散リカバリ中の状態転送のために参加ノードが既存ノードのブート ノードに接続する場合、参加ノードはブートストラップ ノードはクライアントとして機能し、ブートストラップ ノードはサーバーとして機能します。この接続 (非同期レプリケーション チャネル GroupReplicationRecovery を使用) を介してブート ノードのバイナリ ログから状態転送が発生すると、参加ノードはレプリカとして機能し、ブート ノードはソースとして機能します。この接続を介してリモート クローン作成操作を実行する場合、新しく追加されたノードは完全なデータ レシーバーとして機能し、ブート ノードは完全なデータ プロバイダーとして機能します。グループ レプリケーションのコンテキスト外でロールに適用される構成設定は、グループ レプリケーション固有の構成設定または動作によって上書きされない限り、グループ レプリケーションにも適用されます。

既存のノードが分散リカバリのために新しく参加したノードに提供する接続は、グループ レプリケーションがクラスター内のノード間の通信に使用する接続とは異なります。

グループ通信エンジンはグループ レプリケーション (XCom、Paxos バリアント) に使用され、リモート XCom インスタンス間の TCP 通信に使用される接続は groupreplicationlocal_address システム変数によって指定されます。この接続は、クラスター内のオンライン ノード間の TCP/IP メッセージングに使用されます。ローカル インスタンスとの通信は、メモリ内の共有トランスポート チャネルを使用して行われます。

分散リカバリの場合、MySQL8.0.20 までは、クラスタ内のノードは、MySQL サーバーのホスト名とポート システム変数で指定されたとおり、参加ノードへの標準 SQL クライアント接続を提供していました。 report_port システム変数で代替ポート番号が指定されている場合は、そのポート番号が代わりに使用されます。

MySQL 8.0.21 以降、グループ メンバーは分散リカバリ エンドポイントの代替リストをメンバーに参加するための専用クライアント接続として使用できるため、メンバーの通常のクライアント ユーザーから独立した接続を分散スタイルのリカバリの制御に使用できるようになります。このリストは、groupReplicationAdvertiseRecoveryEndpoints システム変数を使用して指定でき、メンバーはグループに参加するときに、分散回復エンドポイントのリストをグループに転送します。デフォルトでは、メンバーは以前のバージョンと同じ標準 SQL クライアント接続を引き続き提供します。

PS:

参加ノードが MySQLServer のシステム変数で定義されたホスト名を使用して他のノードを正しく識別できない場合、分散リカバリは失敗する可能性があります。 MySQL を実行しているオペレーティング システムには、DNS またはローカル設定を使用して、正しく構成された一意のホスト名があることが推奨されます。サーバーが SQL クライアント接続に使用するホスト名は、「パフォーマンススキーマ」ライブラリの ReplicationgroupMembers テーブルの Memberhost 列で確認できます。複数のグループ メンバーがオペレーティング システムによって設定されたデフォルトのホスト名を外部に持つ場合、参加ノードがホスト名を正しいアドレスに解決できず、分散リカバリに接続できなくなる可能性があります。この場合、MySQL Server の report_host システム変数を使用して、各サーバーによって外部化された一意のホスト名を構成できます。

ノードに参加して分散リカバリのための接続を確立する手順は次のとおりです。

ノードがクラスターに参加すると、ノードはクラスターに含まれるシード ノードを使用します。 groupreplicationgroupseeds システム変数のリスト 最初に、このリストで指定された groupreplicationlocaladdress を使用して接続を作成します。シード ノードはクラスター データのサブセットである場合があります。

この接続を通じて、シード ノードはグループ レプリケーションのメンバーシップ サービスを使用して、クラスター内のすべてのオンライン ノードのリストをビューの形式で参加ノードに提供します。メンバーシップ情報には、分散リカバリ用に各メンバーによって提供される分散リカバリ エンドポイントまたは標準 SQL クライアント接続の詳細が含まれます。

ノードに参加 このリストから適切なオンライン ノードを分散リカバリのブート ノードとして選択します。

ノードに参加 ブート ノードの分散リカバリ エンドポイントを使用してブート ノードに接続し、リストを押します。各エンドポイントへの接続は、 で指定された順序で順番に試行されます。ブート ノードがエンドポイントを提供しない場合、参加ノードはブート ノードの標準 SQL クライアント接続を使用して接続を試みます。接続の SSL 要件は、groupreplicationrecoveryssl* オプションで指定されます。

参加ノードが指定されたブート ノードに接続できない場合は、別の適切なブート ノードとの接続が再試行されます。参加ノードが接続を確立せずにエンドポイントのブロードキャスト リストを使い果たした場合、ブート ノードの標準 SQL クライアント接続にはフォールバックせず、別のブート ノードに切り替えて接続の再確立を試みます。

参加ノードがブート ノードとの分散リカバリ接続を確立すると、状態転送にその接続が使用されます。参加ノードのログには、使用された接続のホストとポートが表示されます。リモート クローン操作が使用されている場合、操作の終了時に参加ノードが再起動されると、新しいブート ノードとの接続が確立され、ブート ノードのバイナリ ログから状態転送が実行されます。これは、リモート クローン操作に使用されるブート ノードとは異なる接続である場合もあれば、ブート ノードと同じ接続である場合もあります。いずれにせよ、分散リカバリは同じ方法でブート ノードへの接続を確立します。

2.1 分散リカバリ終了アドレスの検索

groupreplicationadvertiserecoveryendpoints システム変数は、分散リカバリ終了によって提供される IP アドレスとして機能し、MySQL Server 用に構成する必要はありません (つまり、MySQL Server 用に構成する必要はありません)。 adminaddress システム変数または bindingaddress システム変数で設定する必要はありません)。

MySQL Server の分散リカバリ端に提供されるポートを構成します。これは、port、reportport、または adminport システム変数で指定する必要があります。 TCP/IP 接続はこれらのポートでリッスンする必要があります。 adminport が指定されている場合、分散リカバリに使用されるレプリケーション ユーザーには、接続するために SERVICECONNECTIONADMIN 権限が必要です。 adminport を選択すると、分散リカバリ接続が通常の MySQL クライアント接続から分離されます。

結合ノードは、リストで指定された順序で各エンドポイントを順番に試行します。 groupreplicationadvertiserecoveryendpoints がエンドポイントのリストではなく DEFAULT に設定されている場合、標準 SQL クライアント接続が提供されます。標準 SQL クライアント接続は、分散回復エンドポイント リストに自動的には含まれないため、ブート ノードのエンドポイント リストが接続なしで使い果たされた場合はバックアップとして使用されません。標準 SQL クライアント接続を複数の分散リカバリ エンドポイントの 1 つとして提供する場合は、groupreplicationadvertiseadvertiserecovery_endpoints で指定されたリストにそれを明示的に含める必要があります。最後の接続手段としてこれを最後に置くことができます。

groupreplicationipallowlist (MySQL 8.0.22 以降) または groupreplicationipwhitelist システムによって指定されたグループ レプリケーション許可リストに、グループ メンバーの分散リカバリ エンドポイント (またはエンドポイントが提供されていない場合は標準 SQL クライアント接続) を追加する必要はありません。変数。許可リストは、各ノードの groupreplicationlocal_address で指定されたアドレスにのみ適用されます。参加ノードは、分散リカバリ用の 1 つ以上のアドレスを取得するために、許可リストで許可されているクラスターへの初期接続を持っている必要があります。

システム変数を設定し、STARTGROUP_REPLICATION ステートメントを実行すると、リストされた分散リカバリ エンドポイントが検証されます。リストを正しく解析できない場合、またはサービスがリストをリッスンしていないためにホスト上のエンドポイントに到達できない場合、グループ レプリケーションはエラーを記録し、開始に失敗します。

2.2 分散リカバリ圧縮

MySQL 8.0.18 では、ブート ノードのバイナリ ログの状態転送メソッドを使用して、分散リカバリの圧縮をオプションで構成できます。ネットワーク帯域幅が制限されており、リーダー ノードが参加ノードに多くのトランザクションを転送する必要がある状況では、圧縮は分散リカバリに利点をもたらします。 groupreplicationrecoverycompressionalgorithm および groupreplicationrecoveryzstdcompression_level システム変数は、ブート ノードのバイナリ ログから状態転送を実行するときに使用される、許可される圧縮アルゴリズムと zstd 圧縮レベルを構成します。

これらの圧縮設定は、リモート クローン作成操作には適用されません。リモート クローン操作が分散リカバリに使用される場合、クローン プラグインの cloneenablecompression 設定が適用されます。

2.3 分散リカバリのユーザー

分散リカバリでは、グループ レプリケーションがノード間の直接レプリケーション チャネルを確立できるように、適切な権限を持つレプリケーション ユーザーが必要です。レプリケーション ユーザーには、適切な権限も必要です。レプリケーション ユーザーがリモート クローン作成操作でクローン ユーザーとしても機能する場合、レプリケーション ユーザーは、クローン ユーザーとして機能するために、ブート ノード上でリモート クローン作成関連の権限 (BACKUP_ADMIN 権限) も持っている必要があります。ブート ノード上で、リモート クローン作成操作のためにユーザーのクローンを作成します。これに加えて、クラスタ内のすべてのノードで分散リカバリに同じレプリケーション ユーザーを使用する必要があります。

2.4 分散リカバリと SSL 認証

分散リカバリに使用される SSL は、通常のグループ通信に使用される SSL とは別に構成されます。これは、サーバーの SSL 設定と groupreplicationssl_mode システム変数によって決まります。分散リカバリ接続の場合、専用のグループ レプリケーション分散リカバリ SSL システム変数を使用して、分散リカバリ専用の証明書とキーの使用を構成できます。

デフォルトでは、分散リカバリ接続には SSL は使用されません。 groupreplicationrecoveryusessl=ON を設定して有効にしてから、グループ レプリケーション分散リカバリ SSL システム変数を構成し、SSL を使用するようにレプリケーション ユーザーを設定します。

SSL を使用するように分散リカバリを構成すると、グループ レプリケーションはこの設定をリモート クローン操作とブート ノードのバイナリ ログからの状態転送に適用します。グループ レプリケーションは、対応するグループ レプリケーションの分散回復オプション (groupreplicationrecoverysslca、groupreplicationrecoverysslcert、および groupreplicationrecoverysslkey) の設定と一致するように、クローン SSL オプション (clonesslca、clonesslcert、および clonesslkey) を自動的に構成します。

分散リカバリに SSL が使用されておらず (groupreplicationrecoveryusessl が OFF に設定されている)、グループ レプリケーションのレプリケーション ユーザー アカウントが cachingsha2password プラグイン (MySQL 8.0 のデフォルト) または sha256password プラグインを使用して認証されている場合、RSA キーこのペアはパスワード交換に使用されます。この場合、groupreplicationrecoverypublickeypath システム変数を使用して RSA 公開キー ファイルを指定するか、groupreplicationrecoverygetpublic_key システム変数を使用して公開キーを要求します。そうしないと、エラー報告により分散応答全体が失敗します。

3. 分散リカバリのためのクローン プラグインの使用

MySQLServer のクローン プラグインは、MySQL8.0.17 から利用可能です。クラスター内の分散リカバリにリモート クローン操作を使用する場合は、この機能をサポートするように既存のノードと参加ノードを事前にプロビジョニングする必要があります。クラスターでこの機能を使用したくない場合は、これを設定しないでください。その場合、グループ レプリケーションはバイナリ ログ内の状態転送のみを使用します。

クローン作成プラグインを使用するには、少なくとも 1 つの既存のクラスター ノードと参加ノードが、リモート クローン作成操作をサポートするように事前設定されている必要があります。少なくとも、クローン プラグインがブート ノードと結合ノードにインストールされている必要があり、分散リカバリ用のレプリケーション ユーザーに BACKUPADMIN 権限が付与され、groupreplicationclonethreshold システム変数が適切なレベルに設定されている必要があります。 (デフォルトでは、GTID シーケンスで許可される最大値です。つまり、通常の状況では、結合ノードによって要求されたトランザクションがグループのどのメンバーにも存在しない場合を除き、バイナリ ログに基づくステータス送信が常に優先されることを意味します)このとき、クローン作成機能が無効になっている場合、システム変数の値がどのように設定されていても、クローン作成による分散リカバリがトリガーされます。たとえば、新しく初期化されたサーバーがグループへの参加を申請した場合です。クローン作成機能を使用したくない場合は、インストールしないでください。および構成) ブート ノードの可用性を最大限に確保するには、現在および将来のすべてのクラスター ノードをリモート クローン作成操作をサポートするように設定することをお勧めします。そのため、後でサーバーがクラスターに参加するときに、リモート クローン作成操作を使用してクラスター内の最新データを迅速に取得できます。

リモート クローン操作では、ブート ノードから結合ノードにデータを転送する前に、結合ノード内のユーザー作成のテーブル スペースとデータが削除されます。操作が途中で予期せず終了した場合、参加ノードには部分的なデータが残っているか、まったくデータが残っていない可能性があります。この問題は、グループ レプリケーションが自動的に実行するリモート クローン操作を再実行することで解決できます。

これは主に、リモートクローン作成時に DATADIRECTORY サブオプションを使用してデータの保存パスを指定する場合に当てはまります。パスを指定すると、データは指定されたディレクトリ、つまりデータに保存されます。クローン作成後は、クローンを操作するインスタンスとは関係ありません。手動でインスタンスを起動し、クローンデータが保存されているディレクトリを datadir に指定する必要があります。もちろん、MGR プラグインが自動的にリトライを実行することもできますリモート クローンの操作 (クローン操作で DATA DIRECTORY サブオプションが指定されていないことを確認する必要があります。この場合、リモート クローンのデータは、リモート クローンを操作するサーバーのデータを上書きします。リモート クローンの実行後)操作が完了すると、リモート クローンを操作するサーバーがクローン データに基づいて自動的に再起動します)。さらに、クローン作成プラグインは、グループ レプリケーションの管理とメンテナンスをより自動化するためにグループ レプリケーションと組み合わせて使用​​されますが、クローン作成プラグインをクラスタ内で実行する必要はありません（MGR プラグインは必要ありません）。インストールする必要があります)。

3.1 クローン作成の基本条件

グループ レプリケーションの場合、分散リカバリ用のクローン プラグインを使用する場合は、次の点と相違点に注意する必要があります。

既存のクラスター ノードと参加ノードには、クローン プラグインがインストールされ、アクティブになっている必要があります。

ブート ノードと参加ノードは同じオペレーティング システム上で実行され、同じ MySQL Server バージョンを持っている必要があります (クローン プラグインをサポートするには MySQL 8.0.17 以降である必要があります)。したがって、メンバーが異なるバージョンの MySQL を実行しているクラスターではクローン作成は機能しません。

ブート ノードと参加ノードには「グループ レプリケーション」プラグインがインストールされアクティブ化されている必要があり、ブート ノードでアクティブ化されている他のすべてのプラグイン (キーリング プラグインなど) も参加ノードでもアクティブである必要があります。

分散リカバリが SSL を使用するように構成されている場合 (groupreplicationrecoveryusessl=ON)、グループ レプリケーションはこの設定をリモート クローン操作に適用します。グループ レプリケーションは、クローン SSL オプション (clonesslca、clonesslcert、および clonesslkey) の設定を、対応するグループ レプリケーションの分散リカバリ オプション (groupreplicationrecoverysslca、groupreplicationrecoverysslcert、および groupreplicationrecoverysslkey) の設定と一致するように自動的に構成します。

クラスターに参加するために、参加ノードの clonevaliddonor_list システム変数に有効なブート ノード リストを設定する必要はありません。 MGR が既存のクラスター ノードからブート ノードを自動的に選択した後、グループ レプリケーションはこの設定を自動的に構成します。リモート クローン作成操作では、クラスター メンバー間の内部通信用のアドレスとポートではなく、サーバーの SQL プロトコルのホスト名とポートが使用されることに注意してください。

クローン作成プラグインには、リモート クローン作成操作のネットワーク負荷とパフォーマンスへの影響を管理するための多数のシステム変数があります。これらの設定はグループ レプリケーションでは構成されないため、必要に応じてそれらを確認して設定することも、デフォルトとして設定することもできます。分散リカバリにリモート クローン操作を使用する場合、クローン プラグインの cloneenablecompression 設定が既存のグループ レプリケーション圧縮設定に影響します。

グループ レプリケーションは、参加ノードでリモート クローン操作を呼び出すために、すでに CLONE_ADMIN 権限を持っている内部 mysql.session ユーザーを使用するため、特別な設定は必要ありません。

グループ レプリケーションは、リモート クローン操作のブート ノード上のクローン ユーザーとして、分散リカバリ用に設定されたレプリケーション ユーザーを使用します。したがって、このレプリケーション ユーザーには、クローン作成可能なすべてのクラスター ノードに対する BACKUP_ADMIN 権限が与えられる必要があります。グループ レプリケーション用にノードを構成する場合、参加ノードがある場合は、そのノードのレプリケーション ユーザーにもこの権限を付与する必要があります。これは、参加ノードがクラスターに参加した後、他の参加ノードのブート ノードとして機能できるためです。各クラスター ノードの分散リカバリには同じレプリケーション ユーザーが使用されます。既存のノード上のレプリケーション ユーザーにこの権限を付与するには、バイナリ ログが無効になっている各クラスタ ノード、またはバイナリ ログが有効になっているクラスタのプライマリ ノードでこのステートメントを個別に実行します。次のステートメント:

GRANT BACKUP_ADMIN ON *.* TO *rpl_user*@'%';

STARTGROUPREPLICATION を使用する前に、CHANGE MASTER TO を使用して、ユーザー資格情報を提供したサーバー上でレプリケーション ユーザー資格情報を指定した場合は、リモート クローン作成操作を実行する前に、レプリケーション メタデータ リポジトリからユーザー資格情報を必ず削除してください。また、参加メンバーに groupreplicationstartonboot=OFF が設定されていることを確認してください。ユーザー資格情報が設定解除されていない場合、リモート クローン操作中に参加メンバーに転送されます。元のメンバーまたはそこから複製されたメンバーに保存されている資格情報を使用して、GroupReplicationRecovery チャネルが誤って開始される可能性があります。サーバーの起動時 (リモート クローン操作後を含む) にグループ レプリケーションを自動的に開始すると、保存されているユーザー資格情報が使用され、START GROUPREPLICATION コマンドで指定されていない場合は分散リカバリ資格情報も使用されます。

3.2 クローン作成のしきい値

クローン作成をサポートするようにグループ メンバーを設定した後、groupreplicationclonethreshold システム変数は、分散リカバリでリモート クローン作成操作を使用するためのトランザクション数で表されるしきい値を指定します。ブートストラップ ノードと参加ノード間のトランザクションの数がこの数より大きい場合、技術的に可能な場合は、リモート クローン操作を使用して状態を参加ノードに転送します。グループ レプリケーションは、既存のグループ メンバーの gtideexecuted セットに基づいて、しきい値を超えているかどうかを計算します。トランザクション ギャップが大きい場合にリモート クローン操作を使用すると、事前にクラスターのデータを手動でサーバーに転送することなく、クラスターに新しいメンバーを追加できます。また、遅れているノードがより効率的にデータを追いつくこともできます。

groupreplicationclone_threshold グループ レプリケーション システム変数のデフォルト設定は非常に高い (GTID で許可されるトランザクションの最大シーケンス番号) ため、バイナリ ログから状態を転送できる場合は常にクローン作成が事実上無効になります。グループ レプリケーションが状態転送により適したリモート クローン操作を選択できるようにするには、クローン作成のトランザクション間隔として使用するトランザクションの数を指定するシステム変数を設定します。

PS:

アクティブなクラスターでは、groupreplicationclone_threshold にこれより低い設定を使用しないでください。リモート クローン操作の進行中にクラスター内でしきい値を超えるトランザクションが発生した場合、参加メンバーは再起動後にリモート クローン操作を再度トリガーし、無期限に続行できます。これを回避するには、リモート クローン操作にかかる期間中にクラスター内で発生すると予想されるトランザクションの数よりも大きい、信頼できる数値にしきい値を設定してください。

ブート ノードのバイナリ ログから状態転送を実行できない場合、グループ レプリケーションは、その時点のしきい値に関係なく、リモート クローン操作を実行しようとします。たとえば、メンバーに参加するために必要なトランザクションが実行されているためです。既存のグループ メンバーはバイナリ ログでは使用できません。グループ レプリケーションは、gtidpurged された既存のグループ メンバーのセットに基づいてこれを識別します。必要なトランザクションがどのメンバーのバイナリ ログ ファイルにも存在しない場合、groupreplicationclonethreshold システム変数を使用してクローン作成を非アクティブ化することはできません。この場合、結合ノードにデータを手動で転送する唯一のオプションがクローン作成であるためです。

3.3 クローン操作

クラスター ノードを設定し、クローン作成のためにノードに参加すると、グループ レプリケーションがリモート クローン作成操作を管理します。データのサイズに応じて、リモート クローン操作が完了するまでに時間がかかります。

パフォーマンススキーマ.cloneprogress テーブルには、クローン作成操作全体の各ステージとそれに対応するステージ情報が記録されます。各ステージでは、レコードの行が生成されます (このテーブルには、クローン作成操作のプロセス情報が 1 つだけ記録されることに注意してください)。次へ クローン作成操作を実行すると、最後の情報が上書きされます)

select * from clone_progress;
+------+-----------+-----------+---------------------------- 
+----------------------------+---------+------------+-------- 
----+------------+------------+---------------+
| ID | STAGE | STATE | BEGIN_TIME | END_TIME | THREADS | 
ESTIMATE | DATA | NETWORK | DATA_SPEED | NETWORK_SPEED |
+------+-----------+-----------+---------------------------- 
+----------------------------+---------+------------+------- 
-----+------------+------------+---------------+
| 1 | DROP DATA | Completed | 2019-10-08 16:46:58.757964 | 
2019-10-08 16:46:59.128436 | 1 | 0 | 0 | 0 | 0 | 0 |
| 1 | FILE COPY | Completed | 2019-10-08 16:46:59.128766 | 
 2019-10-08 16:47:16.857536 | 8 | 8429731840 | 8429731840 | 
 8430190882 | 0 | 0 |
| 1 | PAGE COPY | Completed | 2019-10-08 16:47:16.857737 | 
 2019-10-08 16:47:17.159531 | 8 | 0 | 0 | 785 | 0 | 0 |
| 1 | REDO COPY | Completed | 2019-10-08 16:47:17.159748 | 
2019-10-08 16:47:17.460516 | 8 | 2560 | 2560 | 3717 | 0 | 0 
|
| 1 | FILE SYNC | Completed | 2019-10-08 16:47:17.460788 | 
2019-10-08 16:47:20.926184 | 8 | 0 | 0 | 0 | 0 | 0 |
| 1 | RESTART | Completed | 2019-10-08 16:47:20.926184 |

| 1 | RESTART | Completed | 2019-10-08 16:47:20.926184 | 
2019-10-08 16:47:28.623732 | 0 | 0 | 0 | 0 | 0 | 0 |
| 1 | RECOVERY | Completed | 2019-10-08 16:47:28.623732 | 
2019-10-08 16:47:34.898453 | 0 | 0 | 0 | 0 | 0 | 0 |
+------+-----------+-----------+---------------------------- 
+----------------------------+---------+------------+------- 
-----+------------+------------+---------------+
7 rows in set (0.00 sec)
select * from clone_status\G
*************************** 1. row ***************************
ID: 1
PID: 0
STATE: Completed
BEGIN_TIME: 2019-10-08 16:46:58.758
END_TIME: 2019-10-08 16:47:34.898
SOURCE: 10.10.30.162:3306
DESTINATION: LOCAL INSTANCE
ERROR_NO: 0
ERROR_MESSAGE:
BINLOG_FILE: mysql-bin.000022
BINLOG_POSITION: 222104704
GTID_EXECUTED: 320675e6-de7b-11e9-b3a9-5254002a54f2:1-4,
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-2771494
1 row in set (0.01 sec)

PS:

状態転送が完了すると、グループ レプリケーションによって参加ノードが再起動されますプロセスを完了します。たとえば、レプリケーション ユーザー資格情報が START GROUPREPLICATION ステートメントに指定されているなどの理由で、結合ノードに groupreplicationstartonboot=OFF が設定されている場合は、再起動後に START GROUPREPLICATION を手動で再度公開する必要があります。 groupreplicationstartonboot=ON およびグループ レプリケーションの開始に必要なその他の設定が構成ファイルまたは SET PERSIST ステートメントで設定されている場合、介入なしで参加ノードがオンラインになった状態でプロセスが自動的に続行されます。

リモート クローン作成操作では、ブート ノードのデータ ディレクトリ内のさまざまなデータ ファイルが結合ノードにクローン作成されます (テーブルには構成情報やユーザー データなどが含まれる場合があります)。ただし、構成ファイルに保存されたグループ レプリケーション メンバーシップ設定 (グループ レプリケーションのローカル アドレス構成など) は複製されず、参加ノードに変更も加えられません。つまり、グループ レプリケーションに関連する構成は自分で構成する必要があり、クラスター内の既存のメンバーと競合することはできません。リモート クローン作成操作はデータ ファイルのクローン作成のみを担当し、構成情報のクローンは作成されません (もちろん、一部の構成情報が存在する場合)クローン作成操作の場合、データとしてもクローンされるため、テーブルに保存されます。

如果远程克隆过程花费很长时间，则在MySQL 8.0.22之前的发行版中，在该时间段内为该集群累积的一组认证信息可能会变得太大而无法传输给加入成员。在这种情况下，加入成员会记录一条错误消息，并且不会加入该集群。从MySQL 8.0.22开始，组复制以不同的方式管理应用事务的垃圾收集过程，以避免发生这种情况。在早期版本中，如果确实看到此错误，则在远程克隆操作完成之后，请等待两分钟，以允许进行一轮垃圾收集，以减小集群的认证信息的大小。然后在加入成员上发出以下声明，以使其停止尝试应用先前的认证信息集：

RESET SLAVE FORCHANNEL group_replication_recovery;
RESET REPLICA FOR CHANNEL group_replication_recovery;（从8.0.22开始）

引导节点中用于组复制专用通道groupreplicationrecovery的用户凭证（复制用户和密码），在克隆操作完成之后，会被新成员使用，所以，该用户和密码及其权限必须在新成员中也有效。因此，所有组成员才能够使用相同的复制用户和密码通过远程克隆操作接收状态传输进行分布式恢复。但是，组复制会保留与使用SSL相关的组复制通道设置，这些设置对单个成员来说可以是惟一的（即，每个组成员使用不同的复制用户和密码）。如果使用了PRIVILEGECHECKSUSER帐户来帮助保护复制应用线程（从MySQL8.0.18开始，可以创建一个具有特定权限的用户账号，然后将其指定为PRIVILEGECHECKSUSER帐户，这样可以防止将未经授权或意外将具有特权的账号用于组复制通道），则在克隆操作完成之后新加入成员不会使用该用户帐户作为组复制通道的用户。此时必须为组复制通道手工指定合适的复制用户。

如果引导节点用于groupreplicationrecovery复制通道的复制用户凭据已使用CHANGE MASTER TO语句存储在复制元数据存储库中，则在克隆后将它们转移到加入成员并由其使用，并且它们在此处必须有效。因此，使用存储的凭据，所有通过远程克隆操作接收状态转移的组成员都会自动接收复制用户和密码，进行分布式恢复。如果在START GROUPREPLICATION语句上指定了复制用户凭据，则这些凭据将用于启动远程克隆操作，但是在克隆后它们不会传输到加入节点并由其使用。如果不希望将凭据转移到新的server上并记录在那里，确保在进行远程克隆操作之前取消设置它们，并使用START GROUPREPLICATION代替提供它们。

ps:如果已使用PRIVILEGECHECKSUSER帐户来帮助保护复制应用程序，则从MySQL 8.0.19开始，会将PRIVILEGECHECKSUSER帐户以及来自引导节点的相关设置克隆出来。如果将加入节点设置为在启动时启动组复制，它将自动使用该帐户在相应的复制通道上进行权限检查。（在MySQL 8.0.18中，由于许多限制，建议不要将PRIVILEGECHECKSUSER帐户用于组复制通道。）

3.4克隆的其他用处

组复制启动并管理用于分布式恢复的克隆操作。设置为支持克隆的组成员也可以参与用户手动启动的克隆操作。例如，可能希望通过从组成员作为引导节点来进行克隆来创建新的MySQL实例，但是不希望新的服务器实例立即加入或可能永远不会加入该集群。

在所有支持克隆的发行版中，可以手动启动涉及停止了组复制的组成员的克隆操作。由于克隆要求引导节点和接收数据的节点上的克隆插件必须匹配，因此即使不希望该实例加入集群，也必须在另一个实例上安装并激活组复制插件。可以通过发出以下语句来安装插件：

INSTALL PLUGIN group_replication SONAME'group_replication.so';

在MySQL 8.0.20之前的发行版中，如果操作涉及正在运行“组复制”的组成员，则无法手动启动克隆操作。从MySQL8.0.20开始，只要克隆操作不会删除和替换接收者上的数据，就可以执行此操作。因此，如果正在运行组复制，则用于启动克隆操作的语句必须包含DATA DIRECTORY子句。

以上がMySQL 分散リカバリ インスタンスの分析の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。