グループは、最大 9 台のサーバーで構成できます。 9 つのメンバーを持つグループに別のサーバーを追加しようとすると、リクエストは拒否されます。 この制限は、安定したローカルエリアネットワーク上でグループが確実に実行される安全な境界としてのテストおよびベンチマークから特定されています。

グループ内のサーバーは、ピアツーピア TCP 接続を開いてグループ内の他のサーバーに接続します。 これらの接続は、グループ内のサーバー間の内部通信およびメッセージの受渡しにのみ使用されます。 このアドレスは、group_replication_local_address 変数によって構成されます。

ブートストラップフラグは、メンバーにグループを create に指示し、初期シードサーバーとして機能します。 グループに参加する 2 つ目のメンバーは、グループに追加するために構成を動的に変更するようにグループをブートストラップしたメンバーに依頼する必要があります。

メンバーは、2 つのシナリオでグループをブートストラップする必要があります。 グループが最初に作成されたとき、またはグループ全体を停止して再起動したとき。

ユーザー資格証明は、CHANGE REPLICATION SOURCE TO ステートメント (MySQL 8.0.23 の場合) または CHANGE MASTER TO ステートメント (MySQL 8.0.23 の場合) を使用して、group_replication_recovery チャネルの資格証明として永続的に設定できます。 または、MySQL 8.0.21 から、グループレプリケーションが開始されるたびに START GROUP_REPLICATION ステートメントで指定できます。

CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO を使用して設定されたユーザー資格証明は、サーバー上のレプリケーションメタデータリポジトリにプレーンテキストで格納されますが、START GROUP_REPLICATION で指定されたユーザー資格証明はメモリーにのみ保存され、STOP GROUP_REPLICATION ステートメントまたはサーバーの停止によって削除されます。 したがって、START GROUP_REPLICATION を使用してユーザー資格証明を指定すると、不正なアクセスからグループレプリケーションサーバーを保護するのに役立ちます。 ただし、この方法は、group_replication_start_on_boot システム変数で指定された Group Replication の自動起動とは互換性がありません。 詳細は、セクション18.5.3.1「分散リカバリのためのセキュアなユーザー資格証明」を参照してください。

直接ではありませんが、MySQL Group レプリケーションは、グループ内のすべてのサーバーが同じ量のデータをレプリケートする、何も共有しない完全レプリケーションソリューションです。 したがって、トランザクションのコミット操作の結果として、グループ内のあるメンバーが N バイトをストレージに書き込む場合、トランザクションはどこにでもレプリケートされるため、他のメンバーのストレージにも約 N バイトが書き込まれます。

ただし、最初にトランザクションを実行したときに元のメンバーが実行する必要があったのと同じ量の処理を他のメンバーが実行する必要がない場合は、変更がより高速に適用されます。 トランザクションは、行変換の適用にのみ使用される形式でレプリケートされ、トランザクションを再実行する必要はありません (行ベースの形式)。

さらに、変更が行ベースの形式で伝播および適用される場合、それらは最適化されたコンパクトな形式で受信され、元のメンバーと比較して必要な IO 操作の数が削減される可能性があります。

要約すると、競合のないトランザクションをグループ内の様々なメンバーに分散することで、処理をスケールアウトできます。 また、リモートサーバーは安定したストレージへの読取り/変更/書込み変更に必要な変更のみを受信するため、IO 操作のごく一部をスケールアウトできます。

同期化のためにサーバーが相互に常に相互作用する必要があるため、追加のロードが必要になります。 これ以上のデータ量を定量化することは困難です。 また、グループのサイズによっても異なります (3 台のサーバは、グループ内の 9 台のサーバよりも帯域幅要件に応力を軽減します)。

また、サーバー同期部分およびグループメッセージングではより複雑な作業が行われるため、メモリーおよび CPU フットプリントも大きくなります。

はい。ただし、各メンバー間のネットワーク接続は信頼性が高く、適切なパフォーマンスを備えている必要があります。 最適なパフォーマンスを得るには、低レイテンシで高帯域幅のネットワーク接続が必要です。

ネットワーク帯域幅のみに問題がある場合、セクション18.6.3「メッセージ圧縮」 を使用して必要な帯域幅を減らすことができます。 ただし、ネットワークがパケットをドロップし、再送信とエンドツーエンドの待機時間が長くなると、スループットと待機時間の両方に悪影響を与えます。

これは、接続の問題の理由によって異なります。 接続の問題が一時的で、障害検出で認識されないほど迅速に再接続できる場合、サーバーはグループから削除されない可能性があります。 接続性の問題が長い場合、障害検出機能は最終的に問題を疑い、サーバーはグループから削除されます。

MySQL 8.0 から、グループに残っているメンバーまたはグループに再参加するメンバーの可能性を高めるために、次の 2 つの設定を使用できます:

サーバーがグループから削除され、自動再結合の試行が成功しない場合は、再度参加する必要があります。 つまり、サーバーがグループから明示的に削除された後、手動で再結合する (またはスクリプトで自動的に再結合する) 必要があります。

メンバーがサイレントになると、他のメンバーはグループ構成からメンバーを削除します。 実際には、これはメンバーがクラッシュしたか、ネットワークが切断された場合に発生することがあります。

指定されたメンバーの指定されたタイムアウトが経過し、サイレントメンバーが作成されずに新しい構成が作成されると、障害が検出されます。

メンバーをグループから自動的に削除するタイミングのポリシーを定義する方法はありません。 メンバーが遅れている理由を確認し、それを修正するか、グループからメンバーを削除する必要があります。 そうでない場合、サーバーが非常に低速でフロー制御をトリガーすると、グループ全体も低速になります。 フロー制御は、必要に応じて構成できます。

いいえ。再構成のトリガーを担当する特別なメンバーはグループにありません。

どのメンバーも問題がある疑いがあります。 すべてのメンバーは、特定のメンバーが失敗したことを (自動的に) 同意する必要があります。 1 人のメンバーが、再構成をトリガーすることでグループから明示的に削除されます。 どのメンバーがメンバーの明示を担当しているかは、ユーザーが制御または設定できないものです。

グループレプリケーションは、可用性の高いレプリカセットを提供するように設計されています。データおよび書込みは、グループ内の各メンバーで複製されます。 単一システムが提供できるものを超えるスケーリングのために、オーケストレーションおよびシャーディングフレームワークが多数のグループレプリケーションセットを中心に構築されている必要があります。各レプリカセットは、データセット全体の特定のシャードまたはパーティションを保持および管理します。 このタイプの設定 (「「シャードクラスタ」」とも呼ばれる) では、読取りおよび書込みを制限なしで線形的にスケーリングできます。

sestatus -v を使用して検証できる SELinux が有効になっている場合は、Group Replication 通信ポートの使用を有効にする必要があります。 グループレプリケーションの TCP ポートコンテキストの設定を参照してください。

iptables が有効な場合は、マシン間の通信用にグループレプリケーションポートを開く必要があります。 各マシンに設定されている現在のルールを確認するには、iptables -L を発行します。 構成されているポートが 33061 の場合は、iptables -A INPUT -p tcp --dport 33061 -j ACCEPT を発行して、必要なポート経由の通信を有効にします。

グループレプリケーションで使用されるレプリケーションチャネルは、レプリカレプリケーションへの非同期ソースで使用されるレプリケーションチャネルと同じように動作し、リレーログに依存します。 relay_log 変数が変更された場合、またはオプションが設定されておらず、ホスト名が変更された場合は、エラーが発生する可能性があります。 この状況でのリカバリ手順については、セクション17.2.4.1「リレーログ」 を参照してください。 または、Group Replication で特に問題を修正する別の方法は、STOP GROUP_REPLICATION ステートメントを発行してから、START GROUP_REPLICATION ステートメントを発行してインスタンスを再起動することです。 Group Replication プラグインは、group_replication_applier チャネルを再度作成します。

グループレプリケーションでは、クライアントがメンバーと通信するために使用する SQL アドレスと、通信するためにグループメンバーによって内部的に使用される group_replication_local_address の間でネットワークトラフィックを分割するために、2 つのバインドアドレスが使用されます。 たとえば、ネットワークアドレス 203.0.113.1 および 198.51.100.179 に 2 つのネットワークインタフェースが割り当てられているサーバーがあるとします。 このような状況では、group_replication_local_address=203.0.113.1:33061 を設定して、内部グループのネットワークアドレスに 203.0.113.1:33061 を使用できます。 その後、198.51.100.179 for hostname および 3306 for the port を使用できます。 その後、クライアント SQL アプリケーションは 198.51.100.179:3306 のメンバーに接続します。 これにより、ネットワークごとに異なるルールを構成できます。 同様に、内部グループ通信をクライアントアプリケーションに使用されるネットワーク接続と分離して、セキュリティを向上させることができます。

グループレプリケーションではメンバー間のネットワーク接続が使用されるため、その機能はホスト名とポートの構成方法によって直接影響を受けます。 たとえば、Group Replication 分散リカバリプロセスでは、サーバーのホスト名とポートを使用して既存のグループメンバーへの接続が作成されます。 メンバーがグループに参加すると、performance_schema.replication_group_members にリストされているネットワークアドレス情報を使用してグループメンバーシップ情報を受け取ります。 そのテーブルにリストされているメンバーのいずれかが、グループから結合メンバーへの欠落データのドナーとして選択されます。

つまり、SQL ネットワークアドレスやグループシードアドレスなど、ホスト名を使用して構成する値は、完全修飾名であり、グループの各メンバーによって解決可能である必要があります。 たとえば、DNS、正しく構成された/etc/hosts ファイルまたはその他のローカルプロセスを使用して、これを確認できます。 サーバーで MEMBER_HOST 値を構成する場合は、グループに参加する前に、サーバーで --report-host オプションを使用して指定します。

サーバーで MEMBER_PORT を構成するには、report_port システム変数を使用して指定します。

グループレプリケーションがサーバーで開始されると、auto_increment_increment の値は group_replication_auto_increment_increment の値に変更され (デフォルトは 7 )、auto_increment_offset の値はサーバー ID に変更されます。 グループレプリケーションが停止すると、変更は元に戻されます。 これらの設定では、グループメンバーに対する書込みに対して重複する自動増分値が選択されないため、トランザクションがロールバックされます。 グループレプリケーションのデフォルトの自動増分値 7 は、使用可能な値の数とレプリケーショングループの最大許容サイズ (9 メンバー) のバランスを表します。

変更は、auto_increment_increment および auto_increment_offset のそれぞれのデフォルト値が 1 の場合にのみ行われ、元に戻されます。 これらの値がすでにデフォルトから変更されている場合、Group Replication はそれらを変更しません。 MySQL 8.0 からは、グループレプリケーションが単一プライマリモードで、サーバー書込みが 1 つのみの場合も、システム変数は変更されません。

グループがシングルプライマリモードで動作している場合は、どのメンバーがプライマリであるかを確認すると役立ちます。 セクション18.1.3.1.2「プライマリの検索」を参照してください