MGR组复制常见问题

单个复制组中的允许组成员（MySQL Server）的最大数量是9个。如果有更多的Server尝试加入该组时，其连接请求将被拒绝。该限制数量是通过已有的测试案例和基准测试中得出的一个安全边界，在这个安全边界中，组能够安全、可靠、稳定地运行在一个稳定的局域网中。

组中的成员之间，通过建立点对点的TCP连接与组中的其他成员进行通讯。这些连接仅用于组成员之间的内部通信和消息传递。用于建立TCP连接的地址信息由系统变量group_replication_local_address进行配置。

指示启用该系统变量的Server在执行START GROUP_REPLICATION语句时引导创建一个组，并充当种子成员。后续的其他Server如果要加入组（加入组的Server在这里称为joiner成员），则需要向创建组的成员请求加入组（接受连接请求的组成员在这里称为donor节点），创建组的成员在接收到joiner节点请求之后，会动态更改一些配置，以便将其添加到组中

有如下两种场景需要使用该系统变量来引导创建一个组：

如果组使用多主模式，则可以将无冲突的事务分散到不同的主要节点中，这样就能够一定程度上扩展写负载能力（通过多节点写来扩展一小部分IO *** 作，能够间接扩展一小部分写负载）。

由于组成员之间需要不断地相互交互消息以实现同步数据和相互告知组成员状态的目的。因此，相对于主从复制来说，预计会产生一些额外的负载，但具体多多少负载很难量化，因为它还取决于组的大小（即，组成员数量。例如：9个组成员对带宽需求大于3个成员，且内存和CPU消息也更大，因为成员数量越多，组中消息传递和处理工作就越复杂）。

可以，但是每个成员之间的网络连接必须可靠并具有良好的性能，低延迟、高带宽的网络连接是保证组复制高性能的必要条件，如果网络带宽存在瓶颈，可以参考"6.3 消息压缩" 中介绍的方法来降低组复制的带宽消耗。但是，如果网络连接存在丢包的问题，可能导致重新传输造成更高的端到端延迟，这个时候，吞吐量和延迟都将受到负面影响。注意：当任何组成员之间的网络往返时间(RTT)超过5秒时，可能会触发内置的故障检测机制而导致组成员被驱逐出组（实际是否被驱逐出组，需要看具体的配置）。

这取决于连接发生问题的原因。如果连接问题是暂时的，并且重新连接的速度足够快（即，发生问题的时间很短），以至于故障检测器没有发现或者未达到故障级别，那么组成员可能就不会被驱逐出组。如果发生问题的时间足够长，则故障检测器最终会发现问题并将故障成员驱逐出组。

从MySQL 8.0版本开始，可以使用两个系统变量进行调节，这就为发生问题的组成员增加了一个继续留在组中或被驱逐出组之后重新加入组的机会：

group_replication_autorejoin_tries：设置一个组成员被驱逐出组或者与组中多数成员失联达到超时时间之后，尝试自动重新加入组的次数。设置该系统变量为非0值时，成员会按照该系统变量设置的次数每隔5分钟进行一次自动重新加入组的尝试

如果一个成员被驱逐出组，并且耗尽了自动重新加入组的尝试次数都不能成功加入组，那么将会按照系统变量group_replication_exit_state_action指定的值执行退出 *** 作。之后，如果需要将其重新加入组，你需要手动执行加入组的步骤（或者使用自动化运维脚本）。

MGR(组复制)两种运行模式

单主模式 下,组复制具有自动选主功能，每次只有一个

server成员接受更新。单写模式group内只有一台节点可写可读，其他节点只可以读。对于group的部署，需要先跑起primary节点（即那个可写可读的节点，read_only=0）然后再跑起其他的节点，并把这些节点一一加进group。其他的节点就会自动同步primary节点上面的变化，然后将自己设置为只读模式（read_only=1）。当primary节点意外宕机或者下线，在满足大多数节点存活的情况下，group内部发起选举，选出下一个可用的读节点，提升为primary节点。primary选举根据group内剩下存活节点的UUID按字典序升序来选择，即剩余存活的节点按UUID字典序排列，然后选择排在最前的节点作为新的primary节点。

多主模式 下, 所有的 server 成员都可以同时接受更新。group内的所有机器都是primary节点，同时可以进行读写 *** 作，并且数据是最终一致的。

相关参数 : group_replication_single_primary_mode

是否启动单主模式，如果启动，则本实例是主库，提供读写，其他实例仅提供读

多主模式切换单主模式

# 所有节点执行

mysql>stop group_replication

mysql>set global group_replication_enforce_update_everywhere_checks=OFF

mysql>set global group_replication_single_primary_mode=on

# 主节点（172.16.2.185）执行

set global group_replication_bootstrap_group=on

start GROUP_REPLICATION

set global group_replication_bootstrap_group=OFF

# 从节点（3307、3308）执行

start GROUP_REPLICATION

# 查看MGR组信息

mysql>select * from performance_schema.replication_group_members

单主切换到多主模式

MGR切换模式需要重新启动组复制，因些需要在所有节点上先关闭组复制，设置 group_replication_single_primary_mode=OFF 等参数，再启动组复制。

# 停止组复制(所有节点执行)：

mysql>stop group_replication

mysql>set global group_replication_single_primary_mode=OFF

mysql>set global group_replication_enforce_update_everywhere_checks=ON

# 随便选择某个节点执行

mysql>SET GLOBAL  group_replication_bootstrap_group=ON

mysql>START GROUP_REPLICATION

mysql>SET GLOBAL  group_replication_bootstrap_group=OFF

# 其他节点执行

mysql>STARTGROUP_REPLICATION

msyql 5.7

# 查看MGR组信息

SELECT * FROM performance_schema.replication_group_members

查看读写权限

select @@read_only, @@super_read_only

show variables like 'read_only'

mysql 8.0

# 查看MGR组信息

mysql>SELECT * FROM performance_schema.replication_group_members

可以看到所有节点状态都是online，角色都是PRIMARY(mysql 8.0)，MGR多主模式搭建成功。

验证:读写权限

写入数据测试:

---