MYSQL--架构--MGR--理论--10--视图更新

MYSQL–架构–MGR–理论–10–视图更新

---

1、架构图

2、binlog中的特殊事件：视图更新

1. 在binlog中，除了DDL语句、DCL语句(grant,revoke)语句、DML语句生成的事件，还有一种因组复制而存在的特殊事件：视图更新事件(view change)。
2. 这个视图就是指成员管理服务

3、成员管理服务(成员视图)

1. 在组复制插件中，有一个内置的服务,称为"成员管理服务"(group membership service)。也叫成员视图
2. 可以在任何给定的时间点保持组的视图一致并可供所有服务器使用。
3. 服务器可以离开并加入组，视图也会相应更新。
   1. 有时，服务器可能会意外离开组，在这种情况下，故障检测机制会检测到此情况并通知组视图已更改。 这都是自动的。

3.1、功能

1. 维护组内的成员关系
2. 向外展示当前组内成员列表
3. 每当有成员加组、离组时，都会自动触发成员视图更新的行为，这意味着让成员管理服务去重新配置当前的组成员。举例
   1. 一个新成员加组成功时，这个组的大小加1，离组时组大小减1。

3.2、视图id和视图更新事件

1. 在成员加组、离组时会触发视图更改，它不是DDL、DCL、DML，但却也会当作一个事件t1写入binlog，这样才能在组内传播，让其它节点对视图更改进行投票。
2. 这个事件t1件称为"视图更改事件"。

3.2.1、案例

以下是binlog中某次视图更改对应的事件。

View_change   | view_id=15294216022242634:2

1. view_id：视图标识符，用来惟一标识一个视图

2. view_id由两部分组成

   1. 第1部分是创建组时随机生成的，在组停止(关闭)之前一直保持不变
   2. 第2部分是一个单调递增的整数，每次视图发生更改都递增一次.例如，以下是4个节点加入组时的binlog事件。

   View_change   | view_id=15294216022242634:1     # 第一个节点创建组
   View_change   | view_id=15294216022242634:2     # 第二个节点加入组
   View_change   | view_id=15294216022242634:3     # 第三个节点加入组
   View_change   | view_id=15294216022242634:4     # 第四个节点加入组
   
   

3.2.2、注意

1. 视图更改事件就像DDL/DCL事件一样，是非事务型的，不具有原子性和回滚性
2. 只要发生了就会记录到binlog中，即使加组失败或者离组失败。

3.2.3、使用这种混合视图id的原因

1. 可以标记 当成员加入或离开时发生的组成员配置更改
2. 可以标记 当所有成员离开组后没有任何信息保留在视图中。
3. 总而言之：
   1. 第1部分标识这个组是从什么时候启动的
   2. 第2部分标识组在什么时间点发生了更改。

3.2.4、总结

1. 在组通信层(架构图)，视图更改以及它们关联的视图id是加组之前和之后的区分边界。
2. 通过视图id，可以区分要同步的事务数据。例如
   1. 一个新节点加入到组，对应的view_id为id1，那么id1之前的事务数据需要全部复制到新节点上
   2. id1之后的事务是加组之后的事务，不需要复制给新节点(这部分事务会放进新节点的事务缓存队列)。
3. binlog中的view_change事件还 充当 组内其余节点感知新节点已经成功加组或成功离组功能，例如
   1. 新成员加组的情况，当view_id写入binlog，表示这个新节点已经标记为ONLINE，其它节点知道它已经在线了，信息广播的时候也会广播给这个新节点，这个新节点也会占有一个法定票数。