前書き

MySQLレプリケーションは、データベース間でデータと操作を確実にミラーリングします。 従来のレプリケーションでは、プライマリサーバーのログから独自のデータセットにアクションをコピーして適用するセカンダリサーバーでのデータベース書き込み操作を受け入れるように構成されたプライマリサーバーが必要です。 これらのセカンダリサーバーは読み取りに使用できますが、通常はデータの書き込みを実行できません。

グループレプリケーションは、より柔軟でフォールトトレラントなレプリケーションメカニズムを実装する方法です。 このプロセスには、データが正しくコピーされるようにするためのサーバープールの確立が含まれます。 プライマリサーバーで問題が発生した場合、メンバーの選択により、グループから新しいプライマリを選択できます。 これにより、問題が発生した場合でも、残りのノードは動作を継続できます。 メンバーシップネゴシエーション、障害検出、およびメッセージ配信は、https://en.wikipedia.org/wiki/Paxos_(computer_science)[Paxos concensus algorithm]の実装を通じて提供されます。

このチュートリアルでは、3台のUbuntu 16.04サーバーのセットを使用してMySQLグループのレプリケーションをセットアップします。 この構成では、単一のプライマリレプリケーショングループまたはマルチプライマリレプリケーショングループの運用方法について説明します。

前提条件

これに従うには、3つのUbuntu 16.04サーバーのグループが必要になります。 これらの各サーバーで、 `+ sudo +`権限を持つ非rootユーザーを設定し、基本的なファイアウォールを設定する必要があります。 これらの要件を満たし、各サーバーを準備完了状態。

UbuntuのデフォルトリポジトリにあるMySQLのバージョンには、必要なグループレプリケーションプラグインは含まれていません。 ありがたいことに、MySQLプロジェクトは、このコンポーネントを含む最新のMySQLバージョンの独自のリポジトリを保持しています。 Ubuntu 16.04への最新のMySQLのインストールのガイドに従ってグループをインストールします各サーバー上のMySQLのレプリケーション対応バージョン。

MySQLグループを識別するUUIDを生成します

MySQL構成ファイルを開いてグループ複製設定を構成する前に、作成するMySQLグループを識別するために使用できるUUIDを生成する必要があります。

  • mysqlmember1 *で、 `+ uuidgen +`コマンドを使用して、グループの有効なUUIDを生成します。

uuidgen
Output

受け取った値をコピーします。 サーバーのプールのグループ名を構成するときに、これをすぐに参照する必要があります。

MySQL構成ファイルでのグループレプリケーションのセットアップ

これで、MySQLの構成ファイルを変更する準備が整いました。 *各MySQLサーバー*でメインのMySQL構成ファイルを開きます。

sudo nano /etc/mysql/my.cnf

デフォルトでは、このファイルはサブディレクトリから追加のファイルを入手するためにのみ使用されます。 `+!includedir +`行の下に独自の設定を追加する必要があります。 これにより、含まれているファイルの設定を簡単にオーバーライドできます。

まず、 `+ [mysqld] `ヘッダーを含めることにより、MySQLサーバーコンポーネントのセクションを開きます。 この下に、グループの複製に必要な設定を貼り付けます。 ` loose- +`プレフィックスにより、MySQLは失敗せずに適切に認識されないオプションを適切に処理できます。 これらの設定の多くをすぐに入力してカスタマイズする必要があります。

/etc/mysql/my.cnf

. . .
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mysql.conf.d/

上記の構成を4つのセクションに分割しました。 それではそれらを見ていきましょう。

定型グループのレプリケーション設定

最初のセクションには、変更を必要としないグループ複製に必要な一般設定が含まれています。

/etc/mysql/my.cnf

. . .
# General replication settings
gtid_mode = ON
enforce_gtid_consistency = ON
master_info_repository = TABLE
relay_log_info_repository = TABLE
binlog_checksum = NONE
log_slave_updates = ON
log_bin = binlog
binlog_format = ROW
transaction_write_set_extraction = XXHASH64
loose-group_replication_bootstrap_group = OFF
loose-group_replication_start_on_boot = OFF
loose-group_replication_ssl_mode = REQUIRED
loose-group_replication_recovery_use_ssl = 1
. . .

これらの設定は、グローバルトランザクションIDを有効にし、グループレプリケーションに必要なバイナリログを構成し、グループのSSLを構成します。 この構成では、リカバリとブートストラップを支援する他のいくつかの項目も設定します。 このセクションの内容を変更する必要はありません。貼り付けてから先に進んでください。

共有グループ複製設定

2番目のセクションでは、グループの共有設定をセットアップします。 これを一度カスタマイズしてから、各ノードで同じ設定を使用する必要があります。 これには、グループのUUID、受け入れ可能なメンバーのホワイトリスト、および初期データを取得するために連絡するシードメンバーが含まれます。

`+ loose-group_replication_group_name `を、以前に ` uuidgen +`コマンドで生成したUUIDに設定します。 コピーしたUUIDをこの変数の値として貼り付けます。

次に、 `+ loose-group_replication_ip_whitelist `を、コンマで区切られたすべてのMySQLサーバーIPアドレスのリストに設定します。 ` loose-group_replication_group_seeds +`設定はホワイトリストとほぼ同じである必要がありますが、各メンバーの最後に使用するグループ複製ポートを追加する必要があります。 このガイドでは、グループレプリケーションに33061の推奨ポートを使用します。

/etc/mysql/my.cnf

. . .
# Shared replication group configuration
loose-group_replication_group_name = ""
loose-group_replication_ip_whitelist = ",,"
loose-group_replication_group_seeds = "":33061,:33061,:33061"
. . .

このセクションは、各MySQLサーバーで同じである必要があるため、慎重にコピーしてください。

単一のプライマリまたはマルチプライマリの選択

次に、単一プライマリグループを構成するか、マルチプライマリグループを構成するかを決定する必要があります。 公式のMySQLドキュメントの一部では、この区別は「シングル」レプリケーションと「マルチマスター」レプリケーションとも呼ばれます。 単一のプライマリ設定では、MySQLは書き込み操作を処理する単一のプライマリサーバー(ほとんどの場合、最初のグループメンバー)を指定します。 マルチプライマリグループは、任意のグループメンバーへの書き込みを許可します。

マルチプライマリグループを設定したい場合は、 `+ loose-group_replication_single_primary_mode `および ` loose-group_replication_enforce_update_everywhere_checks +`ディレクティブのコメントを外します。 これにより、マルチプライマリグループが設定されます。 単一のプライマリグループの場合、次の2行をコメントのままにしてください。

/etc/mysql/my.cnf

. . .
# Single or Multi-primary mode? Uncomment these two lines
# for multi-primary mode, where any host can accept writes
loose-group_replication_single_primary_mode = OFF
loose-group_replication_enforce_update_everywhere_checks = ON
. . .

これらの設定は、各MySQLサーバーで同じでなければなりません。

この設定は後で変更できますが、MySQLグループを再起動しなければ変更できません。 新しい構成に切り替えるには、グループ内の各MySQLインスタンスを停止し、各メンバーを新しい設定で起動してから、グループレプリケーションを再起動する必要があります。 これはデータには影響しませんが、わずかなダウンタイムが必要です。

ホスト固有の構成設定

4番目のセクションには、以下を含む各サーバーで異なる設定が含まれています。

  • サーバーID

  • バインドするアドレス

  • 他のメンバーに報告するアドレス

  • ローカル複製アドレスとリスニングポート

`+ server_id `ディレクティブは一意の番号に設定する必要があります。 最初のメンバーについては、これを「1」に設定し、追加するホストごとに番号を増やします。 MySQLインスタンスが外部接続をリッスンし、そのアドレスを他のホストに正しく報告するように、「 bind-address」と「+ report_host」を現在のサーバーのIPアドレスに設定します。 `+ loose-group_replication_local_address +`は、IPアドレスにグループ複製ポート(33061)を追加した現在のサーバーのIPアドレスにも設定する必要があります。

/etc/mysql/my.cnf

. . .
# Host specific replication configuration
server_id =
bind-address = ""
report_host = ""
loose-group_replication_local_address = ":33061"

各MySQLサーバーでこのプロセスを完了します。

完了したら、共有レプリケーション設定が各ホストで同じであること、およびホスト固有の設定が各ホストに対してカスタマイズされていることを再確認します。 終了したら、各ホストでファイルを保存して閉じます。

MySQLを再起動してリモートアクセスを有効にする

MySQL構成ファイルには、MySQLグループレプリケーションのブートストラップに必要なディレクティブが含まれています。 MySQLインスタンスに新しい設定を適用するには、次のコマンドを使用して*各サーバー*でサービスを再起動します。

sudo systemctl restart mysql

MySQL構成ファイルで、デフォルトポート3306で外部接続をリッスンするようにサービスを構成しました。 また、メンバーがレプリケーション調整に使用するポートとして33061を定義しました。

ファイアウォールでこれらの2つのポートへのアクセスを開く必要があります。これは、次のように入力することで実行できます。

sudo ufw allow 33061
sudo ufw allow 3306

MySQLポートが開いている状態で、レプリケーションユーザーを作成し、グループレプリケーションプラグインを有効にすることができます。

レプリケーションユーザーの構成とグループレプリケーションプラグインの有効化

*各MySQLサーバー*で、管理ユーザーでMySQLインスタンスにログインして、対話型セッションを開始します。

mysql -u root -p

MySQL管理パスワードの入力を求められます。 その後、MySQLセッションにドロップされます。 最初に行う必要があるのは、レプリケーションユーザーの作成です。

グループ複製を確立するには、各サーバーで複製ユーザーが必要です。 各サーバーには独自のレプリケーションユーザーがいるため、作成プロセス中にバイナリログをオフにする必要があります。 そうしないと、複製が開始されると、グループは複製ユーザーをプライマリサーバーから他のサーバーに伝達しようとし、既に配置されている複製ユーザーと競合します。

レプリケーションユーザーにSSLを要求し、サーバーでレプリケーション権限を付与してから、権限をフラッシュして変更を実装します。 その後、バイナリロギングを再度有効にして、通常の操作を再開します。 レプリケーションユーザーを作成するときは、安全なパスワードを使用してください。

SET SQL_LOG_BIN=0;
CREATE USER 'repl'@'%' IDENTIFIED BY '' REQUIRE SSL;
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;

次に、新しいレプリケーションユーザーと関連するパスワードを使用するために、 `+ group_replication_recovery +`チャンネルを設定する必要があります。 その後、各サーバーはこれらの資格情報を使用してグループの認証を行います。

CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='' FOR CHANNEL 'group_replication_recovery';

レプリケーションユーザーを配置したら、グループレプリケーションプラグインを有効にして、グループの初期化を準備できます。 MySQLの最新バージョンを使用しているため、次のように入力してプラグインを有効にできます。

INSTALL PLUGIN group_replication SONAME 'group_replication.so';

次を入力して、プラグインがアクティブであることを確認します。

SHOW PLUGINS;
Output+----------------------------+----------+--------------------+----------------------+---------+
| Name                       | Status   | Type               | Library              | License |
+----------------------------+----------+--------------------+----------------------+---------+
|                            |          |                    |                      |         |
| . . .                      | . . .    | . . .              | . . .                | . . .   |
|                            |          |                    |                      |         |
| group_replication          | ACTIVE   | GROUP REPLICATION  | group_replication.so | GPL     |
+----------------------------+----------+--------------------+----------------------+---------+
45 rows in set (0.00 sec)

`+ group_replication +`行は、プラグインがロードされ、現在アクティブであることを確認します。

グループレプリケーションを開始する

各MySQLサーバーでレプリケーションユーザーが構成され、グループレプリケーションプラグインが有効になったので、グループを立ち上げることができます。

ブートストラップの最初のノード

グループを起動するには、*グループの単一のメンバー*で次の手順を実行します。

グループメンバーは、最初にグループに参加するときに、既存のメンバーに依存して、レプリケーションデータ、最新のメンバーシップリスト、およびその他の情報を送信します。 このため、最初のグループメンバーを起動するために、少し異なる手順を使用して、シードリスト内の他のメンバーからこの情報を期待しないようにする必要があります。

設定されている場合、 `+ group_replication_bootstrap_group +`変数は、ピアから情報を受信することを期待してはならず、代わりに新しいグループを確立して自分自身をプライマリメンバーに選出する必要があることをメンバーに伝えます。 これが適切な唯一の状況は、既存のグループメンバーが存在しない場合だけなので、グループをブートストラップした直後にこの機能をオフにします。

SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;

このサーバーを唯一のメンバーとしてグループを開始する必要があります。 `+ performance_schema `データベースの ` replication_group_members +`テーブル内のエントリをチェックすることでこれを確認できます:

SELECT * FROM performance_schema.replication_group_members;

現在のホストを表す単一の行が表示されるはずです。

Output+---------------------------+--------------------------------------+--------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST  | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 |   |        3306 | ONLINE       |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
1 row in set (0.00 sec)

「+ MEMBER_STATE 」の「 ONLINE +」値は、このノードがグループ内で完全に動作していることを示します。

次に、テストデータベースとテーブルを作成して、レプリケーションをテストします。

CREATE DATABASE playground;
CREATE TABLE playground.equipment ( id INT NOT NULL AUTO_INCREMENT, type VARCHAR(50), quant INT, color VARCHAR(25), PRIMARY KEY(id));
INSERT INTO playground.equipment (type, quant, color) VALUES ("slide", 2, "blue");

コンテンツをチェックして、正しく入力されたことを確認します。

SELECT * FROM playground.equipment;
Output+----+-------+-------+-------+
| id | type  | quant | color |
+----+-------+-------+-------+
|  1 | slide |     2 | blue  |
+----+-------+-------+-------+
1 row in set (0.00 sec)

このサーバーがグループのメンバーであり、書き込み機能があることを確認しました。 これで、他のサーバーがグループに参加できます。

残りのノードの起動

次に、* 2番目のサーバー*で、グループのレプリケーションを開始します。 既にアクティブなメンバーがいるので、グループをブートストラップする必要はなく、グループに参加するだけです。

START GROUP_REPLICATION;
  • 3番目のサーバー*で、同じ方法でグループレプリケーションを開始します。

START GROUP_REPLICATION;

メンバーシップリストをもう一度確認してください。 3つのサーバーが表示されます。

SELECT * FROM performance_schema.replication_group_members;
Output+---------------------------+--------------------------------------+--------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST  | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 |   |        3306 | ONLINE       |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 |   |        3306 | ONLINE       |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef |   |        3306 | ONLINE       |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
3 rows in set (0.01 sec)

すべてのメンバーは、 `+ MEMLINE_STATE `の値が ` ONLINE `である必要があります。 新しいグループの場合、いずれかのノードが1〜2秒以上「 RECOVERING 」としてリストされている場合、通常はエラーが発生したか、何かが誤って設定されていることを示しています。 ` / var / log / mysql / error.log +`のログを確認して、問題の詳細を確認してください。

テストデータベース情報が新しいメンバーに複製されているかどうかを確認します。

SELECT * FROM playground.equipment;
Output+----+-------+-------+-------+
| id | type  | quant | color |
+----+-------+-------+-------+
|  1 | slide |     2 | blue  |
+----+-------+-------+-------+
1 row in set (0.01 sec)

新しいメンバーでデータが利用できる場合、グループ複製が正しく機能していることを意味します。

新しいグループメンバーの書き込み機能のテスト

次に、新しいメンバーからデータベースへの書き込みを試みることができます。 これが成功するかどうかは、単一のプライマリグループまたはマルチプライマリグループのどちらを設定するかによって決まります。

単一のプライマリ環境での書き込みのテスト

単一のプライマリグループでは、非プライマリサーバーからの書き込み操作が一貫性の理由で拒否されることを想定する必要があります。 次のクエリを使用して、いつでも現在のプライマリを検出できます。

SHOW STATUS LIKE '%primary%';
Output+----------------------------------+--------------------------------------+
| Variable_name                    | Value                                |
+----------------------------------+--------------------------------------+
| group_replication_primary_member | 13324ab7-1b01-11e7-9dd1-22b78adaa992 |
+----------------------------------+--------------------------------------+
1 row in set (0.01 sec)

クエリの値は `+ MEMBER_ID +`になり、前と同じようにグループメンバーリストをクエリすることでホストに一致させることができます。

SELECT * FROM performance_schema.replication_group_members;
Output+---------------------------+--------------------------------------+--------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST  | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 |   |        3306 | ONLINE       |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 |   |        3306 | ONLINE       |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef |   |        3306 | ONLINE       |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
3 rows in set (0.01 sec)

この例では、 `+ 203.0.113.1 +`のホストが現在プライマリサーバーであることがわかります。 別のメンバーからデータベースに書き込もうとすると、操作が失敗することが予想されます。

INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");
OutputERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement

これは、グループが単一の書き込み可能なプライマリで現在構成されているためです。 プライマリサーバーに問題があり、グループを脱退する場合、グループは自動的に新しいメンバーをプライマリとして選択し、書き込みを受け入れます。

マルチプライマリ環境での書き込みのテスト

マルチプライマリ指向で構成されたグループの場合、すべてのメンバーがデータベースへの書き込みをコミットできる必要があります。

`+ group_replication_primary_member +`変数の値を再度チェックすることで、グループがマルチプライマリモードで動作していることを再確認できます。

SHOW STATUS LIKE '%primary%';
Output+----------------------------------+-------+
| Variable_name                    | Value |
+----------------------------------+-------+
| group_replication_primary_member |       |
+----------------------------------+-------+
1 row in set (0.02 sec)

変数が空の場合、これは、指定されたプライマリホストがなく、メンバーが書き込みを受け入れることができることを意味します。

次のように入力して、* 2番目のサーバー*でこれをテストします。

INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");
OutputQuery OK, 1 row affected (0.00 sec)

2番目のサーバーは、エラーなしで書き込み操作をコミットしました。

  • 3番目のサーバー*で、新しいアイテムが追加されたことを確認するクエリを実行します。

SELECT * FROM playground.equipment;
Output+----+-------+-------+--------+
| id | type  | quant | color  |
+----+-------+-------+--------+
|  1 | slide |     2 | blue   |
|  2 | swing |    10 | yellow |
+----+-------+-------+--------+
2 rows in set (0.00 sec)

これにより、2番目のサーバーの書き込みが正常に複製されたことを確認できます。

次に、次のように入力して、3番目のサーバーで書き込み機能をテストします。

INSERT INTO playground.equipment (type, quant, color) VALUES ("seesaw", 3, "green");
OutputQuery OK, 1 row affected (0.02 sec)

*最初のサーバー*に戻り、両方の新しいメンバーからの書き込み操作が複製されたことを確認するためにテストします。

SELECT * FROM playground.equipment;
Output+----+--------+-------+--------+
| id | type   | quant | color  |
+----+--------+-------+--------+
|  1 | slide  |     2 | blue   |
|  2 | swing  |    10 | yellow |
|  3 | seesaw |     3 | green  |
+----+--------+-------+--------+
3 rows in set (0.01 sec)

これにより、レプリケーションが各方向で機能し、各メンバーが書き込み操作を実行できることが確認されます。

グループをバックアップする

グループがブートストラップされると、プライマリサーバーを選出するのに十分なメンバーがいる限り、個々のメンバーは可用性に影響を与えることなく参加および離脱できます。 ただし、特定の構成の変更(単一プライマリ環境とマルチプライマリ環境の切り替えなど)が行われた場合、またはグループのすべてのメンバーが離脱した場合、グループを再ブートストラップする必要があります。 これは、最初に行ったのとまったく同じ方法で行います。

*最初のサーバー*で、 `+ group_replciation_bootstrap_group +`変数を設定し、グループの初期化を開始します。

SET GLOBAL GROUP_REPLICATION_BOOTSTRAP_GROUP=ON;
START GROUP_REPLICATION;
SET GLOBAL GROUP_REPLICATION_BOOTSTRAP_GROUP=OFF;

最初のメンバーがグループを開始すると、他のメンバーが参加できます:

START GROUP_REPLICATION;

追加のメンバーについては、このプロセスに従ってください。

START GROUP_REPLICATION;

これで、グループがオンラインになり、すべてのメンバーが利用可能になります。

SELECT * FROM performance_schema.replication_group_members;
Output+---------------------------+--------------------------------------+--------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST  | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 |   |        3306 | ONLINE       |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 |   |        3306 | ONLINE       |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef |   |        3306 | ONLINE       |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
3 rows in set (0.01 sec)

このプロセスは、必要なときにいつでもグループを再開するために使用できます。

MySQLの起動時にグループに自動的に参加する

現在の設定では、メンバーサーバーが再起動しても、起動時にグループに自動的に再参加しません。 メンバーがグループに自動的に再参加するようにする場合は、構成ファイルをわずかに変更できます。

概要を説明する設定は、メンバーが起動時に自動的に参加するようにする場合に役立ちます。 ただし、次の点に注意する必要があります。

まず、この設定は、MySQLインスタンス自体がいつ開始されるかにのみ影響します。 タイムアウトの問題のためにメンバーがグループから削除されても、MySQLインスタンスがオンラインのままである場合、メンバーは自動的に再参加しません。

第二に、グループを最初にブートストラップするときにこの設定を有効にすると、有害になる可能性があります。 参加する既存のグループが存在しない場合、MySQLプロセスは、他の存在しないメンバーに連絡して初期化を試みるため、開始に時間がかかります。 長いタイムアウトの後でのみ、それはあきらめ、正常に開始します。 その後、上記の手順を使用してグループをブートストラップする必要があります。

上記の注意事項を念頭に置いて、MySQLの起動時にグループに自動的に参加するようにノードを構成する場合は、メインのMySQL構成ファイルを開きます。

sudo nano /etc/mysql/my.cnf

内部で、 `+ loose-group_replication_start_on_boot +`変数を見つけて、「ON」に設定します。

/etc/mysql/my.cnf

[mysqld]
. . .
loose-group_replication_start_on_boot = ON
. . .

完了したら、ファイルを保存して閉じます。 メンバーは、MySQLインスタンスが次に起動されたときに、グループへの参加を自動的に試みる必要があります。

結論

このチュートリアルでは、3つのUbuntu 16.04サーバー間でMySQLグループのレプリケーションを構成する方法について説明しました。 シングルプライマリセットアップの場合、メンバーは必要に応じて書き込み可能なプライマリを自動的に選択します。 マルチプライマリグループの場合、すべてのメンバーが書き込みと更新を実行できます。

グループレプリケーションは、メンバーが自由に参加または離脱できる柔軟なレプリケーショントポロジを提供すると同時に、データの一貫性とメッセージの順序に関する保証を提供します。 MySQLグループのレプリケーションは、構成が少し複雑になる場合がありますが、従来のレプリケーションでは不可能な機能を提供します。