组复制常规操作-分布式恢复 | 全方位认识 MySQL 8( 三 ) _分布式事务

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

文章插图

# 下面的语句将尝试重新连接donor节点的最大次数限制为5:mysql> SET GLOBAL group_replication_recovery_retry_count= 5;# 注意：对于远程克隆操作，此重试次数不适用 。在开始尝试基于二进制日志的状态传输之前，组复制仅对每一个合适的donor候选节点做一次克隆操作连接尝试

连接尝试的时间间隔

# 以下语句将分布式恢复中donor节点的连接重试间隔设置为120秒mysql> SET GLOBAL group_replication_recovery_reconnect_interval= 120;# 对于远程克隆操作，此间隔时间不适用 。开始尝试基于二进制日志的状态传输之前，组复制仅对每一个合适的donor候选节点做一次克隆操作连接尝试

标记节点在线
分布式恢复使用SSL身份验证
分布式恢复压缩
4.3.3. 分布式恢复的容错能力
组复制有许多内置的容错措施，以确保在分布式恢复过程中出现任何问题时能够进行容错。
分布式恢复的donor节点是从组的当前视图中的在线成员列表中随机选择的一个合适的组成员。随机选择donor节点就意味着当多个同时申请加入组时，组中的同一个成员很可能不会被同时多次选中。从MySQL 8.0.17开始，对于基于二进制日志的状态传输，同时申请加入组的所有只选择同一个donor节点来提供状态传输，这个donor节点运行的MySQL 的补丁版本要求比申请节点的版本低或相同（可以将donor节点类比为主库，节点类比为从库，为了保证兼容性，主库的版本不能高于从库的版本）。但对于更早的版本，组中所有的在线成员都可以成为donor节点。对于基于远程克隆操作的状态传输，节点只选择与自身运行相同版本的组成员作为donor节点（因为克隆操作是拷贝数据文件，不同版本之间可能存在着一些文件格式兼容性问题，要处理这些问题可能需要做升级与降级处理，而克隆不做这些处理）。注意，节点在克隆操作结束之后重新启动数据库进程时，它将重新选择一个新的donor节点建立连接并执行基于二进制日志的状态传输，这个新的donor节点可能与用于远程克隆操作的原始donor节点不是同一个组成员。