20.2.1.6 组中添加实例节点

上一篇已经启动了引导组，此时组中已经有一个成员，server s1，s1中可能已经有一些数据了，此时可以扩展组了，通过添加之前配置的其他两个服务器。

20.2.1.6.1 添加第二个实例

为了添加第二个实例，server s2，首先需要为s2创建一个配置文件。这个配置和s1使用的配置相似，除了比如server_id之类的需要修改。如下这些高亮的行可能需要不同的配置。

[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是相同的，因为用户在组内是共享的。这些组内成员需要相同的复制用户配置。如果你依赖分布式恢复在这些成员中恢复这些用户，当s2连接到s1的时候，就会将复制用户复制或者克隆到s1(这一步个人理解类似于将s2的用户信息注册到s1的复制元数据中)，如果您在s1上配置用户凭据时没有启用二进制日志，并且没有使用远程克隆操作进行状态转移，则必须在s2上创建复制用户。在这种情况下，连接到s2并执行：

SET SQL_LOG_BIN=0;

CREATE USER rpl_user@'%' IDENTIFIED BY 'password';

GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';

GRANT CONNECTION_ADMIN ON *.* TO rpl_user@'%';

GRANT BACKUP_ADMIN ON *.* TO rpl_user@'%';

GRANT GROUP_REPLICATION_STREAM ON *.* TO rpl_user@'%';

FLUSH PRIVILEGES; SET SQL_LOG_BIN=1;

如果需要使用CHANGE MASTER TO或者CHANGE REPLICATION SOURCE TO语句提供用户凭证，执行如下语句

mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password'  \\ FOR CHANNEL 'group_replication_recovery';

从MySQL 8.0.23以及更高版本:

mysql> CHANGE REPLICATION SOURCE TO SOURCE_USER='rpl_user', SOURCE_PASSWORD='password' \\ FOR CHANNEL 'group_replication_recovery';

 如果使用的是caching SHA-2验证插件，参考第20.6.3.11节

如果有需要的话，安装下组复制插件

启动s2的组复制成语加入组

mysql> START GROUP_REPLICATION;

或者如果使用START GROUP_REPLICATION提供的分布式恢复用户凭证的话(从MySQL8.0.21开始)，执行如下SQL： 

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仅仅需要加入这个已存在的组即可。

Tip

当组复制成功启动并且节点加入组之后，需要检查super_read_only参数。通过在组成员中设置super_read_only=ON，可以确保组复制失败时或者任何其他原因导致失败时server不会在接受事务。如果server需要以read_write的方式加入组，比如说作为主节点加入单主模式的组或者作为多主模式的组复制成员，当super_read_only被设置为ON，加入后自动设置为OFF。

查看performance_schema.replication_group_members表查看节点状态：

SELECT * FROM performance_schema.replication_group_members;

 当s2尝试加入组的时候，确保s1上相同的事务都在s2上进行了应用。一旦这个过程完成，s2则成为组的一个成员，并且此时被标记为ONLINE。换句话说他必须已经自动准备好追上s1上的所有数据。一旦状态时ONLINE，那么他就开始处理组内的事务。可以通过查询查看s2同步s1服务的状态：

SHOW DATABASES LIKE 'test';

SELECT * FROM test.t1;

SHOW BINLOG EVENTS;

以上所示，s2就已经追加到s2加入组时的状态。

 20.2.1.6.2 添加额外的实例节点

简述：

和s2过程类似

1.配置文件

2.创建用户并赋权

3.change master to

4.安装插件

5.开启组复制

6.查询表并进行验证。