本节解释控制视图更改标识符如何合并到二进制日志事件并写入日志的过程，采取以下步骤：
每当新成员加入组并因此执行视图更改时，每个在线服务器都会排队执行视图更改日志事件。这是排队的，因为在视图更改之前，多个事务可以在服务器上排队等待应用，因此，这些属于旧视图。将视图更改事件排在它们之后可以保证正确标记何时发生。
同时，加入群组的服务器通过视图抽象从成员服务声明的在线服务器列表中选择捐赠者。一个成员在视图 4 上加入，在线成员将视图更改事件写入二进制日志。
一旦加入该组的服务器选择了该组中的哪个服务器作为捐赠者，就会在两者之间建立一个新的异步复制连接，并且状态传输开始（阶段 1）。这种与捐赠者的交互一直持续到加入组的应用程序线程处理与加入组的服务器进入组时触发的视图更改对应的视图更改日志事件。换句话说，加入该组的服务器从捐赠者那里复制，直到它到达具有与它已经在的视图标记匹配的视图标识符的标记。
由于视图标识符在同一逻辑时间传输到组中的所有成员，因此加入组的服务器知道它应该停止复制哪个视图标识符。这避免了复杂的 GTID 集计算，因为视图 id 清楚地标记了哪些数据属于每个组视图。
当加入该组的服务器正在从捐赠者复制时，它也在缓存来自该组的传入事务。最终，它停止从捐赠者复制并切换到应用缓存的那些。
当加入该组的服务器识别出具有预期视图标识符的视图更改日志事件时，与捐赠者的连接将终止并开始应用缓存的事务。需要了解的重要一点是最后的恢复程序。尽管它在二进制日志中充当标记，定界视图更改，但视图更改日志事件还扮演着另一个角色。它传达了加入组的服务器进入组时所有服务器感知到的认证信息，换句话说，最后一次视图更改。没有它，加入该组的服务器将没有必要的信息来证明（检测冲突）后续交易。
追赶（第 2 阶段）的持续时间不是确定性的，因为它取决于工作量和组中传入事务的速率。这个过程是完全在线的，加入该组的服务器在追赶过程中不会阻塞组中的任何其他服务器。因此，当服务器进入阶段 2 时，加入该组的服务器落后的事务数可能会因此而变化，因此会根据工作负载而增加或减少。
当加入该组的服务器达到零排队事务并且其存储的数据与其他成员相同时，其公共状态变为在线。
