17.9.5.3 查看更改

本部分说明了控制如何将视图更改标识符合并到二进制日志事件中以及如何将其写入日志的过程,执行以下步骤:

开始:稳定小组

所有服务器均处于联机状态,并且正在处理来自该组的传入事务。在复制的事务方面,某些服务器可能会有些落后,但最终它们会融合在一起。该组充当一个分布式和复制数据库。

图 17.10 稳定组

服务器 S1,S2 和 S3 是该组的成员。他们所有二进制日志中的最新项目是事务 T20.

视图更改:成员加入

每当新成员加入该组并因此执行视图更改时,每个联机服务器都会将视图更改日志事件排队 await 执行。之所以要排队,是因为在更改视图之前,可以在要应用的服务器上将多个事务排队,因此,这些事务属于旧视图。在它们之后对视图更改事件进行排队可确保正确标记何时发生。

同时,加入该组的服务器通过成员资格服务通过视图抽象从联机服务器列 table 中选择捐赠者。成员加入视图 4,在线成员将视图更改事件写入二进制日志。

图 17.11 会员加入

服务器 S4 加入该组并寻找捐助者。服务器 S1,S2 和 S3 各自将视图更改条目 VC4 排队为其二进制日志。同时,服务器 S1 正在接收新的事务 T21.

状态转移:追赶

一旦加入该组的服务器选择了该组中的哪台服务器作为施主,则将在两者之间构建新的异步复制连接,并开始状态转移(阶段 1)。与捐助者的这种交互 continue 进行,直到加入该组的应用程序线程的服务器处理与加入该组的服务器进入该组时触发的视图更改相对应的视图更改日志事件。换句话说,加入该组的服务器从供体复制,直到它到达具有与其已经在其中的视图标记匹配的视图标识符的标记。

图 17.12 状态转移:追赶

服务器 S4 已选择服务器 S2 作为施主。从服务器 S2 到服务器 S4 执行状态转移,直到到达视图更改条目 VC4(view_id = VC4)为止。服务器 S4 使用临时的应用程序缓冲区进行状态传输,并且其二进制日志当前为空。

由于视图标识符是在同一逻辑时间传输到组中的所有成员的,因此加入该组的服务器知道应该停止复制哪个视图标识符。这避免了复杂的 GTID 集计算,因为视图 ID 清楚地标记了哪些数据属于每个组视图。

当加入组的服务器从供体复制时,它也在缓存来自组的传入事务。最终,它停止从供体复制并切换到应用那些已缓存的。

图 17.13 排队的 Transaction

状态转移已完成。服务器 S4 已应用事务直到 T20,并将它们写入其二进制日志。服务器 S4 已将在视图更改之后到达的事务 T21 缓存在恢复时的临时应用程序缓冲区中。

完成:赶上

当加入该组的服务器识别到带有预期视图标识符的视图更改日志事件时,到施主的连接将终止,并开始应用缓存的事务。要了解的重要一点是最终的恢复过程。尽管它在二进制日志中充当标记,但界定了视图更改的范围,但视图更改日志事件也扮演着另一个角色。当加入该组的服务器进入该组时,它传达所有服务器所感知的认证信息,换句话说,最后一个视图更改。没有它,加入组的服务器将没有必要的信息以能够认证(检测冲突)后续事务。

追赶的持续时间(第 2 阶段)不确定,因为它取决于工作负载和向该组传入的事务的速率。此过程完全在线,加入该组的服务器在追赶时不会阻止该组中的任何其他服务器。因此,由于这个原因,加入组的服务器进入第二阶段时的事务数量可能会有所变化,因此会根据工作负载而增加或减少。

当加入该组的服务器达到零排队事务且其存储的数据等于其他成员时,其公共状态将更改为联机。

图 17.14 在线实例

服务器 S4 现在是该组的联机成员。它已应用了缓存的事务 T21,因此其二进制日志显示的项目与其他组成员的二进制日志相同,并且不再需要临时的应用程序缓冲区。现在,所有组成员都接收并应用了新的传入 TransactionT22.