Documentation Home
MySQL 8.3 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 40.8Mb
PDF (A4) - 40.9Mb
Man Pages (TGZ) - 294.0Kb
Man Pages (Zip) - 409.0Kb
Info (Gzip) - 4.0Mb
Info (Zip) - 4.0Mb
Excerpts from this Manual

MySQL 8.3 Reference Manual  /  ...  /  How Distributed Recovery Works

20.5.4.5 分布式恢复如何工作

当组复制的分布式恢复过程从二进制日志中执行状态传输时,加入成员和捐赠者使用 GTID(见 第 19.1.3 节,“使用全局事务标识符的复制”)。然而,GTID 只提供了缺少事务的信息,但不提供特定时间点的标记,也不提供认证信息。这是二进制日志视图标记的工作,它们在二进制日志流中标记视图更改,并包含额外的元数据信息,为加入成员提供缺少的认证相关数据。

本主题解释视图更改和视图更改标识符的角色,以及从二进制日志执行状态传输的步骤。

视图和视图更改

一个 视图 对应于当前配置中的活动成员组,在特定时间点上在线和正确地工作。

一个 视图更改 发生在组配置发生变化时,例如成员加入或离开。任何组成员变化都会导致视图更改,并在同一逻辑时间点上通知所有成员。

一个 视图标识符 唯一标识一个视图。它是在视图更改时生成的。

在组通信层面上,视图更改及其关联的视图标识符标记了数据交换的边界,在成员加入之前和之后。这个概念通过二进制日志事件实现:“视图更改日志事件”(VCLE)。视图标识符记录下来,以区分成员加入之前和之后的交易。

视图标识符本身由两个部分组成:一个随机生成的部分和一个单调递增的整数。随机生成的部分是在组创建时生成的,并在至少有一个成员在组中时保持不变。整数每次视图更改时递增。使用这两个不同的部分使视图标识符能够标识组成员加入或离开引起的增量更改,并且能够标识组完全关闭的情况,在这种情况下,组中的所有信息都将丢失。随机生成部分视图标识符的随机部分时,确保二进制日志中的数据标记保持唯一,并且在组完全关闭后,不会重用相同的标识符,这将在未来引起分布式恢复问题。

开始:稳定组

所有服务器在线并处理来自组的传入事务。一些服务器可能落后于事务复制,但最终它们会收敛。组作为一个分布式和复制的数据库工作。

图 20.8 稳定组

Servers S1, S2, and S3 are members of the group. The most recent item in all of their binary logs is transaction T20.

视图更改:成员加入

每当新成员加入组时,所有在线服务器都会将视图更改日志事件排队执行。这是因为在视图更改之前,服务器上可能有几个事务排队等待应用,这些事务属于旧视图。排队视图更改事件保证了正确的标记时刻。

同时,加入成员从在线服务器列表中选择合适的捐赠者,通过成员服务的视图抽象。成员加入视图 4,并且在线成员将视图更改事件写入二进制日志。

图 20.9 成员加入

Server S4 joins the group and looks for a donor. Servers S1, S2, and S3 each queue the view change entry VC4 for their binary logs. Meanwhile, server S1 is receiving new transaction T21.

状态传输:追赶

如果组成员和加入成员都设置了克隆插件(见第 20.5.4.2 节,“分布式恢复中的克隆”),并且加入成员和组之间的交易差异超过了远程克隆操作的阈值(group_replication_clone_threshold),则组复制开始分布式恢复,使用远程克隆操作。如果加入成员的二进制日志文件中不再存在所需交易,或者克隆插件未安装,组复制将直接进行状态传输。

对于状态传输,加入成员与捐赠者之间建立连接,状态传输开始。这种交互将继续,直到加入成员的应用程序线程处理了对应于加入组时触发的视图更改日志事件。当加入成员从捐赠者复制时,它会复制到与当前视图标识符匹配的标记。

图 20.10 状态传输:赶上

Server S4 has chosen server S2 as the donor. State transfer is executed from server S2 to server S4 until the view change entry VC4 is reached (view_id = VC4). Server S4 uses a temporary applier buffer for state transfer, and its binary log is currently empty.

由于视图标识符在组中的所有成员中同时传输,因此加入成员知道它应该停止复制的位置。这避免了复杂的 GTID 集计算,因为视图标识符清楚地标记了每个组视图中的数据。

当加入成员从捐赠者复制时,它还会缓存来自组的传入交易。最终,它停止从捐赠者复制,并切换到应用缓存的交易。

图 20.11 队列交易

State transfer is complete. Server S4 has applied the transactions up to T20 and written them to its binary log. Server S4 has cached transaction T21, which arrived after the view change, in a temporary applier buffer while recovering.

完成:赶上

当加入成员识别出具有预期视图标识符的视图更改日志事件时,它将终止与捐赠者的连接,并开始应用缓存的交易。视图更改日志事件不仅是二进制日志中的标记,标记视图更改,还传递了加入成员加入组时的认证信息,即最后的视图更改。否则,加入成员将无法检测后续交易的冲突。

赶上的持续时间不可预测,因为它取决于工作负载和组中的传入交易速率。这个过程是在线的,加入成员不会阻塞组中的其他服务器。因此,加入成员在达到这个阶段时落后的交易数量可能会增加或减少,取决于工作负载。

当加入成员的队列交易数量为零,并且其存储的数据与其他成员相同时,其公共状态将更改为在线。

图 20.12 实例在线

Server S4 is now an online member of the group. It has applied cached transaction T21, so its binary log shows the same items as the binary logs of the other group members, and it no longer needs the temporary applier buffer. New incoming transaction T22 is now received and applied by all group members.