17.9.5.3 查看更改

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

开始：稳定小组

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

图 17.10 稳定组

视图更改：成员加入

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

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

图 17.11 会员加入

状态转移：追赶

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

图 17.12 状态转移：追赶

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

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

图 17.13 排队的 Transaction

完成：赶上

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

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

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

图 17.14 在线实例