シングルプライマリモード (group_replication_single_primary_mode=ON) では、グループに読取り/書込みモードに設定された単一のプライマリサーバーがあります。 グループ内の他のすべてのメンバーは読取り専用モードに設定されます (super_read_only=ON を使用)。 プライマリは通常、グループをブートストラップする最初のサーバーです。 グループに参加する他のすべてのサーバーはプライマリサーバーについて学習し、自動的に読取り専用モードに設定されます。
単一プライマリモードでは、グループレプリケーションにより、単一サーバーのみがグループに書き込まれるように強制されるため、マルチプライマリモードと比較すると、一貫性チェックの制限が少なくなり、DDL ステートメントを特別に処理する必要はありません。 オプション group_replication_enforce_update_everywhere_checks は、グループの厳密な整合性チェックを有効または無効にします。 シングルプライマリモードでデプロイする場合、またはグループをシングルプライマリモードに変更する場合は、このシステム変数を OFF に設定する必要があります。
プライマリサーバーとして指定されたメンバーは、次の方法で変更できます:
既存のプライマリがグループから退出した場合は、自発的か予期せず、新しいプライマリが自動的に選択されます。
group_replication_set_as_primary()UDF を使用して、特定のメンバーを新しいプライマリとして指名できます。group_replication_switch_to_single_primary_mode()UDF を使用して、マルチプライマリモードで実行されていたグループをシングルプライマリモードで実行するように変更した場合は、新しいプライマリが自動的に選択されるか、UDF で指定して新しいプライマリを指名できます。
UDF は、すべてのグループメンバーが MySQL 8.0.13 以上を実行している場合にのみ使用できます。 新しいプライマリサーバーが自動的に選択されるか、手動で指定されると、自動的に読取り /書込みに設定され、他のグループメンバーはセカンダリとして残り、読取り専用のままになります。図18.4「新規プライマリ選択」 にこのプロセスが表示されます。
新しいプライマリが選択または指名されると、古いプライマリに適用されたが、このサーバーにはまだ適用されていない変更のバックログがある可能性があります。 この状況では、新しいプライマリが古いプライマリと捕捉されるまで、読取り/書込みトランザクションによって競合が発生してロールバックされ、読取り専用トランザクションによって読取りが失効する可能性があります。 高速メンバーと低速メンバーの違いを最小限に抑えるグループレプリケーションのフロー制御メカニズムにより、アクティブ化され適切にチューニングされた場合に発生する可能性が軽減されます。 フロー制御の詳細は、セクション18.6.2「フロー制御」 を参照してください。 MySQL 8.0.14 から、group_replication_consistency システム変数を使用してトランザクション一貫性のグループレベルを構成し、この問題を回避することもできます。 BEFORE_ON_PRIMARY_FAILOVER (またはそれ以上の整合性レベル) を設定すると、バックログが適用されるまで、新しく選択されたプライマリに新しいトランザクションが保持されます。 トランザクションの一貫性の詳細は、セクション18.4.2「トランザクション一貫性保証」 を参照してください。 フロー制御およびトランザクションの一貫性保証がグループに使用されていない場合は、クライアントアプリケーションを再ルーティングする前に、新しいプライマリがレプリケーション関連のリレーログを適用するのを待機することをお薦めします。
プライマリメンバーの自動選択プロセスでは、各メンバーがグループの新しいビューを参照し、潜在的な新しいプライマリメンバーを順序付けし、最も適したメンバーを選択します。 各メンバーは、MySQL Server リリースのプライマリ選択アルゴリズムに従って、独自の決定をローカルで行います。 すべてのメンバーは同じ決定に到達する必要があるため、他のグループメンバーがより低い MySQL Server バージョンを実行している場合、メンバーはプライマリ選択アルゴリズムを調整して、グループ内で最も低い MySQL Server バージョンのメンバーと同じ動作をします。
プライマリを選択するときにメンバーが考慮するファクタは、次のとおりです:
最初に考慮される要因は、MySQL Server の最下位バージョンを実行しているメンバーです。 すべてのグループメンバーが MySQL 8.0.17 以上を実行している場合、メンバーは最初にそのリリースのパッチバージョンで順序付けされます。 MySQL Server 5.7 または MySQL 8.0.16 以下を実行しているメンバーがある場合、メンバーは最初にメジャーバージョンのリリースで順序付けされ、パッチバージョンは無視されます。
-
複数のメンバーで最低バージョンの MySQL Server が実行されている場合、考慮される 2 番目のファクタは、メンバーの
group_replication_member_weightシステム変数で指定されている各メンバーのメンバーの重みです。 このシステム変数を使用できなかった MySQL Server 5.7 をグループのいずれかのメンバーが実行している場合、この係数は無視されます。group_replication_member_weightシステム変数は、0-100 の範囲の数値を指定します。 すべてのメンバーのデフォルトの重みは 50 であるため、順序を下げるにはこの値より下の重みを設定し、順序を上げるにはその上の重みを設定します。 この重み付け機能を使用すると、より適切なハードウェアの使用に優先順位を付けることや、プライマリのスケジュールされたメンテナンス中に特定のメンバーにフェイルオーバーすることができます。 複数のメンバーで最低バージョンの MySQL Server が実行されており、それらのメンバーのうち複数のメンバーの重みが最高である (またはメンバーの重みが無視されている) 場合、3 番目の要因は、
server_uuidシステム変数で指定されているように、各メンバーの生成されたサーバー UUID の辞書順であるとみなされます。 サーバー UUID が最も低いメンバーがプライマリとして選択されます。 このファクタは、すべてのグループメンバーが重要なファクタによって決定できない場合に同じ決定に到達するように、保証付きで予測可能なタイエリアとして機能します。
シングルプライマリモードでデプロイされたときに現在プライマリであるサーバーを確認するには、performance_schema.replication_group_members テーブルの MEMBER_ROLE カラムを使用します。 例:
mysql> SELECT MEMBER_HOST, MEMBER_ROLE FROM performance_schema.replication_group_members;
+-------------------------+-------------+
| MEMBER_HOST | MEMBER_ROLE |
+-------------------------+-------------+
| remote1.example.com | PRIMARY |
| remote2.example.com | SECONDARY |
| remote3.example.com | SECONDARY |
+-------------------------+-------------+
group_replication_primary_member ステータス変数は非推奨になり、将来のバージョンで削除される予定です。
または、group_replication_primary_member ステータス変数を使用します。
mysql> SHOW STATUS LIKE 'group_replication_primary_member'