このページは機械翻訳したものです。

18.10 よくある質問

このセクションでは、よくある質問への回答を示します。

グループ内の MySQL サーバーの最大数はいくつですか。

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

グループ内のサーバーはどのように接続されていますか。

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

group_replication_bootstrap_group オプションは何に使用されますか。

ブートストラップフラグは、メンバーにグループを 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 操作のごく一部をスケールアウトできます。

グループレプリケーションでは、単純なレプリケーションと比較して、同じワークロードでより多くのネットワーク帯域幅と CPU が必要ですか。

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

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

広域ネットワーク間でグループレプリケーションをデプロイできますか。

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

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

警告

いずれかのグループメンバー間のネットワークラウンドトリップ時間 (RTT) が 5 秒以上の場合、組込みの障害検出メカニズムが誤ってトリガーされる可能性があるため、問題が発生する可能性があります。

一時的な接続の問題が発生した場合、メンバーは自動的にグループに再参加しますか。

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

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

• group_replication_member_expel_timeout では、疑いの作成 (最初の 5 秒間の検出期間の後に発生) とメンバーの削除の間の時間が長くなります。 最大 1 時間の待機期間を設定できます。 MySQL 8.0.21 からは、待機期間はデフォルトで 5 秒に設定されます。

• group_replication_autorejoin_tries では、メンバーは強制タイムアウトまたは到達不能な大多数のタイムアウトの後にグループへの再参加を試行します。 メンバーは、指定された数の自動再結合試行を 5 分間隔で行います。 MySQL 8.0.21 からは、この機能はデフォルトでアクティブ化され、メンバーは 3 回の自動再結合を試行します。

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

メンバーがグループから除外されるのはいつですか。

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

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

1 つのノードが大幅に遅れているとどうなりますか。

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

グループ内の問題が疑われる場合、再構成のトリガーを担当する特別なメンバーはいますか。

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

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

シャーディングにグループレプリケーションを使用できますか。

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

SELinux でグループレプリケーションを使用するにはどうすればよいですか。

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

iptables でグループレプリケーションを使用するにはどうすればよいですか。

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 チャネルを再度作成します。

グループレプリケーションで 2 つのバインドアドレスが使用されるのはなぜですか。

グループレプリケーションでは、クライアントがメンバーと通信するために使用する 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 オプションを使用して指定します。

重要

割り当てられた値は直接使用され、skip_name_resolve システム変数の影響を受けません。

サーバーで 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「プライマリの検索」を参照してください