20.1.1.2 组复制 Group Replication

组复制是可以用来实施容错系统的技术。复制组中的所有server中都包含他们完整的数据副本(shared-nothing复制模式)，互相通过消息传递进行交互。communication层提供了比如原子消息和完全有序的消息传递等一组保障。这些都是非常强大的特性。可以转化为非常有用的抽象概念，人们可以依赖这些抽象来构建更高级的数据库复制解决方案。(这些解决方案可能包括高级的数据同步机制、更精细的故障检测和恢复策略等。)

MySQL组复制建立在这些特性和抽象的概念之上，通过这些实施多主更新，无处不在的复制协议

MySQL组复制正是建立在这些属性和抽象之上，并实现了多源更新的处处复制协议。这意味着MySQL组复制能够接收来自多个源的数据更新，并在组内的每个成员上实现这些更新，从而确保数据在整个组中的一致性和同步。这种多源更新的设计使得组复制更加灵活和高效，能够适应各种复杂的数据库复制场景

 由多个server组成的复制组可以在任何时间独立的在组中执行事务，然而所有的读写事务请求在组中被批准通过后才能提交。换句话说，对于任何读写事务，都需要再组中决定他是是否可以提交。所以提交操作不只是操作的server单方面的决定。只读事务不需要和组内成员进行协调后，会立即提交。

当发起事务的server准备提交一个读写事务时，这个server会原子的广播这个写值(write values对应的write set，即行数据已被更改)和响应的写集(write set，唯一标识被更新的行)，因为事务是被原子地广播，所以要么组中的所有。servre都收到要么都没接收到。如果组内成员接收到该信息，那么它们都会以相同的顺序接收，这与之前发送的其他事务的顺序保持一致。因此，所有服务器都会以相同的顺序接收到相同的事务集，从而为这些事务建立了一个全局的总顺序。

个人理解：

1. 原子性广播：原子性广播是确保消息在分布式系统中以一致和可靠的方式传播的一种机制。在MySQL组复制中，当有一个读写事务准备在源服务器上提交时，它使用原子性广播来确保写值和写集能够可靠地发送给组内的所有其他服务器。原子性意味着这个操作是不可分割的，即要么完全成功，要么完全失败，没有中间状态。

2. 写值和写集：写值是事务中实际更改的数据行，而写集则是这些行的唯一标识符。通过发送写集，接收服务器能够识别哪些行被更新，并据此更新自己的数据副本。

3. 全局总顺序：通过确保所有服务器以相同的顺序接收事务，MySQL组复制能够维护一个全局的总顺序。这对于确保数据一致性和避免冲突至关重要。因为所有服务器都按照相同的顺序应用事务，所以它们最终都会达到一致的状态。

4. 容错性：由于使用了原子性广播，即使在网络分区或其他故障情况下，也能够保证要么所有服务器都接收到事务，要么都不接收。这有助于维护数据的一致性和系统的容错能力。

然而，在不同的server上并发的执行事务间可能会存在冲突，比如通过检查和比较两个不同且并发的事务的写集进行冲突探测，这个过程叫做certification(认证)。在认证期间,是以行级别进行冲突检测：如果两个不同的server上执行的并发事务，更新了同一行，那么这就出现了冲突(conflict)。那么冲突处理程序规定，第一个被排序的事务在所有服务器上提交，而第二个被排序的事务则会中止，因此在源服务器上会被回滚，并被组内的其他服务器丢弃(组内冲突的事务比如序列号为1，2，3，则第一个提交，发起2，3的事务会在发起的server中被回滚并在组内其他的servre中丢弃该事务)。比如说，如果在不同的节点并发的执行t1和t2两个事务，并且这两个事务修改的都是同一行数据，t2的顺序在t1之前，那么在冲突检测中t2会通过冲突检测，而t1会被回滚。这实际上是分布式首次提交获胜规则。如果两个事务很可能经常发生冲突，那么将它们启动在同一台服务器上是一个好的实践。这样，它们就有机会在本地锁管理器上进行同步，而不是因为认证过程而导致被回滚。

对于应用和外部化已认证的事务，组复制允许服务器在不破坏一致性和有效性的前提下，偏离事务商定的顺序。组复制是一个最终一致性系统，这意味着一旦输入流量减缓或停止，所有组成员的数据内容就会相同。在流量流动的过程中，事务可能会以略微不同的顺序被外部化，或者在某些成员上比其他成员更早地被外部化。例如，在多主模式下，本地事务可能会在认证后立即被外部化，尽管在全局顺序中更早的远程事务尚未被应用。当认证过程已经确定事务之间没有冲突时，这是允许的。在单主模式下，主服务器上存在很小的可能性，即并发且没有冲突的本地事务可能会以不同于组复制商定的全局顺序的顺序进行提交和外部化。在次服务器上，由于它们不接受来自客户端的写操作，事务总是按照商定的顺序进行提交和外部化。

1. 最终一致性：组复制是一个最终一致性系统，这意味着尽管在数据流动的过程中，不同服务器上的数据状态可能暂时不一致，但最终，当数据流量减缓或停止时，所有服务器的数据都会变得一致。这种设计允许系统在高并发和分布式环境下保持较高的可用性和性能。

2. 事务的外部化：在组复制中，事务的“外部化”通常指的是事务的更改被永久地应用到数据库中，并对外部可见。这通常发生在事务提交之后。

3. 多主模式与单主模式：

   • 多主模式：在这种模式下，多个服务器都可以接受来自客户端的写操作。由于网络延迟和并发处理的原因，不同服务器上的事务可能会以不同的顺序被外部化。但是，只要认证过程确定这些事务之间没有冲突，这种顺序的不一致是可以接受的。
   • 单主模式：在这种模式下，只有一个主服务器接受来自客户端的写操作。尽管主服务器上的本地事务可能会以不同于全局顺序的顺序进行提交和外部化，但由于次服务器不直接处理写操作，它们总是按照全局顺序来应用事务。

4. 事务的顺序：虽然组复制允许事务以不同于全局顺序的顺序被提交和外部化，但这通常是在没有冲突且不会破坏数据一致性的前提下进行的。当事务之间存在冲突时，组复制会使用一种冲突解决机制来确定事务的执行顺序。

下图描述了 MySQL Group Replication 协议，通过将其与 MySQL Replication（甚至是 MySQL 半同步复制）进行比较，您可以看到一些不同之处。为了清晰起见，本图中缺少了一些底层共识和 Paxos 相关信息。