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

在以下情况下，组复制检测到分布式恢复过程中的错误时，会自动切换到一个新的donor节点，并重试状态传输操作：
在上述情况下，donor节点发生错误之后，节点将尝试重新选择donor节点。通过选择新的donor节点就可能避免之前节点中发生的错误，从而保证能够继续执行分布式恢复。如果安装了克隆插件，则组复制在这种情况下将首先尝试使用支持克隆功能的合适的在线donor候选节点执行远程克隆操作。如果所有支持克隆的候选donor节点尝试远程克隆都失败了，则组复制会接着继续依次尝试所有合适的候选donor节点进行基于二进制日志的状态传输（如果可能的话）。
在以下情况下，无法完成分布式恢复过程，节点会执行退出组的操作：
在上述几种情况中，除了最后一种之外，其他几种节点退出组时，它将继续执行系统变量指定的操作。
4.3.4. 分布式恢复的工作原理
当组复制的分布式恢复过程基于二进制日志执行状态传输时，为了使节点与donor节点在特定时间点上保持同步，节点和donor节点使用了GTID机制。但是，GTID机制只提供了一种识别节点缺失了哪些事务的方法。它并不能标记节点必须要追赶上组中某个特定的时间点之后才能算作成功加入组（即，节点在不断执行状态传输的过程中，通过GTID是无法知道在什么时间点算成功加入了组），它也不能传递认证信息（这是二进制日志中的t事件的工作，该事件用于标记二进制日志流中的视图变更，且还包含附加的元数据信息，为节点提供缺失的事务数据与证书相关的数据）。下面将配合一些示意图来详细介绍基于二进制日志的状态传输的步骤。
视图和视图变更相关的概念。
1）从一个稳定的组开始。

文章插图
2）新申请加入组，视图发生变更。

文章插图
3）使用状态传输追赶组中的最新数据。

文章插图
由于视图标识符（VC4）在同一逻辑时间会传输给组中的所有成员，所以 S4知道应该在哪个视图标识符（VC4）处停止复制（注意，这里说的停止复制指的是停止在 S4与donor节点之间建立的专用的异步复制通道）。这避免了复杂的GTID SET计算，因为视图标识符（VC4）清楚地标记（界定）了哪些数据属于哪个组视图。
4）使用缓存来追赶组的最新数据。

文章插图
5）追赶数据完成

文章插图
| 作者简介
罗小波·数据库技术专家
《千金良方——MySQL性能优化金字塔法则》作者之一。熟悉MySQL体系结构，擅长数据库的整体调优，喜好专研开源技术，并热衷于开源技术的推广，在线上线下做过多次公开的数据库专题分享，发表过近100篇数据库相关的研究文章。