数据库
首页 > 数据库> > MYSQL MGR 从入门到精通 02

MYSQL MGR 从入门到精通 02

作者：互联网

12 MGR性能

本节介绍如何使用可用的系统变量对组复制进行性能优化，以便获得最佳性能。
6.1. 微调组通信线程
当加载并启动MGR插件时，组通信线程(GCT)就会不断循环运行。GCT接收来自组和MGR插件的消息，处理与仲裁和故障检测相关的任务，发送一些保活的通讯消息，还处理MySQL Server与组之间传入和传出的事务。GCT会等待队列中的传入消息。当队列中没有消息时，GCT将会进行等待。在某些情况下，通过将这个等待配置得稍微长一些（进行主动等待），可以减少操作系统执行上下文切换时从处理器中换出GCT线程的次数。
要强制GCT执行主动等待，请使用系统变量group_replication_poll_spin_loops进行设置，这使得 GCT 在对下一个消息进行实际轮询队列之前，在已配置的循环次数内进行循环时不做任何相关操作（该系统变量设置的值表示需要等待通信引擎互斥锁(mutex)被释放的次数，不是时间单位）。


mysql> SET GLOBAL group_replication_poll_spin_loops= 10000;

6.2. 流量控制
组复制可确保事务仅在组中的大多数成员接收到它，且并发发送的所有事务在所有接收到事务的成员之间的相对顺序达成一致后，就可以执行事务的提交操作。如果对组的写入并发事务总数不超过组中任何成员的写入容量（提供写服务的能力），则此方法可以获得很好的性能。但如果组中所有成员能够提供的最大写服务能力不相同，那么组中服务能力低的成员可能出现数据延迟（例如：一些成员能提供3000TPS的写能力，但是有一些成员只能提供2000TPS的写能力），那么，当对能够提供3000TPS的成员写入并发3000的事务时，只能提供2000TPS的成员就会出现延迟（数据落后于能够提供3000TPS的成员）。
组中如果有成员出现数据延迟，将有可能导致应用程序对这些成员执行读操作时，读取到非常陈旧的数据，另外，组中的其他不存在数据延迟的成员或多或少需要保存一些复制上下文（binlog日志记录），以满足来自存在数据延迟的慢速成员潜在的数据传输请求。但是，复制协议中有一种机制可以避免在快成员和慢成员之间存在过大的事务差距。这就是所谓的流量控制机制。流量控制机制图解决如下几个问题：

MGR 插件架构如上图所示，压缩功能在插件的五层（位于MySQL Server和复制组之间，刨去MySQL Server层，它是MGR插件的第四层，也就是组通讯引擎层)。压缩和解压缩的工作任务由组通信系统API处理。压缩发生在数据被传递给组通信线程之前的组通讯引擎，所以它发生在MySQL 用户会话线程的上下文中。事务有效负载可能在发送到组之前进行压缩，在接收之后进行解压缩。压缩是有条件的，并且依赖于一个配置的阈值。压缩功能默认启用。
此外，并不要求组中的所有成员都启用压缩来协同工作。在收到消息后，成员会检查消息信封以验证它是否已被压缩。如果需要，则该成员在将事务交付给上层组件之前会对其进行解压。
使用的压缩算法是LZ4。默认情况下启用压缩，阈值为1000000字节（1M）。压缩阈值（以字节为单位）可以根据需要设置为比默认值更大的值。当压缩阈值不为0时，只有有效负载大于阈值的事务才会被压缩。设置压缩阈值示例如下：

# 这将压缩阈值设置为2MB。如果事务生成的复制消息的有效负载大于2MB，例如：二进制日志事务条目大于2MB，则对其进行压缩。若要禁用压缩，请将阈值设置为0。
STOP GROUP_REPLICATION;
SET GLOBAL group_replication_compression_threshold= 2097152;
START GROUP_REPLICATION;

6.4. 消息分段
当在组复制组成员之间发送异常大的消息时，可能导致某些组成员发生失败并被驱逐出组。这是因为组复制的组通信引擎（XCom, Paxos变体）使用的单个线程占用的处理消息的时间太长，因此某些组成员可能会报告消息接收失败。默认情况下，从MySQL 8.0.16开始，大的消息被自动分割成片段，分别发送，然后由接收者重新组合这些消息片段。
系统变量group_replication_communication_max_message_size指定组复制通信的最大消息大小，超过该大小的消息将被分段。默认的最大消息大小是10485760字节(10 MiB)。该系统变量的最大允许值与系统变量slave_max_allowed_packet的最大值相同（后者是1073741824字节，即 1GB），系统变量group_replication_communication_max_message_size的设置值必须小于系统变量slave_max_allowed_packet的设置值，因为应用线程不能处理大于系统变量slave_max_allowed_packet的消息片段。要关闭消息分段功能，请将系统变量
group_replication_communication_max_message_size设置为零值。
与大多数其他组复制系统变量一样，修改系统变量group_replication_communication_max_message_size必须重新启动组复制才能使更改生效。例如：


STOP GROUP_REPLICATION;
SET GLOBAL group_replication_communication_max_message_size= 5242880;
START GROUP_REPLICATION;

当所有组成员都接收并重新组合了消息的所有片段时，就认为分段消息的消息传递已经完成了。分段消息的头部包含了一些信息，这些信息使成员能够在消息传输期间加入组，并恢复加入组之前发送的早期消息片段。如果joiner节点无法恢复消息片段，则会将自己从组中驱逐出去。
为了让一个复制组正常使用消息分段功能，所有组成员必须运行MySQL 8.0.16或以上版本，并且组使用的组复制通信协议版本必须支持消息分段。可以使用group_replication_get_communication_protocol() UDF检查组使用的通信协议版本是多少，UDF 返回版本号字符串代表了组支持的最老的MySQL Server版本。MySQL 5.7.14的版本支持压缩消息，MySQL 8.0.16的版本支持消息分段。如果所有组成员都运行在MySQL 8.0.16以上版本，并且组中不需要运行更低版本的组成员，则可以使用group_replication_set_communication_protocol UDF()来设置通信协议版本为MySQL 8.0.16及其以上，这样就能够确保消息分段功能在组中所有成员上正常运行。有关更多信息，请参见"4.1.4. 设置组的通信协议版本”。
如果复制组由于某些成员不支持消息分段导致组不能使用消息分段，则可以使用系统变量group_replication_transaction_size_limit来限制该组所接受的最大事务大小。在MySQL 8.0中，默认设置大约为143 MB。超过这个大小的事务将被回滚。还可以使用系统变量group_replication_member_expel_timeout来设置一个在成员被驱逐出组之前，它被怀疑失败的额外时间（默认为0，从8.0.14版本开始，最大值为一个小时）。即，在该系统变量设置的时间内，被怀疑的成员不会被驱逐出组。
6.5. XCom 缓存管理
用于组复制的组通信引擎（XCom, Paxos变体）包含了一个消息（及其元数据）缓存，该消息是作为组成员之间交换协商一致性协议的一部分。在其他用途中，消息缓存可用于在一段时间内无法与其他组成员通信的成员在重新返回到组使进行恢复。
从MySQL 8.0.16开始，可以使用系统变量
group_replication_message_cache_size为XCom的消息缓存设置缓存大小限制。这个系统变量的默认值和最小值为1 GB，即MySQL Server 8.0.16 版本之前的消息缓存大小设置。如果达到了缓存大小限制设置，XCom将删除已经确定和交付的最老的条目。考虑到MySQL Server的其他缓存和对象池的大小，请确保在系统上有足够的内存来满足所设置的缓存大小限制。
如果一个不可达成员尝试重新恢复连接时，需要一条恢复消息，但该消息已从消息缓存中删除，则该成员无法重新连接。如果使用了系统变量group_replication_member_expel_timeout（该系统变量在MySQL 8.0.13中引入）指定一个额外的延迟时间，则更有可能出现这种情况。当不可达的成员恢复时可能需要使用到的消息在消息缓存中已经被删除时，组复制的组通信系统(GCS)通过一条警告消息来发出警告。此警告消息记录在所有活跃的组成员上（对于每个不可到达的成员仅记录一次）。尽管组成员不能确定不可到达的成员最后看到的消息是什么消息，但是警告消息表明缓存大小可能不足以支撑通过系统变量group_replication_member_expel_timeout设置的在驱逐成员之前的等待时间内总的消息大小。在这种情况下，可以增加缓存大小限制，以便消息缓存能够存放组成员重新加入组所需的所有遗漏消息。
如果考虑减少缓存大小限制，可以使用以下语句先查询
performance_schema.memory_summary_global_by_event_name表中记录的相关内存分配情况：

# 查询语句返回消息缓存的内存使用统计信息，包括当前缓存条目的数量和当前缓存的大小。如果降低了缓存大小限制，XCom将删除已经确定并交付的最老的条目，直到当前大小低于限制值为止。在删除最老的条目过程进行期间，XCom可能会暂时超过缓存大小限制。
mysql> SELECT * FROM performance_schema.memory_summary_global_by_event_name
  WHERE EVENT_NAME LIKE 'memory/group_rpl/GCS_XCom::xcom_cache';

6.6. 对故障检测和网络分区的响应
组复制的故障检测机制旨在识别不能与组正常通信的组成员，并在他们可能发生故障时将他们从组中驱逐出去。当组中有成员发生故障时，如果组中存在多数成员存活，则故障检测机制能够使得组正确恢复可用性，以便能够及时恢复并正确处理客户端的请求。
通常，所有组成员会定期与所有其他组成员交换消息。如果一个组成员在5秒内没有收到来自某个特定成员的任何消息，当这个检测周期结束时，就会产生对该成员的怀疑。当一个可疑成员超时时（在最大允许的怀疑时间范围内仍然没有任何消息），该可疑成员就被认定为失败了，并被驱逐出组。被驱逐的成员会被组中所有活跃成员从组成员资格列表中删除，但被驱逐的成员自己可能不知道已经被驱逐出组（例如：它自己还在线，只是无法联系其他成员）。如果被驱逐的成员实际上没有失败（例如，因为临时网络问题而断开连接），并且后续能够恢复与其他成员的正常通信，则在网络恢复之后它会收到一个包含了该成员已被驱逐出该组的新视图信息。
组成员（包括失败的成员本身）对这些情况的响应可以在流程中的许多地方进行配置。默认情况下，如果怀疑某个成员失败，则会发生以下行为：

分布式恢复不可用

组配置进行了错误的修改

选主出错

多数成员不可达超时

被驱逐出组的成员

超过自动重新加入组尝试次数仍未成功加入组的成员

系统变量super_read_only设置为ON
或

系统变量offline_mode和super_read_only设置为ON
或

MySQL Server关闭

同左

13 MGR安全

本节从组复制的IP白名单以及安全套接字(SSL)支持两个方面来介绍如何保护组合组成员之间连接的安全性。

5.1. 组复制的IP地址白名单
MGR插件有一个系统变量group_replication_ip_whitelist，用于确定可以接受从哪个主机传入的组通信系统连接。假设Server S1中设置了该系统变量，然后使用S1引导组启动，之后，将Server S2作为joiner节点，当S2尝试与S1建立组通讯连接时，S1在接受S2的组通讯连接请求之前，先检查系统变量group_replication_ip_whitelist的设置是否允许S2访问，如果允许，则接受S2的组通讯连接请求，否则拒绝S2的组通讯连接请求。
如果没有显式地指定白名单，则S1的组通信引擎(XCom)将自动扫描S1所在主机上的活跃网卡接口，并根据这些活跃网卡接口上配置的IP地址生成相应的子网地址（包括IPV4和IPV6地址）。根据这些生成的子网地址来自动创建一个组复制的白名单设置。自动生成的IP白名单地址可能包含如下范围：

IPv4 (在RFC 1918中定义的IPV4地址的划分)
# A类地址
10/8 (IP范围：10.0.0.0-10.255.255.255) 
# B类地址
172.16/12 (IP范围：172.16.0.0-172.31.255.255) 
# C类地址
192.168/16 (IP范围：192.168.0.0-192.168.255.255) -
IPv6 ( 在RFC 4193 和 RFC 5156中定义的IPV6地址的划分)
# 唯一的本地地址前缀（范围）
fc00:/7
# 本地链路的单播地址前缀（范围）
fe80::/10
# 本地(localhost)IPv4地址
127.0.0.1 - localhost for IPv4
# 本地(localhost)IPv6地址
::1 - localhost for IPv6

在MySQL的错误日志中会记录自动为主机添加的白名单地址信息。
从上面代码段中所述的IP范围我们可以看到，自动生成的白名单地址都是私有网络地址（即便主机上配置有公网IP地址，也不会生成公网地址网络的白名单），而私有地址只允许在私有网络内访问，不允许在公网上访问。因为，如果要使用公网地址作为白名单，则，你需要使用系统变量group_replication_ip_whitelist来显式指定你希望允许开放访问的公网地址范围，另外，一旦为系统变量group_replication_ip_whitelist指定值之后，自动生成白名单的功能就失效了，未在系统变量group_replication_ip_whitelist中指定的任何地址都不允许访问，因此，任何希望允许访问的IP地址范围，你都需要显式指定。
如果某个Server是组中的活跃成员，则不允许动态修改白名单地址，必须先执行STOP GROUP_REPLICATION语句停止组复制，让其主动脱离组，配置好白名单之后，再执行START GROUP_REPLICATION语句让其重新申请加入组。否则会报错：ERROR 3093 (HY000): The IP whitelist cannot be set while Group Replication is running。
如果要显式指定白名单地址，则，可以使用如下一些有效的字符串形式指定：

# 先停止组复制
mysql> STOP GROUP_REPLICATION;
# 修改白名单地址
mysql> SET GLOBAL group_replication_ip_whitelist="192.0.2.21/24,198.51.100.44,203.0.113.0/24,2001:db8:85a3:8d3:1319:8a2e:370:7348,example.org,www.example.com/24";
# 重新启动组复制
mysql> START GROUP_REPLICATION;

白名单必须包含每个成员的系统变量group_replication_local_address中指定的IP地址或主机名。这个地址与MySQL Server的SQL协议主机和端口不一样（系统变量group_replication_local_address指定的地址和端口是用于组成员之间的组通讯的，而不是对外提供业务访问的）。
要成功加入复制组，则给定的待加入组的Server的IP地址需要在其请求加入组的种子成员的白名单中需要允许其发起组通讯请求。通常，是根据种子成员（即组的引导成员）的系统变量group_replication_group_seeds设置的IP进行适配，但是，也可以根据组中的任意成员的系统变量group_replication_group_seeds指定的值进行设定，例如：组中的成员混合使用了IPV4和IPV6地址，那么，建议将所有成员可能会用于组通讯的网络的IPV4和IPV6协议地址一并配置到白名单中，以避免出现有Server申请加入组时被拒绝连接的情况发生。有关管理混合IPv4和IPv6复制组的更多信息，请参见"4.5. 配置支持IPv6和混合IPv6与IPv4地址的组"。
当复制组被重新配置时（例如，当选举一个新的主要节点或者一个成员脱离组时），组成员会重新建立它们之间的连接。如果组中的所有成员的白名单地址配置不一致，在重新配置组之后，可能导致某个成员在重新配置组之前允许加入组的而在重新配置组之后无法重新加入组（例如：组中有3个成员S1、S2、S3，当S3脱离组并重新配置组时，因为白名单不一致的原因，S2不允许S1访问，S3允许S1访问，但是现在S3已经不在组中了，这就会导致S3脱离组之后，S1和S2也无法组成新的组）。要完全避免这种情况，建议在组中的所有成员中设置一致的白名单。
对于主机名的白名单设置，仅当有另外一个Server发起连接请求时才会进行名称解析。无法解析的主机名不会用于白名单验证，且会将警告信息写入MySQL错误日志中。
注意：主机名用作白名单，安全性不如IP地址，除非必须，否则不建议使用外部组件来实现名称解析（除非外部组件的安全性你能够把控），如果有临时需要，可以考虑使用本地主机中的/etc/hosts解析记录实现
5.2. 组复制安全套接字层(SSL)支持
我们可以使用SSL来保护组成员之间的通信连接和分布式恢复的连接。本节将介绍如何配置SSL的连接。
5.2.1. 为组通信配置SSL
安全套接字可用于组成员之间的组通信连接。MGR插件的系统变量group_replication_ssl_mode控制组通讯连接是否启用SSL，并为组通讯连接指定安全模式。默认设置为DISABLED，表示不使用SSL。该系统变量有如下有效值：

MYSQL MGR 从入门到精通 02
复制的组通信连接的其余SSL相关的配置通过MySQL Server的SSL系统变量进行配置。这些SSL系统变量如下：

![](http://www.icode9.com/i/li/?n=4&i=images/blog/202103/01/69f86cfadbc900c19d4e18ff204fd6e8.png?,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)

重要事项：


[mysqld]
# 为MySQL Server配置好SSL相关的系统变量
ssl_ca = "cacert.pem"
ssl_capath = "/.../ca_directory"
ssl_cert = "server-cert.pem"
ssl_cipher = "DHE-RSA-AEs256-SHA"
ssl_crl = "crl-server-revoked.crl"
ssl_crlpath = "/.../crl_directory"
ssl_key = "server-key.pem"
# 为组复制激活SSL，设置为REQUIRED时，如果组成员之间支持安全连接，则建立安全连接
group_replication_ssl_mode= REQUIRED

5.2.2. 为分布式恢复配置SSL
当一个Server申请加入组时，会组合使用远程克隆操作（如果可用）和异步复制连接来执行分布式恢复。这两种状态传输的方法都需要为分布式恢复设置复制用户，如"2.1.3. 用户凭证"中所述。申请加入组时使用的复制用户需要在执行申请加入组之前提前在组的现有成员中创建好（如果需要使用SSL也需要提前配置好SSL），可以使用如下语句来创建复制用户并启用SSL。


donor> SET SQL_LOG_BIN=0;
donor> CREATE USER 'rec_ssl_user'@'%' REQUIRE SSL;
donor> GRANT replication slave ON *.* TO 'rec_ssl_user'@'%';
donor> GRANT BACKUP_ADMIN ON *.* TO 'rec_ssl_user'@'%';
donor> SET SQL_LOG_BIN=1;

假设在组中的所有成员中都已经配置好了一个启用SSL的复制用户，则，可以通难过如下语句来为组复制的恢复通道配置使用该用户，当启动组复制时，复制恢复通道将使用这些凭据来连接其他组成员，如下所示：


new_member> CHANGE MASTER TO MASTER_USER="rec_ssl_user" FOR CHANNEL "group_replication_recovery";

要配置安全的分布式恢复连接，请使用组复制专用的分布式恢复SSL系统变量。这些变量对应用于组通信连接的Server SSL系统变量值，但它们仅适用于分布式恢复的连接。默认情况下，分布式恢复连接不使用SSL，即使为组通信连接激活了SSL，这些Server SSL系统变量也不会应用于分布式恢复连接。必须单独配置组复制专用的SSL系统变量才会生效。
如果将远程克隆操作用作分布式恢复的一部分，则组复制将自动配置克隆插件的SSL系统变量，以匹配对分布式恢复SSL系统变量的设置。
分布式恢复的专用SSL系统变量如下：

new_member> SET GLOBAL group_replication_recovery_use_ssl=1;
new_member> SET GLOBAL group_replication_recovery_ssl_ca= '.../cacert.pem';
new_member> SET GLOBAL group_replication_recovery_ssl_cert= '.../client-cert.pem';
new_member> SET GLOBAL group_replication_recovery_ssl_key= '.../client-key.pem';

14 MGR在线配置

组复制处于运行状态时，可以使用一组依赖于组操作协调器的UDF自定义函数来对组做一些在线变更操作。这些UDF 由8.0.13或更高版本的MGR插件提供。本节描述如何使用这些UDF自定义函数来对组进行在线进行一些变更操作。

要使用UDF，使用客户端程序连接到组中的任意成员，并使用SELECT语句执行UDF调用。MGR插件会处理该操作及其相关的参数调整，协调器会将此操作发送给组中所有成员（执行此操作能够看到的所有组成员）。如果该操作被接受，所有成员都将执行该操作。一旦所有成员都声明操作已完成时，调用UDF的成员会将执行结果返回给客户端。

在配置整个组时，操作的分布式特性意味着它们与MGR插件有许多进程交互，因此需要注意以下几点：

4.1.1. 修改组的主要节点
本节介绍在单主模式的组中如何使用UDF自定义函数来更改主要节点。用于更改组中主要节点的函数可以在任何成员上运行。
通过使用group_replication_set_as_primary() UDF来更改单主模式的组中的主要节点（如果组运行在多主模式下，则执行该函数不会有任何影响）。单主模式的组中，只有主要节点才允许数据写入（其他成员为辅助节点，只能接受只读请求），因此，如果在该成员（主要节点）上正在运行异步通道（这里指的是主要节点还同时作为主从复制拓扑中的从库），则在停止异步通道之前不允许切换主要节点。
如果在MySQL 8.0.17或以上版本的组成员上执行UDF调用，且组中所有成员都运行在MySQL 8.0.17或以上版本，那么只能基于补丁版本（次要版本，例如：MySQL 8.0.17中，8.0是主要版本，17是次要版本）指定一个组中版本号最低的MySQL服务器作为新的主要节点。此保护措施用于确保组中新功能特性的兼容性。但，如果任何成员运行在MySQL 8.0.13和MySQL 8.0.16之间的版本，则不会对组强制执行此保护措施，可以指定任何成员为主要节点，但为了避免出现一些不兼容的意外发生，建议选择组中版本号最低的成员作为主要节点。
修改组中的主要节点时，使用group_replication_set_as_primary函数并指定将要切换为主要节点的成员server_uuid，如下：

# 查询组成员的状态信息，可以看到当前node1为主要节点（MEMBER_ROLE列值为PRIMARY）

root@localhost : performance_schema:55: > select * from replication_group_members;

+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |

+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

| group_replication_applier | 2d283e92-de7b-11e9-a14d-525400c33752 | node2 | 3306 | ONLINE | SECONDARY | 8.0.17 |

| group_replication_applier | 2e33b2a7-de7b-11e9-9a21-525400bdd1f2 | node3 | 3306 | ONLINE | SECONDARY | 8.0.17 |

| group_replication_applier | 320675e6-de7b-11e9-b3a9-5254002a54f2 | node1 | 3306 | ONLINE | PRIMARY | 8.0.17 |

+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

3 rows in set (0.01 sec)

# 指定node2为新的主要节点

root@localhost : performance_schema:55: > SELECT group_replication_set_as_primary('2d283e92-de7b-11e9-a14d-525400c33752');

+--------------------------------------------------------------------------+

| group_replication_set_as_primary('2d283e92-de7b-11e9-a14d-525400c33752') |

+--------------------------------------------------------------------------+

| Primary server switched to: 2d283e92-de7b-11e9-a14d-525400c33752 |

+--------------------------------------------------------------------------+

1 row in set (0.03 sec)

# 再次查看组成员状态信息，可以发现node2已经被切换为了主要节点

root@localhost : performance_schema:56: > select * from replication_group_members;

+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |

+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

| group_replication_applier | 2d283e92-de7b-11e9-a14d-525400c33752 | node2 | 3306 | ONLINE | PRIMARY | 8.0.17 |

| group_replication_applier | 2e33b2a7-de7b-11e9-9a21-525400bdd1f2 | node3 | 3306 | ONLINE | SECONDARY | 8.0.17 |

| group_replication_applier | 320675e6-de7b-11e9-b3a9-5254002a54f2 | node1 | 3306 | ONLINE | SECONDARY | 8.0.17 |

+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

3 rows in set (0.00 sec)

当操作运行时，您可以通过执行以下语句来检查其进度。

# 注：events_stages_current表是记录线程当前正在执行的事件信息，所以只有线程正在执行某个语句时才能够查询到事件信息，一旦线程执行完成，事件信息就会被清除

root@localhost : performance_schema:58: > SELECT event_name, work_completed, work_estimated FROM performance_schema.events_stages_current WHERE event_name LIKE "%stage/group_rpl%";

+----------------------------------------------------------------------------------+----------------+----------------+

| event_name | work_completed | work_estimated |

+----------------------------------------------------------------------------------+----------------+----------------+

| stage/group_rpl/Primary Election: Waiting for members to turn on super_read_only | 3 | 5 |

+----------------------------------------------------------------------------------+----------------+----------------+

4.1.2. 修改组的运行模式
本节介绍了如何修改组的运行模式，无论是单主模式还是多主模式。用于修改组运行模式的函数可以在组中任何成员上运行。但是。

4.1.2.1. 切换到多主模式
假设组已经处于单主模式，使用group_replication_switch_to_multi_primary_mode() UDF执行如下语句，将单主模式下运行的组修改为多主模式：

# 查查看组成员的状态信息，可以发现目前组处于单主模式（有一个PRIMARY成员，2个SECONDARY成员）

root@localhost : performance_schema:30: > select * from replication_group_members;

+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |

+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

| group_replication_applier | 2d283e92-de7b-11e9-a14d-525400c33752 | node2 | 3306 | ONLINE | PRIMARY | 8.0.17 |

| group_replication_applier | 2e33b2a7-de7b-11e9-9a21-525400bdd1f2 | node3 | 3306 | ONLINE | SECONDARY | 8.0.17 |

| group_replication_applier | 320675e6-de7b-11e9-b3a9-5254002a54f2 | node1 | 3306 | ONLINE | SECONDARY | 8.0.17 |

+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

3 rows in set (0.00 sec)

# 查看组模式系统变量值，发现已经被启用，组处于单主模式下

root@localhost : performance_schema:12: > show variables like '%group_replication_single_primary_mode%';

+---------------------------------------+-------+

| Variable_name | Value |

+---------------------------------------+-------+

| group_replication_single_primary_mode | ON |

+---------------------------------------+-------+

1 row in set (0.01 sec)

# 执行如下语句切换到多主模式（不能指定组成员的系统变量server_uuid值作为参数，否则报错："ERROR 1123 (HY000): Can't initialize function 'group_replication_switch_to_multi_primary_mode'; Wrong arguments: This function takes no arguments."）

root@localhost : performance_schema:38: > SELECT group_replication_switch_to_multi_primary_mode();

+--------------------------------------------------+

| group_replication_switch_to_multi_primary_mode() |

+--------------------------------------------------+

| Mode switched to multi-primary successfully. |

+--------------------------------------------------+

1 row in set (1.02 sec)

# 再次查看组成员状态信息，可以发现3个成员的MEMBER_ROLE列值都为PRIMARY，表示此时3个组成员都可读写

root@localhost : performance_schema:39: > select * from replication_group_members;

+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |

+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

| group_replication_applier | 2d283e92-de7b-11e9-a14d-525400c33752 | node2 | 3306 | ONLINE | PRIMARY | 8.0.17 |

| group_replication_applier | 2e33b2a7-de7b-11e9-9a21-525400bdd1f2 | node3 | 3306 | ONLINE | PRIMARY | 8.0.17 |

| group_replication_applier | 320675e6-de7b-11e9-b3a9-5254002a54f2 | node1 | 3306 | ONLINE | PRIMARY | 8.0.17 |

+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

3 rows in set (0.01 sec)

# 再次查看组模式系统变量，发现已经被关闭，组处于多主模式下

root@localhost : performance_schema:10: > show variables like '%group_replication_single_primary_mode%';

+---------------------------------------+-------+

| Variable_name | Value |

+---------------------------------------+-------+

| group_replication_single_primary_mode | OFF |

+---------------------------------------+-------+

1 row in set (0.00 sec)

上述步骤中，调用group_replication_switch_to_multi_primary_mode() 函数之后，组内经过一些能够确保数据的安全性和一致性的协调操作之后，组中所有的成员都成为了主要节点。

root@localhost : (none):48: > SELECT event_name, work_completed, work_estimated FROM performance_schema.events_stages_current WHERE event_name LIKE "%stage/group_rpl%";

+----------------------------------------------------------------------+----------------+----------------+

| event_name | work_completed | work_estimated |

+----------------------------------------------------------------------+----------------+----------------+

| stage/group_rpl/Multi-primary Switch: applying buffered transactions | 0 | 1 |

+----------------------------------------------------------------------+----------------+----------------+

4.1.2.2. 切换到单主模式
假设组已经处于多主模式，使用group_replication_switch_to_single_primary_mode() UDF将运行在多主模式的组更改为单主模式，当切换到单主模式时，同时还会禁用所有组成员上的严格一致性检查(group_replication_mandatory _update_everywhere_check =OFF)，因为单主模式要求组关闭严格一致性检查。
在调用group_replication_switch_to_single_primary_mode() UDF时，可以为其指定一个成员的server_uuid字符串作为参数，这样指定的成员将成为新的主要节点，如果未指定，则将自动根据选举策略选出新的主要节点。示例如下：

# 先查看一下组成员的状态信息，可以发现此时3个成员都为主要节点

root@localhost : performance_schema:40: > select * from replication_group_members;

+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |

+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

| group_replication_applier | 2d283e92-de7b-11e9-a14d-525400c33752 | node2 | 3306 | ONLINE | PRIMARY | 8.0.17 |

| group_replication_applier | 2e33b2a7-de7b-11e9-9a21-525400bdd1f2 | node3 | 3306 | ONLINE | PRIMARY | 8.0.17 |

| group_replication_applier | 320675e6-de7b-11e9-b3a9-5254002a54f2 | node1 | 3306 | ONLINE | PRIMARY | 8.0.17 |

+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

3 rows in set (0.00 sec)

# 查看组模式系统变量，发现此时单主模式被关闭，组处于多主模式下

root@localhost : performance_schema:10: > show variables like '%group_replication_single_primary_mode%';

+---------------------------------------+-------+

| Variable_name | Value |

+---------------------------------------+-------+

| group_replication_single_primary_mode | OFF |

+---------------------------------------+-------+

1 row in set (0.00 sec)

# 执行模式切换，指定一个组成员的server_uuid作为group_replication_switch_to_single_primary_mode() UDF的参数

root@localhost : performance_schema:07: > SELECT group_replication_switch_to_single_primary_mode('320675e6-de7b-11e9-b3a9-5254002a54f2');

+-----------------------------------------------------------------------------------------+

| group_replication_switch_to_single_primary_mode('320675e6-de7b-11e9-b3a9-5254002a54f2') |

+-----------------------------------------------------------------------------------------+

| Mode switched to single-primary successfully. |

+-----------------------------------------------------------------------------------------+

1 row in set (0.02 sec)

# 再次查看组成员的状态信息，可以发现指定的server_uuid(mode1)成员成为了主要节点

root@localhost : performance_schema:08: > select * from replication_group_members;

+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |

+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

| group_replication_applier | 2d283e92-de7b-11e9-a14d-525400c33752 | node2 | 3306 | ONLINE | SECONDARY | 8.0.17 |

| group_replication_applier | 2e33b2a7-de7b-11e9-9a21-525400bdd1f2 | node3 | 3306 | ONLINE | SECONDARY | 8.0.17 |

| group_replication_applier | 320675e6-de7b-11e9-b3a9-5254002a54f2 | node1 | 3306 | ONLINE | PRIMARY | 8.0.17 |

+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

3 rows in set (0.00 sec)

# 再次查看组模式系统变量值，发现已经被启用，组处于单主模式下

root@localhost : performance_schema:12: > show variables like '%group_replication_single_primary_mode%';

+---------------------------------------+-------+

| Variable_name | Value |

+---------------------------------------+-------+

| group_replication_single_primary_mode | ON |

+---------------------------------------+-------+

1 row in set (0.01 sec)

如果在运行MySQL 8.0.17及其更高版本的组成员上调用UDF，且所有成员都运行在MySQL 8.0.17或更高版本中，且组中存在不同版本的组成员时，则，只能基于补丁版本指定组中最低MySQL Server版本的成员做为主要节点。此保护措施用于确保组与新功能保持兼容性。如果没有为UDF指定新的主要节点，则选举过程中将会考虑组成员的补丁版本（自动选举组中最低版本的成员作为主要节点）。
如果任何成员正在运行MySQL 8.0.13和MySQL 8.0.16之间的MySQL Server版本，则不会对组强制执行此保护，可以指定任何新的组成员作为主要节点，但建议选择组中最低MySQL Server版本的成员作为主要节点。如果没有指定新的主要节点，则选举过程只考虑组成员的主要版本（选举最低主版本的成员作为主要节点）。

当函数运行过程中（未执行完成），您可以通过执行如下语句来检查其执行进度。

root@localhost : performance_schema:24: > SELECT event_name, work_completed, work_estimated FROM performance_schema.events_stages_current WHERE event_name LIKE "%stage/group_rpl%";

+----------------------------------------------------------------------------+----------------+----------------+

| event_name | work_completed | work_estimated |

+----------------------------------------------------------------------------+----------------+----------------+

| stage/group_rpl/Primary Switch: waiting for pending transactions to finish | 4 | 20 |

+----------------------------------------------------------------------------+----------------+----------------+

4.1.3. 设置组并发可写实例数
本节介绍如何检查和配置一个组中的最大并行可写实例数（即，并行在组成员之间广播传输的最大并发可写实例数）。这个最大值称为组的事件范围，可以通过调整该值来优化组复制的性能。例如：默认值10适用于在LAN上运行的组，但是对于在WAN等速度较慢的网络上运行的组，可以通过增加这个数字来提高性能。
检查组的写并发性：使用group_replication_get_write_concurrency() UDF在运行时检查组的事件范围值（注：该函数不需要传入参数），如下：

root@localhost : performance_schema:04: > select group_replication_get_write_concurrency();

+-------------------------------------------+

| group_replication_get_write_concurrency() |

+-------------------------------------------+

| 10 |

+-------------------------------------------+

1 row in set (0.00 sec)

配置组的写并发性：使用group_replication_set_write_concurrency() UDF设置组可以并行执行的可写实例的最大数量，如下：


root@localhost : performance_schema:04: > select group_replication_set_write_concurrency(100);

+-----------------------------------------------------------------------------------+

| group_replication_set_write_concurrency(100) |

+-----------------------------------------------------------------------------------+

| UDF is asynchronous, check log or call group_replication_get_write_concurrency(). |

+-----------------------------------------------------------------------------------+

1 row in set (0.00 sec)

PS：

root@localhost : (none):56: > SELECT group_replication_get_communication_protocol();

+------------------------------------------------+

| group_replication_get_communication_protocol() |

+------------------------------------------------+

| 8.0.16 |

+------------------------------------------------+

1 row in set (0.00 sec)

如果需要更改组的通信协议版本，以便使用更早期版本的成员可以加入组，可以使用group_replication_set_communication_protocol() UDF指定你希望允许加入组的最老的MySQL Server版本。如果指定的旧版本成员成功加入组，则将使组退回到兼容的通信协议版本（最低版本的成员支持的通讯协议版本）。使用该UDF需要用户具有GROUP_REPLICATION_ADMIN权限，当执行该语句时，所有组中的现有成员都必须在线（组可用），如下：

# 注意：group_replication_get_communication_protocol () UDF返回的是组中支持的最低MySQL Server版本（组中声明的通讯协议版本），这可能与使用group_replication_set_communication_protocol () UDF设置组的通讯协议版本时传递给它的版本不同、也可能与组中的最低成员的MySQL Server版本不同（这一点上文中已经提到过了）

root@localhost : (none):32: > SELECT group_replication_set_communication_protocol("5.7.25");

+-----------------------------------------------------------------------------------+

| group_replication_set_communication_protocol("5.7.25") |

+-----------------------------------------------------------------------------------+

| The operation group_replication_set_communication_protocol completed successfully |

+-----------------------------------------------------------------------------------+

1 row in set (0.00 sec)

root@localhost : (none):32: > SELECT group_replication_get_communication_protocol();

+------------------------------------------------+

| group_replication_get_communication_protocol() |

+------------------------------------------------+

| 5.7.14 |

+------------------------------------------------+

1 row in set (0.00 sec)

如果将组中所有成员都升级到新的MySQL Server版本，则组不会自动将该组的通信协议版本升级到匹配最新的版本。必须使用group_replication_set_communication_protocol() UDF将通信协议版本设置为最新MySQL Server版本。如下：

root@localhost : (none):32: > select version();

+-----------+

| version() |

+-----------+

| 8.0.17 |

+-----------+

1 row in set (0.00 sec)

root@localhost : (none):35: > SELECT group_replication_set_communication_protocol("8.0.17");

+-----------------------------------------------------------------------------------+

| group_replication_set_communication_protocol("8.0.17") |

+-----------------------------------------------------------------------------------+

| The operation group_replication_set_communication_protocol completed successfully |

+-----------------------------------------------------------------------------------+

1 row in set (0.01 sec)

root@localhost : (none):35: > SELECT group_replication_get_communication_protocol();

+------------------------------------------------+

| group_replication_get_communication_protocol() |

+------------------------------------------------+

| 8.0.16 |

+------------------------------------------------+

1 row in set (0.00 sec)

group_replication_set_communication_protocol() UDF作为一个组操作实现，因此它同时在组的所有成员上执行。执行该函数过程中，组操作会缓冲消息并等待通讯协议版本修改完成之后再将缓冲的消息发送出去。如果某个Server在更改通信协议版本后尝试加入组，则组中的成员将使用最新的通讯协议版本来决定是否允许该Server加入组。

14 MGR事务一致性

对于组复制这样的分布式系统来说，主要的需求之一是它需要有数据的一致性保证。换句话说，需要保证在组成员之间分布的事务的全局同步的一致性。本节将介绍组复制如何根据组中发生的事件处理一致性保证、以及如何最佳配置组的一致性保证。

4.2.1. 理解事务一致性保证
就分布式一致性保证而言，组复制无论是在正操或者故障修复的操作中，它始终是一个最终一致性的系统。这意味着一旦传入组复制的流量减慢或停止，所有组成员将具有相同的数据内容。与系统一致性相关的事件可以分为：手动操作或由故障自动触发的控制操作、数据流操作。
对于组复制，与一致性相关的控制操作包括：

# 若要在当前会话上强制执行一致性级别，用如下语句设置
mysql> SET @@SESSION.group_replication_consistency= 'BEFORE';

# 要在所有会话上强制执行一致性级别，使用如下语句设置
mysql> SET @@GLOBAL.group_replication_consistency= 'BEFORE';

在特定会话上设置一致性级别的场景可能有如下一些：

总而言之，除非必须，否则不需要全局针对所有事务都运行较高的一致性级别，特别是只有一部分事务有一致性级别要求的场景中。

注意：所有RW事务在组中都是全局排序的，所以，一旦在当前会话中设置会话级别的一致性级别为AFTER，则在该会话中执行RW事务时会等待其他成员应用完成该事务。也就是说，由于RW事务全局是排序的，而该RW事务是后发起的，所以，实际上等于还需要同时等待该RW事务之前所有的积压事务应用完成，而不仅仅只是该RW事务。

4.2.2.3. 一致性级别的影响
分类一致性级别的另一种方法是根据对组的影响进行划分，即一致性级别对其他成员的影响。
对于BEFORE一致性级别，除了在事务流上排序之外，它只影响本地成员，即，它不需要协调其他成员，也不影响其他成员的事务。换句话说，BEFORE一致性级别只影响使用该一致性级别的事务。
AFTER和BEFORE_AND_AFTER一致性级别对在其他成员上执行的并发事务具有副作用，当执行具有AFTER或BEFORE_AND_AFTER一致性级别的事务时，即使后续的事务是以EVENTUAL一致性级别运行的也仍然需要等待AFTER或BEFORE_AND_AFTER一致性级别的事务执行完成。对于其他成员也是如此。即，AFTER或BEFORE_AND_AFTER一致性级别会影响所有的ONLINE成员。
为了进一步说明这一点，假设一个组包含三个组成员：M1、M2、M3，在M1上执行了如下语句：

# 修改一致性级别为AFTER
mysql> SET @@SESSION.group_replication_consistency= AFTER;
# 执行一个INSERT语句
mysql> BEGIN;
mysql> INSERT INTO t1 VALUES (1); # 为了方便看到效果，这里最好是一个大事务
mysql> COMMIT;

然后，在应用上述事务时，对成员M2 执行如下语句：

# 修改一致性级别为EVENTUAL
mysql> SET SESSION group_replication_consistency= EVENTUAL;
# 执行DML事务，就可以发现M2执行的事务被阻塞，需要等待上述执行先执行完成。需要注意的是，如果在M2执行事务时，M1中的事务还没有被M2收到时，select语句是可以立即执行成功的，但如果M1中的事务被M2收到并进入队列之后，执行select ... for update语句也会被阻塞

只能在ONLINE状态的组成员中使用BEFORE、AFTER_AND_BEFORE一致性级别，试图在其他状态（其他状态包括：RECOVERING、OFFLINE、ERROR、UNREACHABLE）的成员上使用时会导致报错。
如果一个非EVENTUAL的一致性级别的事务执行时，持续等待且一直未返回，当达到了由统变量wait_timeout系配置的超时时间（默认为8小时）之后，会抛出ER_GR_HOLD_WAIT_TIMEOUT错误信息。

4.2.2.4. 一致性对选主的影响
本节描述在一个单主模式的主中，一致性级别是如何影响选主的（选举主要节点）。例如：组自动检测故障并调整处于活动状态的成员的视图，换句话说就是成员资格配置。此外，如果组以单主模式部署，每当组成员资格发生更改时，都会检查所有的组成员状态，以便检测组中是否仍然存在主要节点。如果没有，则从辅助节点成员列表中选择一个组成员提升为新的主要节点。这个过程就是选举一个辅助节点晋升为主要节点的过程。
当系统检测到故障并自动重新配置时，你也许希望一旦辅助节点晋升完成，则新的主要节点与旧的主要节点之间的数据状态相同。换句话说，你可能希望新的主要节点能够对外提供读写访问时，新的主要节点就已经应用完成了所有积压事务，即，一旦应用程序完成了故障转移到新的主要节点时，就不会读取或者修改陈旧的数据记录（即使是暂时的也不行）。
从MySQL 8.0.14版本开始，辅助节点晋升为主要节点之后，你可以指定新主要节点的行为，通过新增的系统变量group_replication_consistency来控制新的主要节点采用什么一致性级别（默认为EVENTUAL），如果设置为BEFORE_ON_PRIMARY_FAILOVER，则在对外提供读写访问之前，会先应用完成积压事务。这就确保了客户端完成了故障转移到新主要节点之后，能够看到最新数据。同时，也可以防止出现下列不正常的现象：

mysql> BEGIN;
# 假设x=1在t1表中，x=2还在积压事务中，那么，在这里需要等待积压事务应用完成，才能执行查询，以便读取到最新的数据x=2
mysql> SELECT x FROM t1; 
mysql> INSERT x INTO t2;
mysql> COMMIT;

以上事务如果不使用BEFORE_ON_PRIMARY_FAILOVER一致性级别，那么，将导致插入t2表中的值为x=1，而不是x=2（因为发生了读偏差），但是，无论是否设置为BEFORE_ON_PRIMARY_FAILOVER一致性级别，都不会导致写冲突，而最多只会发生读偏差，从而导致写入t2表的数据不是最新的。
为了确保组中所有的组成员无论谁被晋升为新的主要节点之后，都会提供相同的一致性级别，组的所有成员都应该在配置中持久化一致性级别为BEFORE_ON_PRIMARY_FAILOVER（或更高的一致性级别）。这可以防止应用程序故障转移完成之后查询到陈旧的数据，设置语句如下：


# 使用set语句将系统变量group_replication_consistency的值持久化为BEFORE_ON_PRIMARY_FAILOVER
root@localhost : (none):57: > SET PERSIST group_replication_consistency='BEFORE_ON_PRIMARY_FAILOVER';
Query OK, 0 rows affected (0.02 sec)

# 上述语句执行完成之后，该系统变量值会被持久化到auto.cnf文件中（该文件是一个JSON格式数组，且其中已经存在了组辅助的一些预设持久化变量，注意：对于使用 SET PERSIST语句持久化系统变量的操作，只会影响到当前成员，其他成员不会进行同步，所以，建议在所有组成员中都执行相同的操作）
[root@node1 ~]# cat /data//mysqldata1/mydata/mysqld-auto.cnf  
{ "Version" : 1 , "mysql_server" : { "group_replication_consistency" : { "Value" : "BEFORE_ON_PRIMARY_FAILOVER" , "Metadata" : { "Timestamp" : 1569841133777625 , "User" : "root" , "Host" : "localhost" } } , "mysql_server_static_options" : { "group
_replication_enforce_update_everywhere_checks" : { "Value" : "OFF" , "Metadata" : { "Timestamp" : 1569402731795015 , "User" : "mysql.session" , "Host" : "localhost" } } , "group_replication_single_primary_mode" : { "Value" : "ON" , "Metadata" : {
"Timestamp" : 1569402731795762 , "User" : "mysql.session" , "Host" : "localhost" } } } } }

尽管在使用BEFORE_ON_PRIMARY_FAILOVER一致性级别时，在未应用完成所有的积压事务之前，所有的写操作都会进入待处理状态，但并不是所有的读操作都被阻塞，对于一些不修改数据的查询是允许执行的（例如：对于一些状态表的查看等，这对一些问题排查和性能监控非常有用）。

事务不能永远处于待处理状态(on-hold)，如果处于该状态的时间超过系统变量wait_timeout设置的值，则会返回ER_GR_HOLD_WAIT_TIMEOUT错误信息。

15 MGR分布式恢复

每当一个Server新加入或重新加入一个复制组时，对于新加入的Server，它必须要追平组中的最新数据，对于重新加入的Server，它必须要追平它脱离组之后的最新数据。这个追平最新数据的过程称为分布式恢复。
申请加入组的Server首先检查其组复制通道group_replication_applier对应的中继日志，查看它已经从组中接收到了但尚未应用的任何事务。如果是重新加入组的Server，那么它可能在脱离组时存在着未应用完成的事务，在这种情况下，它将第一步应用这些事务，如果是新加入组的Server则不存在这种情况，所以在这一步没有任何东西需要应用。
之后，申请加组的Server会与组中的现有成员建立连接进行状态传输。申请加入组的Server会从组中现有成员中（提供状态传输的组成员称为donor节点，接收状态传输的Server称为joiner节点）传输在其加入组之前或者在其脱离组之后组中的所有事务数据。然后，申请加入组的Server将应用在状态传输过程中组内新事务写入的数据。当这个过程完成时，就表示申请加入组的Server已经赶上了组中其余成员中的数据，此时，新加入组的Server就会转换为ONLINE状态，并开始正常地参与组中的各项工作。
在分布式恢复期间，组复制使用如下方法的组合进行状态传输：


**4.3.1.2. 克隆触发阈值**
当组成员设置了支持克隆时，会通过系统变量group_replication_clone_threshold指定的阈值（该阈值表示若干个事务）来判断在分布式恢复过程中是否需要使用远程克隆操作。如果donor节点的事务与joiner节点之间的事务差距大于此数字（组复制会根据组中的现有成员的系统变量gtid_execution中的GTID SET计算出它们之间的事务数量的差距是否超出了阈值），则在技术上可行的情况下，将使用远程克隆操作将donor节点的状态传输到joiner节点，无需事先手动将组的数据传输到joiner节点主机中，还可以让延迟非常大的组成员能够快速追赶上来。
系统变量group_replication_clone_threshold的默认设置非常高（GTID中事务的最大允许序列号），因此只要可以从二进制日志传输状态，组复制就不会使用克隆功能传输状态。要想让组复制在何时的时候使用远程克隆操作进行状态传输，可以根据具体情况对系统变量group_replication_clone_threshold设置合适的值。但是要注意，在组中有成员正在使用远程克隆操作进行状态传输的过程中，不要对系统变量group_replication_clone_threshold设置过低的阈值。因为，如果在进行远程克隆操作时组中存在着大量超过阈值的新的事务请求，则joiner节点在重新启动数据库进程后将再次触发远程克隆操作，并无限循环远程克隆操作。要避免这种情况，需要将该阈值设置为高于组内的最高并发事务请求数。
当无法从donor节点的二进制日志进行状态传输时，组复制会尝试执行远程克隆操作。此时会忽略系统变量group_replication_clone_threshold的阈值设置，例如，joiner节点所需的事务在任何现有组成员的二进制日志中都不可用（找不到）。组复制基于现有组成员的系统变量gtid_purged的GTID SET来进行比对。当任何现有组成员的二进制日志文件中都没有joiner节点所需的事务时，组复制会尝试执行远程克隆操作进行状态传输，且这种情况下无法通过系统变量group_replication_clone_threshold的阈值设置来停用克隆操作，因为在这种情况下，克隆是将组的状态传输到joiner节点的一个可行的替代方法。
**4.3.1.3. 克隆操作**
当为组成员以及待加入组的成员都设置好了克隆功能时，组复制会接管远程克隆操作。远程克隆操作过程可能需要一些时间才能完成，具体取决于数据的大小。有关克隆操作过程的监控信息，详情可留意后续克隆插件系列文章。

performance_schema.clone_progress表中记录了整个克隆操作的每一个阶段及其对应的阶段信息，每一个阶段会生成一行记录（注意，该表中只记录一次克隆操作的过程信息，下一次执行克隆操作时，上一次的信息会被覆盖）

admin@localhost : performance_schema:37: > select * from clone_progress;
+------+-----------+-----------+----------------------------+----------------------------+---------+------------+------------+------------+------------+---------------+
| ID | STAGE | STATE | BEGIN_TIME | END_TIME | THREADS | ESTIMATE | DATA | NETWORK | DATA_SPEED | NETWORK_SPEED |
+------+-----------+-----------+----------------------------+----------------------------+---------+------------+------------+------------+------------+---------------+
| 1 | DROP DATA | Completed | 2019-10-08 16:46:58.757964 | 2019-10-08 16:46:59.128436 | 1 | 0 | 0 | 0 | 0 | 0 |
| 1 | FILE COPY | Completed | 2019-10-08 16:46:59.128766 | 2019-10-08 16:47:16.857536 | 8 | 8429731840 | 8429731840 | 8430190882 | 0 | 0 |
| 1 | PAGE COPY | Completed | 2019-10-08 16:47:16.857737 | 2019-10-08 16:47:17.159531 | 8 | 0 | 0 | 785 | 0 | 0 |
| 1 | REDO COPY | Completed | 2019-10-08 16:47:17.159748 | 2019-10-08 16:47:17.460516 | 8 | 2560 | 2560 | 3717 | 0 | 0 |
| 1 | FILE SYNC | Completed | 2019-10-08 16:47:17.460788 | 2019-10-08 16:47:20.926184 | 8 | 0 | 0 | 0 | 0 | 0 |
| 1 | RESTART | Completed | 2019-10-08 16:47:20.926184 | 2019-10-08 16:47:28.623732 | 0 | 0 | 0 | 0 | 0 | 0 |
| 1 | RECOVERY | Completed | 2019-10-08 16:47:28.623732 | 2019-10-08 16:47:34.898453 | 0 | 0 | 0 | 0 | 0 | 0 |
+------+-----------+-----------+----------------------------+----------------------------+---------+------------+------------+------------+------------+---------------+
7 rows in set (0.00 sec)

performance_schema.clone_status表中记录了克隆操作的一些元数据信息，例如，donor节点地址信息，对应数据的二进制日志位置信息和GTID信息（注意，该表中只记录一次克隆操作的信息，下一次执行克隆操作时，该表中的信息会被覆盖）

admin@localhost : performance_schema:38: > select * from clone_status\G
1. row
ID: 1
PID: 0
STATE: Completed
BEGIN_TIME: 2019-10-08 16:46:58.758
END_TIME: 2019-10-08 16:47:34.898
SOURCE: 10.10.30.162:3306
DESTINATION: LOCAL INSTANCE
ERROR_NO: 0
ERROR_MESSAGE:
BINLOG_FILE: mysql-bin.000022
BINLOG_POSITION: 222104704
GTID_EXECUTED: 320675e6-de7b-11e9-b3a9-5254002a54f2:1-4,
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-2771494
1 row in set (0.01 sec)


注意：当完成状态传输后，组复制将重新启动joiner节点的数据库进程以完成该过程。如果在joiner节点上设置了group_replication_start_on_boot=OFF，则在数据库进程重新启动完成之后必须再次手动执行START GROUP_REPLICATION语句启动组复制。如果在配置文件中设置了group_replication_start_on_boot=ON和启动组复制所需的其他设置，或者使用了SET PERSIST语句将group_replication_start_on_boot=ON和启动组复制所需的其他设置进行了持久化，则在数据库进程重启之后不需要进行干预，组复制会继续自动执行成员加入组并使其达到ONLINE状态的流程。

远程克隆操作会将donor节点的datadir下的各种数据文件克隆到joiner节点中（表中可能包含了一些配置信息及其用户数据等）。但保存在配置文件（如组复制本地地址配置等）中的组复制成员设置不会被克隆，也不会在joiner节点上做任何更改。即，组复制相关的配置需要自行配置好，不能跟组中的现有成员冲突，远程克隆操作只负责克隆数据文件，不会克隆配置信息（当然，如果某些配置信息保存在表里，对于克隆操作来说，也会被当做数据进行克隆）。
donor节点中用于组复制专用通道group_replication_recovery的用户凭证（复制用户和密码），在克隆操作完成之后，会被新成员使用，所以，该用户和密码及其权限必须在新成员中也有效。因此，所有组成员才能够使用相同的复制用户和密码通过远程克隆操作接收状态传输进行分布式恢复。但是，组复制会保留与使用SSL相关的组复制通道设置，这些设置对单个成员来说可以是惟一的（即，每个组成员使用不同的复制用户和密码）。如果使用了PRIVILEGE_CHECKS_USER帐户来帮助保护复制应用线程（从MySQL 8.0.18开始，可以创建一个具有特定权限的用户账号，然后将其指定为PRIVILEGE_CHECKS_USER帐户，这样可以防止将未经授权或意外将具有特权的账号用于组复制通道），则在克隆操作完成之后新加入成员不会使用该用户帐户作为组复制通道的用户。此时必须为组复制通道手工指定合适的复制用户。

关于PRIVILEGE_CHECKS_USER帐户的详细信息，详见链接：

https://dev.mysql.com/doc/refman/8.0/en/replication-privilege-checks.html

**4.3.2. 配置分布式恢复**
分布式恢复的复制用户
* 分布式恢复需要具有正确权限（replication slave权限）的复制用户，以便组复制可以在成员之间建立直接相连的复制通道。如果该复制用户还同充当远程克隆操作中的克隆用户，则在donor节点中该复制用户还必须具有远程克隆相关的正确权限（BACKUP_ADMIN权限）。有关设置此复制用户的说明，请参见 2.1.3节“用户凭证”。
手动状态传输
* 基于二进制日志进行状态传输是组复制执行分布式恢复的基本机制，如果复制组中的donor节点和joiner节点未设置克隆功能支持，那么基于二进制日志进行状态传输就是惟一可用的分布式恢复方法。由于基础二进制日志的状态传输是基于典型的异步复制的数据同步类型，因此，如果joiner节点中没有任何组的数据、或者与组中的数据差距太大（例如，数据取自很久之前的备份），则整个分布式恢复的过程可能需要很长时间，如果在组中任何成员中都找不到joiner节点所需的数据，则会导致joiner节点加入组失败。因此，在这种情况下，建议先手动从组中获取一份最新的数据快照，使用该快照数据先恢复到joiner节点中，基于该快照数据加入组可以最小化分布式恢复所花费的时间，并减少对donor节点的影响。
连接尝试次数
* 对于基于二进制日志的状态传输，组复制限制了joiner节点从可用的donor节点池（即，可作为donor节点的组成员列表）尝试获取donor节点的尝试次数。如果达到重试限制次数之后仍然没有成功与donor节点建立连接，则分布式恢复过程将报错终止。注意，该限制次数指的joiner节点可以重试连接donor节点的总次数。例如，如果组中有2个组成员可作为donor候选节点，且重试连接次数限制为4，则每个donor候选节点都可以被重试连接2次。
* 默认的连接重试限制是10。可以使用系统变量group_replication_recovery_retry_count进行设置，如下：

下面的语句将尝试重新连接donor节点的最大次数限制为5:

mysql> SET GLOBAL group_replication_recovery_retry_count= 5;

注意：对于远程克隆操作，此重试次数不适用。在开始尝试基于二进制日志的状态传输之前，组复制仅对每一个合适的donor候选节点做一次克隆操作连接尝试


连接尝试的时间间隔

* 对于基于二进制日志的状态传输，系统变量group_replication_recovery_reconnect_interval定义了分布式恢复过程中重新连接donor节点的时间间隔。注意，如果最大重试次数设置为4，且组内有2个donor候选节点，则，会先连续2次分别尝试连接这两个donor候选节点（不会使用系统变量group_replication_recovery_reconnect_interval设置的间隔时间，因为这两个donor候选节点之间并没有相互的强关联影响因素，所以没有必要在占满这两个donor候选节点之前就执行重试等待）。一旦joiner节点尝试与所有的donor候选节点都执行了连接尝试之后（假设这里2个donor候选节点都在同时做连接尝试），那么，比起donor候选节点数量来讲，多余的重试连接次数（4-2=2次）就会按照系统变量group_replication_recovery_reconnect_interval配置的时间间隔（单位秒）对分布式恢复程序进行休眠。

* 默认的连接重试间隔是60秒，可以使用如下语句进行动态修改。

以下语句将分布式恢复中donor节点的连接重试间隔设置为120秒

mysql> SET GLOBAL group_replication_recovery_reconnect_interval= 120;

对于远程克隆操作，此间隔时间不适用。开始尝试基于二进制日志的状态传输之前，组复制仅对每一个合适的donor候选节点做一次克隆操作连接尝试



标记joiner节点在线

* 当分布式恢复成功完成了从donor节点到joiner节点之间的状态传输时，joiner节点在组中就可以被标记为online状态并准备参与到组内的各项工作中。默认情况下，此操作是在joiner节点接收并应用完成了所有缺失的事务之后执行的。但，可以允许joiner节点在接收并验证完成所有缺失事务之后，应用它们之前，将joiner节点标记为online状态。可以在joiner节点中将系统变量group_replication_recovery_complete_at设置为TRANSACTIONS_CERTIFIED值来实现。

分布式恢复使用SSL身份验证

* 您可以选择将SSL用于组成员之间的分布式恢复连接。用于分布式恢复的SSL与用于普通组通信的SSL是分开配置的，后者由MySQL Server的SSL相关的系统变量和系统变量group_replication_ssl_mode共同设置。对于分布式恢复连接的SSL配置，使用专用的分布式恢复相关的SSL系统变量来配置相关的证书和密码。

* 默认情况下，分布式恢复连接不使用SSL。要启用此功能，可以通过系统变量group_replication_recovery_use_ssl=ON进行设置，并配置组复制的分布式恢复相关的SSL系统变量，并创建一个启用了SSL的专用用户，详情可参考"5.2. 组复制安全套接字层(SSL)支持"。

* 当为分布式恢复配置使用SSL时，组复制会将此设置应用于远程克隆操作，以及基于二进制日志的状态传输。组复制会自动配置克隆操作相关的SSL系统变量(即，clone_ssl_ca、clone_ssl_cert、clone_ssl_key等系统变量)，以匹配相应的分布式恢复系统变量值（即，group_replication_recovery_ssl_ca、group_replication_recovery_ssl_cert和group_replication_recovery_ssl_key等系统变量）。

* 如果没有为分布式恢复配置使用SSL（即，group_replication_recovery_use_ssl=OFF），且组复制的复制用户是使用的caching_sha2_password插件（caching_sha2_password是MySQL 8.0中默认使用的身份认证插件）或sha256_password插件进行身份认证的，则会将RSA密钥对用于密码交换。在这种情况下，需要使用系统变量group_replication_recovery_public_key_path来指定RSA公钥文件，或使用系统变量group_replication_recovery_get_public_key设置秘钥文件从主要节点中获取，否则，分布式恢复操作将发生报错终止。

分布式恢复压缩

* 从MySQL 8.0.18开始，基于二进制日志的状态传输支持压缩功能。当网络带宽有限，且发送方（donor节点）需要向接收方（joiner节点）传输大量事务时，压缩功能有利于提高分布式恢复的效率。通过系统变量group_replication_recovery_compression_algorithm配置允许的压缩算法，通过系统变量group_replication_recovery_zstd_compression_level设置zstd压缩级别。

* 注意，这些压缩设置不适用于远程克隆操作。当使用远程克隆操作进行分布式恢复时，如果需要使用压缩功能，可以使用克隆插件的系统变量clone_enable_compression进行设置。

***4.3.3. 分布式恢复的容错能力
***
组复制有许多内置的容错措施，以确保在分布式恢复过程中出现任何问题时能够进行容错。
分布式恢复的donor节点是从组的当前视图中的在线成员列表中随机选择的一个合适的组成员。随机选择donor节点就意味着当多个Server同时申请加入组时，组中的同一个成员很可能不会被同时多次选中。从MySQL 8.0.17开始，对于基于二进制日志的状态传输，同时申请加入组的所有Server只选择同一个donor节点来提供状态传输，这个donor节点运行的MySQL Server的补丁版本要求比申joiner节点的Server版本低或相同（可以将donor节点类比为主库，joiner节点类比为从库，为了保证兼容性，主库的版本不能高于从库的版本）。但对于更早的版本，组中所有的在线成员都可以成为donor节点。对于基于远程克隆操作的状态传输，joiner节点只选择与自身运行相同Server版本的组成员作为donor节点（因为克隆操作是拷贝数据文件，不同版本之间可能存在着一些文件格式兼容性问题，要处理这些问题可能需要做升级与降级处理，而克隆不做这些处理）。注意，joiner节点在克隆操作结束之后重新启动数据库进程时，它将重新选择一个新的donor节点建立连接并执行基于二进制日志的状态传输，这个新的donor节点可能与用于远程克隆操作的原始donor节点不是同一个组成员。
在以下情况下，组复制检测到分布式恢复过程中的错误时，会自动切换到一个新的donor节点，并重试状态传输操作：
* 连接错误：在连接到候选donor节点时存在身份验证问题或其他问题。
* 复制错误：基于二进制日志的状态传输的复制线程（接收线程或应用线程）之一出现错误。因为这种状态传输方法使用了现有的MySQL主从复制基础架构，所以一些临时错误可能会在接收线程或应用程序线程中引起错误。
* 远程克隆操作错误：远程克隆操作失败或在执行完成之前意外停止。
* donor节点脱离组：在执行状态传输过程中，donor节点意外脱离组，或者在donor节点上停止组复制。
在上述情况下，donor节点发生错误之后，joiner节点将尝试重新选择donor节点。通过选择新的donor节点就可能避免之前joiner节点中发生的错误，从而保证能够继续执行分布式恢复。如果安装了克隆插件，则组复制在这种情况下将首先尝试使用支持克隆功能的合适的在线donor候选节点执行远程克隆操作。如果所有支持克隆的候选donor节点尝试远程克隆都失败了，则组复制会接着继续依次尝试所有合适的候选donor节点进行基于二进制日志的状态传输（如果可能的话）。
* 注意：对于远程克隆操作，在开始执从donor节点接收数据之前，会先删除joiner节点上的原始数据文件。所以，一旦远程克隆操作启动之后但未执行完成就被终止，则joiner节点上可能只剩下部分原始数据文件，或者原始数据文件完全被清空。此时，可以通过重试克隆操作来修复这种情况（组复制会自动执行该修复操作）。
在以下情况下，无法完成分布式恢复过程，joiner节点会执行退出组的操作：
* 事务被清理：joiner节点所需的事务，在组中现有的任何在线成员的二进制日志中都无法找到，且也无法执行远程克隆操作（例如，因为克隆插件没有安装,或者所有支持克隆操作的所有候选donor节点尝试连接都失败了）。此时，joiner节点无法获取组中的数据，无法加入组。
* 事务冲突：joiner节点已经包含了组中不存在的一些事务。如果执行远程克隆操作，这些组中不存在的事务将被删除（对于joiner节点来说，意味着这些事务数据丢失），因为joiner节点上的数据目录将被删除。如果使用基于二进制日志的状态传输，则joiner节点中多余的事务可能会与组内的事务发生冲突，所以，joiner节点可能无法加入组。
* 已达到连接重试限制：joiner节点已耗尽了重试连接donor节点的限制次数。可以使用系统变量group_replication_recovery_retry_count来指定限制次数，关于该系统变量的配置，详情可参见"4.3.2. 配置分布式恢复"。
* 没有更多的donor节点：joiner节点向每个在线的且支持克隆操作的组成员之间尝试执行远程克隆操作的状态传输都失败之后，再向每个在线的且合适的组成员尝试执行基于二进制日志的状态传输也都失败时，joiner节点无法加入组。
* * joiner节点脱离组：在执行状态传输过程中，joiner节点意外脱离组，或者在joiner节点上停止组复制，则joiner节点加入组过程终止。
* 在上述几种情况中，除了最后一种之外，其他几种joiner节点退出组时，它将继续执行系统变量group_replication_exit_state_action指定的操作。
* **4.3.4. 分布式恢复的工作原理**
* 当组复制的分布式恢复过程基于二进制日志执行状态传输时，为了使joiner节点与donor节点在特定时间点上保持同步，joiner节点和donor节点使用了GTID机制。但是，GTID机制只提供了一种识别joiner节点缺失了哪些事务的方法。它并不能标记joiner节点必须要追赶上组中某个特定的时间点之后才能算作成功加入组（即，joiner节点在不断执行状态传输的过程中，通过GTID是无法知道在什么时间点算成功加入了组），它也不能传递认证信息（这是二进制日志中的View_change_log_event事件的工作，该事件用于标记二进制日志流中的视图变更，且还包含附加的元数据信息，为joiner节点提供缺失的事务数据与证书相关的数据）。下面将配合一些示意图来详细介绍基于二进制日志的状态传输的步骤。
视图和视图变更相关的概念。
* view：view（视图）对应于组中活跃成员的当前配置，换句话说，它是在特定的时间点所有组成员达成一致状态的配置。
* view changes：View Changes 指的是引起组配置发生变化的事件，当视图发生变更时（例如，有Server新加入组或有组成员脱离组时），视图将发生变更。任何组成员资格的变更都会导致在相同的逻辑时间点上向所有组成员发送视图变更消息。
* View Identifier：View Identifier（视图标识符）可以唯一标识一个视图。它是在视图发生变更时生成的。当发生View Changes时，就会生成这样一个唯一标识来表示这个新的View。
* 在组通信层，View changes 产生的view ids作为joiner节点与donor节点之间同步数据的临界点。View change 事件对应到binary log里面是一个新binary log event的实现，即“View_change_log_event”（视图变更日志事件），在这个事件里面携带了view id。它用于记录视图标识符，以便能够划分组成员资格发生变更之前和之后传输的事务边界。
* 视图标识符本身由两部分构成：随机生成的整数数字部分和单调递增的整数数字（例如：view_id=15692965051216743:3）。随机生成的部分是在创建组时生成的，在组中至少有一个成员开始，该随机部分无论组中后续有多少个成员加入或脱离组（只要至少有一个成员）都会保持不变。当每次发生视图变更时，单调递增的整数部分就会递增。通过使用这两个不同的部分，视图标识符就可以唯一标识由于Server加入组或组成员脱离组而导致的组成员资格变更，还可以标记在完全关闭组时所有成员退出组的情况，这将确保二进制日志中的数据标记保持惟一，以便在完全关闭组后不会重用相同的标识符，以防止将来的分布式恢复出现问题。
1） 从一个稳定的组开始。
* 所有成员都在线并正在持续处理来自组中的事务。有些成员可能存在复制延迟，但最终它们会达到一致的状态。组充当一个分布式的数据库副本。下图表示一个稳定的组。
![](http://www.icode9.com/i/li/?n=4&i=images/blog/202103/01/b9e19d575d30cb3632b840b3f6121cb4.png?,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)
2）新Server申请加入组，视图发生变更。
* 每当有新Server申请加入组并因此执行视图变更时，每个在线的成员都会将视图变更日志事件排队等待执行。之所以要排队，因为在视图变更之前，每个成员中可能还有一些属于旧视图的事务还在队列中未应用完成，将视图变更日志时间排在这些属于旧视图的事务之后可以确保正确标记什么时候发生了视图变更。
* 同时，新加入组的Server从视图声明的在线成员列表中选择一个合适的donor节点。如下图所示，Server S4申请加入组时生成视图4（VC4），在线的所有组成员将视图变更日志事件写入二进制日志中（如果有成员存在应用延迟，则会先将View_change_log_event事件缓存在队列里排队，在该事件之前的事务属于旧视图，在该事件之后的事务属于新视图）。
![](http://www.icode9.com/i/li/?n=4&i=images/blog/202103/01/4f24e1571744dd5369bb5398f8cd8292.png?,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)
3）使用状态传输追赶组中的最新数据。
* 如果组中的成员和joiner节点都设置好了克隆插件（详情可参考 "4.3.1. 克隆用于分布式恢复"），如果joiner节点与组之间的事务差异量超过了系统变量group_replication_clone_threshold设置的阈值，组复制就会通过远程克隆操作执行分布式恢复；如果joiner节点在组中的任何组成员的二进制日志文件中都找不到所需的事务，组复制也会通过远程克隆操作执行分布式恢复。在远程克隆操作期间，joiner节点上的现有数据将会被全部删除，并替换为donor节点的数据副本。当远程克隆操作完成且joiner节点完成数据库实例的重启操作之后，将从donor节点执行基于二进制日志的状态传输，以获取在远程克隆操作期间该组中新应用的事务；如果joiner节点与组之间的事务差异不大，或者没有安装克隆插件，则组复制直接从donor节点执行基于二进制日志进行状态传输。
* 对于从donor节点执行基于二进制日志的状态传输，会在joiner节点（这里为Server S4）和donor节点之间建立一个异步复制机制的专用通道，然后开始状态传输。与donor节点的这种交互将一直持续，直到Server S4中的applier线程处理视图变更日志事件（这里为VC4）为止，该事件对应于Server S4进入该组时触发的视图变更。这个时候，组内的所有成员读取到VC4时，通过VC4都能够清楚地知道在这之前的事务属于old view，在这之后的事务属于new view。如下图。
![](http://www.icode9.com/i/li/?n=4&i=images/blog/202103/01/7616c0d2f50dea85e32354d9135557c1.png?,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)
由于视图标识符（VC4）在同一逻辑时间会传输给组中的所有成员，所以Server S4知道应该在哪个视图标识符（VC4）处停止复制（注意，这里说的停止复制指的是停止在Server S4与donor节点之间建立的专用的异步复制通道）。这避免了复杂的GTID SET计算，因为视图标识符（VC4）清楚地标记（界定）了哪些数据属于哪个组视图。
4）使用缓存来追赶组的最新数据。
* 当Server S4从donor节点复制数据的过程中，它也同时缓存来自组的新执行的事务。最终，当Server S4停止与donor节点之间的异步复制连接之后，它将应用那些被缓存的事务（这是实现Server S4加入组的过程中，在该阶段不阻塞写业务的关键特性）。如下图。
![](http://www.icode9.com/i/li/?n=4&i=images/blog/202103/01/729cfc4a3a2207227682e1b56bab22dc.png?,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)
5）追赶数据完成
* 当joiner节点（Server S4）使用预期的视图标识符识别了视图变更日志事件（VC4）时，它与donor节点之间的连接将终止，并开始应用自身缓存中的增量事务。VC4 除了在二进制日志中充当新旧视图的分隔标记之外，它还扮演另一个角色。当Server S4成员进入组时，它传递所有服务器感知到的认证信息，即，就是最后一次视图变更。如果没有VC4，Server S4将没有所需的信息来验证（检测冲突）后续的事务。
* 追赶的持续时间是不确定的，因为它取决于工作负载和整个过程中组内新进入的事务速率。因为，这个过程是完全在线的，Server S4在追赶组数据的过程中不会阻塞组中的任何其他成员写入新的数据。因此，当Server S4在执行此阶段过程中，后续新写入组的事务可能堆积，堆积的事务多少取决于它的工作负载。
* 当Server S4应用完成缓存中的事务（缓存队列为空）且其存储的数据与组中其他成员达到一致时，其公共状态将更改为ONLINE。如下图 

![](http://www.icode9.com/i/li/?n=4&i=images/blog/202103/01/aee99044bc0eb6ac3ff299e57bf6c054.png?,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)

标签：02,事务,组中,group,replication,成员,MGR,MYSQL,节点
来源： https://blog.51cto.com/15080028/2643025