この時点で、グループにはサーバー s1 というメンバーがあり、サーバー s1 にはデータが含まれています。 ここで、以前に構成した他の 2 つのサーバーを追加して、グループを拡張します。
別のインスタンスであるサーバー s2 を追加するには、最初にその構成ファイルを作成します。 この構成は、server_id などを除き、サーバー s1 に使用される構成と似ています。 これらの異なる行は、次のリストで強調表示されています。
[mysqld]
#
# Disable other storage engines
#
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
#
# Replication configuration parameters
#
server_id=2
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_checksum=NONE # Not needed from 8.0.21
#
# Group Replication configuration
#
plugin_load_add='group_replication.so'
group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
group_replication_start_on_boot=off
group_replication_local_address= "s2:33061"
group_replication_group_seeds= "s1:33061,s2:33061,s3:33061"
group_replication_bootstrap_group= offサーバー s1 の手順と似ていますが、サーバーを起動するオプションファイルが配置されています。 次に、分散リカバリ資格証明を次のように構成します。 これらのコマンドは、ユーザーがグループ内で共有されるため、サーバー s1 の設定時に使用されるコマンドと同じです。 このメンバーは、セクション18.2.1.3「分散リカバリのユーザー資格証明」 で同じレプリケーションユーザーが構成されている必要があります。 分散リカバリを使用してすべてのメンバーでユーザーを構成する場合、s2 がシード s1 に接続すると、レプリケーションユーザーは s1 にレプリケートまたはクローニングされます。 s1 でユーザー資格証明を構成したときにバイナリロギングを有効にしておらず、リモートクローニング操作が状態転送に使用されない場合は、s2 でレプリケーションユーザーを作成する必要があります。 この場合は、s2 に接続して次のコマンドを発行します:
SET SQL_LOG_BIN=0;
CREATE USER rpl_user@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
GRANT BACKUP_ADMIN ON *.* TO rpl_user@'%';
FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;
CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO ステートメントを使用してユーザー資格証明を指定する場合は、その後に次のステートメントを発行します:
CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password' \\
FOR CHANNEL 'group_replication_recovery';
Or from MySQL 8.0.23:
CHANGE REPLICATION SOURCE TO SOURCE_USER='rpl_user', SOURCE_PASSWORD='password' \\
FOR CHANNEL 'group_replication_recovery';MySQL 8 のデフォルトであるキャッシュ SHA-2 認証プラグインを使用している場合は、セクション18.5.3.1.1「キャッシュ SHA-2 認証プラグインを使用するレプリケーションユーザー」 を参照してください。
必要に応じて、Group Replication プラグインをインストールします。セクション18.2.1.4「グループレプリケーションの起動」 を参照してください。
グループレプリケーションを開始し、s2 がグループに参加するプロセスを開始します。
mysql> START GROUP_REPLICATION;
または、START GROUP_REPLICATION ステートメント (MySQL 8.0.21 から) で分散リカバリ用のユーザー資格証明を指定する場合は、次の手順を実行します:
mysql> START GROUP_REPLICATION USER='rpl_user', PASSWORD='password';
s1 で実行されたステップと同じステップとは異なり、グループはすでに存在するため、グループをブートストラップする必要はありません。 つまり、s2 group_replication_bootstrap_group では OFF に設定されており、グループレプリケーションを開始する前に SET GLOBAL group_replication_bootstrap_group=ON;を発行しません。これは、グループがすでにサーバー s1 によって作成およびブートストラップされているためです。 この時点で、s2 は既存のグループにのみ追加する必要があります。
グループレプリケーションが正常に開始され、サーバーがグループに参加すると、super_read_only 変数がチェックされます。 メンバー構成ファイルで super_read_only を ON に設定すると、なんらかの理由でグループレプリケーションの起動時に失敗したサーバーがトランザクションを受け入れないようにすることができます。 サーバーが読取り/書込みインスタンスとしてグループに参加する必要がある場合 (たとえば、単一プライマリグループのプライマリまたはマルチプライマリグループのメンバーとして)、super_read_only 変数が ON に設定されていると、グループへの参加時に OFF に設定されます。
performance_schema.replication_group_members テーブルを再度チェックすると、グループに 2 つの ONLINE サーバーが存在することがわかります。
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+---------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+---------------+
| group_replication_applier | 395409e1-6dfa-11e6-970b-00212844f856 | s1 | 3306 | ONLINE |
| group_replication_applier | ac39f1e6-6dfa-11e6-a69d-00212844f856 | s2 | 3306 | ONLINE |
+---------------------------+--------------------------------------+-------------+-------------+---------------+
s2 がグループに参加しようとすると、セクション18.4.3「分散リカバリ」 は、s1 が適用したのと同じトランザクションを s2 が適用したことを確認しました。 このプロセスが完了すると、s2 はグループをメンバーとして参加でき、この時点で ONLINE としてマークされます。 つまり、サーバー s1 を自動的に捕捉しておく必要があります。 s2 が ONLINE になると、グループとのトランザクションの処理が開始されます。 次のように、s2 がサーバー s1 と実際に同期されていることを確認します。
mysql> SHOW DATABASES LIKE 'test';
+-----------------+
| Database (test) |
+-----------------+
| test |
+-----------------+
mysql> SELECT * FROM test.t1;
+----+------+
| c1 | c2 |
+----+------+
| 1 | Luis |
+----+------+
mysql> SHOW BINLOG EVENTS;
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| binlog.000001 | 4 | Format_desc | 2 | 123 | Server ver: 8.0.29-log, Binlog ver: 4 |
| binlog.000001 | 123 | Previous_gtids | 2 | 150 | |
| binlog.000001 | 150 | Gtid | 1 | 211 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1' |
| binlog.000001 | 211 | Query | 1 | 270 | BEGIN |
| binlog.000001 | 270 | View_change | 1 | 369 | view_id=14724832985483517:1 |
| binlog.000001 | 369 | Query | 1 | 434 | COMMIT |
| binlog.000001 | 434 | Gtid | 1 | 495 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:2' |
| binlog.000001 | 495 | Query | 1 | 585 | CREATE DATABASE test |
| binlog.000001 | 585 | Gtid | 1 | 646 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:3' |
| binlog.000001 | 646 | Query | 1 | 770 | use `test`; CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL) |
| binlog.000001 | 770 | Gtid | 1 | 831 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:4' |
| binlog.000001 | 831 | Query | 1 | 890 | BEGIN |
| binlog.000001 | 890 | Table_map | 1 | 933 | table_id: 108 (test.t1) |
| binlog.000001 | 933 | Write_rows | 1 | 975 | table_id: 108 flags: STMT_END_F |
| binlog.000001 | 975 | Xid | 1 | 1002 | COMMIT /* xid=30 */ |
| binlog.000001 | 1002 | Gtid | 1 | 1063 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:5' |
| binlog.000001 | 1063 | Query | 1 | 1122 | BEGIN |
| binlog.000001 | 1122 | View_change | 1 | 1261 | view_id=14724832985483517:2 |
| binlog.000001 | 1261 | Query | 1 | 1326 | COMMIT |
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+前述のように、2 つ目のサーバーがグループに追加され、サーバー s1 から変更が自動的にレプリケートされました。 つまり、s2 がグループに参加した時点までに s1 で適用されたトランザクションは、s2 にレプリケートされています。
グループへのインスタンスの追加は、サーバー s2 の場合と同様に構成を変更する必要があることを除き、基本的には 2 つ目のサーバーの追加と同じステップのシーケンスです。 必要なコマンドを要約するには:
-
構成ファイルを作成します。
[mysqld] # # Disable other storage engines # disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY" # # Replication configuration parameters # server_id=3 gtid_mode=ON enforce_gtid_consistency=ON binlog_checksum=NONE # Not needed from 8.0.21 # # Group Replication configuration # plugin_load_add='group_replication.so' group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" group_replication_start_on_boot=off group_replication_local_address= "s3:33061" group_replication_group_seeds= "s1:33061,s2:33061,s3:33061" group_replication_bootstrap_group= off -
サーバーを起動して接続します。 分散リカバリ用のレプリケーションユーザーを作成します。
SET SQL_LOG_BIN=0; CREATE USER rpl_user@'%' IDENTIFIED BY 'password'; GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%'; GRANT BACKUP_ADMIN ON *.* TO rpl_user@'%'; FLUSH PRIVILEGES; SET SQL_LOG_BIN=1;CHANGE REPLICATION SOURCE TO|CHANGE MASTER TOステートメントを使用してユーザー資格証明を指定する場合は、その後に次のステートメントを発行します:CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password' \\ FOR CHANNEL 'group_replication_recovery'; Or from MySQL 8.0.23: CHANGE REPLICATION SOURCE TO SOURCE_USER='rpl_user', SOURCE_PASSWORD='password' \\ FOR CHANNEL 'group_replication_recovery'; -
必要に応じて、Group Replication プラグインをインストールします。
INSTALL PLUGIN group_replication SONAME 'group_replication.so'; -
グループレプリケーションを開始します。
mysql> START GROUP_REPLICATION;または、
START GROUP_REPLICATIONステートメント (MySQL 8.0.21 から) で分散リカバリ用のユーザー資格証明を指定する場合は、次の手順を実行します:mysql> START GROUP_REPLICATION USER='rpl_user', PASSWORD='password';
この時点で、s3 は起動して実行され、グループに参加して、グループ内の他のサーバーと捕捉されています。 performance_schema.replication_group_members テーブルを再度参照して、これが当てはまることを確認します。
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+---------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+---------------+
| group_replication_applier | 395409e1-6dfa-11e6-970b-00212844f856 | s1 | 3306 | ONLINE |
| group_replication_applier | 7eb217ff-6df3-11e6-966c-00212844f856 | s3 | 3306 | ONLINE |
| group_replication_applier | ac39f1e6-6dfa-11e6-a69d-00212844f856 | s2 | 3306 | ONLINE |
+---------------------------+--------------------------------------+-------------+-------------+---------------+サーバー s2 またはサーバー s1 でこの同じクエリーを発行すると、同じ結果になります。 また、サーバー s3 が捕捉されたことを確認できます:
mysql> SHOW DATABASES LIKE 'test';
+-----------------+
| Database (test) |
+-----------------+
| test |
+-----------------+
mysql> SELECT * FROM test.t1;
+----+------+
| c1 | c2 |
+----+------+
| 1 | Luis |
+----+------+
mysql> SHOW BINLOG EVENTS;
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| binlog.000001 | 4 | Format_desc | 3 | 123 | Server ver: 8.0.29-log, Binlog ver: 4 |
| binlog.000001 | 123 | Previous_gtids | 3 | 150 | |
| binlog.000001 | 150 | Gtid | 1 | 211 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1' |
| binlog.000001 | 211 | Query | 1 | 270 | BEGIN |
| binlog.000001 | 270 | View_change | 1 | 369 | view_id=14724832985483517:1 |
| binlog.000001 | 369 | Query | 1 | 434 | COMMIT |
| binlog.000001 | 434 | Gtid | 1 | 495 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:2' |
| binlog.000001 | 495 | Query | 1 | 585 | CREATE DATABASE test |
| binlog.000001 | 585 | Gtid | 1 | 646 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:3' |
| binlog.000001 | 646 | Query | 1 | 770 | use `test`; CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL) |
| binlog.000001 | 770 | Gtid | 1 | 831 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:4' |
| binlog.000001 | 831 | Query | 1 | 890 | BEGIN |
| binlog.000001 | 890 | Table_map | 1 | 933 | table_id: 108 (test.t1) |
| binlog.000001 | 933 | Write_rows | 1 | 975 | table_id: 108 flags: STMT_END_F |
| binlog.000001 | 975 | Xid | 1 | 1002 | COMMIT /* xid=29 */ |
| binlog.000001 | 1002 | Gtid | 1 | 1063 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:5' |
| binlog.000001 | 1063 | Query | 1 | 1122 | BEGIN |
| binlog.000001 | 1122 | View_change | 1 | 1261 | view_id=14724832985483517:2 |
| binlog.000001 | 1261 | Query | 1 | 1326 | COMMIT |
| binlog.000001 | 1326 | Gtid | 1 | 1387 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:6' |
| binlog.000001 | 1387 | Query | 1 | 1446 | BEGIN |
| binlog.000001 | 1446 | View_change | 1 | 1585 | view_id=14724832985483517:3 |
| binlog.000001 | 1585 | Query | 1 | 1650 | COMMIT |
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+