MGR 重要参数-group_replication_consistency

参数group_replication_consistency共 5 个值可选：

1. EVENTUAL：确保最终一致性，并不能保证数据实时同步。(MySQL 8.0.14 之前只有这一个选项)

2. BEFORE：确保本地强一致性，并不保证其他节点数据实时同步。

3. AFTER：确保全局强一致性，可以保证所有节点数据实时同步。

4. BEFORE_AND_AFTER：最高级别，确保本地强一致性，全局强一致性。结合 BEOFRE 和 AFTER 的特性。

5. BEFORE_ON_PRIMARY_FAILOVER：确保从节点晋升为主节点后的本地一致性。

接下来，在组复制的默认模式下讨论 EVENTUAL，BEFORE，AFTER 这三类值的含义以及使用场景。

二、环境准备debian-ytt1:3306(写节点，简称节点 1)

debian-ytt2:3306(读节点，简称节点 2)

debian-ytt3:3306(读节点，简称节点 3)

以下为集群 ytt_mgr 的状态，节点 1 为主，节点 2 和节点 3 为从。MySQL debian-ytt1:3306 ssl ytt Py > c1 = dba.get_cluster('ytt_mgr');MySQL debian-ytt1:3306 ssl ytt Py > c1.status();{ "clusterName": "ytt_mgr", "defaultReplicaSet": { "name": "default", "primary": "debian-ytt1:3306", "ssl": "REQUIRED", "status": "OK", "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.", "topology": { "debian-ytt1:3306": { "address": "debian-ytt1:3306", "mode": "R/W", "readReplicas": {}, "replicationLag": null, "role": "HA", "status": "ONLINE", "version": "8.0.20" }, "debian-ytt2:3306": { "address": "debian-ytt2:3306", "mode": "R/O", "readReplicas": {}, "replicationLag": null, "role": "HA", "status": "ONLINE", "version": "8.0.20" }, "debian-ytt3:3306": { "address": "debian-ytt3:3306", "mode": "R/O", "readReplicas": {}, "replicationLag": null, "role": "HA", "status": "ONLINE", "version": "8.0.20" } }, "topologyMode": "Single-Primary" }, "groupInformationSourceMember": "debian-ytt1:3306"}

三、三种选项值的含义和适用场景

3.1 EVENTUAL

这类选项代表最终一致性，组复制默认值。意思是说，设置了 EVENTUAL 的节点，其读或者写请求可以立即返回结果，不用等到新请求之前的中继日志处理完。创建一张测试表 t1。create table t1 (id serial primary key, r1 int,r2 int,r3 char(36));Query OK, 0 rows affected (0.07 sec)

节点 1 正常插入一条记录。insert into t1 (r1,r2,r3) select 10,20,uuid();Query OK, 1 row affected (0.02 sec)Records: 1 Duplicates: 0 Warnings: 0

节点 2 及时应用这条记录到表 t1。select * from t1;+----+------+------+--------------------------------------+| id | r1 | r2 | r3 |+----+------+------+--------------------------------------+| 1 | 10 | 20 | e878289e-89c4-11ea-861d-08002753f58d |+----+------+------+--------------------------------------+1 row in set (0.00 sec)

此时给节点 2 加一个 server 层的共享读锁，人为制造拥堵延迟。lock table t1 read;Query OK, 0 rows affected (0.00 sec)

节点 1 再次插入一条 ID 为 2 的新记录。insert into t1 (r1,r2,r3) select 20,20,uuid();

Query OK, 1 row affected (0.02 sec)

Records: 1 Duplicates: 0 Warnings: 0

select * from t1;

+----+------+------+--------------------------------------+

| id | r1 | r2 | r3 |

+----+------+------+--------------------------------------+

| 1 | 10 | 20 | e878289e-89c4-11ea-861d-08002753f58d |

| 2 | 20 | 20 | 2982d33f-89c5-11ea-861d-08002753f58d |

+----+------+------+--------------------------------------+

2 rows in set (0.00 sec)

此时再次查询节点 2 可立即返回结果，但是数据并非最新，不包含最新 ID 为 2 的记录，还是之前的旧数据。select * from t1;+----+------+------+--------------------------------------+| id | r1 | r2 | r3 |+----+------+------+--------------------------------------+| 1 | 10 | 20 | e878289e-89c4-11ea-861d-08002753f58d |+----+------+------+--------------------------------------+1 row in set (0.00 sec)

节点 2 上，ID 为 2 的这条记录，目前状态为：已拉到自己的中继日志，但尚未应用到表 t1。表 t1 的共享读锁释放掉后，才能继续应用。现在释放表 t1 的共享读锁，再次查询已经包含最新的记录。unlock tables;

Query OK, 0 rows affected (0.01 sec)

select * from t1;

+----+------+------+--------------------------------------+

| id | r1 | r2 | r3 |

+----+------+------+--------------------------------------+

| 1 | 10 | 20 | e878289e-89c4-11ea-861d-08002753f58d |

| 3 | 20 | 20 | 759cc5c0-89c7-11ea-861d-08002753f58d |

+----+------+------+--------------------------------------+

从以上例子可以看出，最终一致性模式优缺点。优点：可以快速返回本节点已经成功应用的数据，不用等待所有的数据应用完成。

缺点：可能返回的数据比较旧。

3.2 BEFORE

这类选项代表保证本地节点强一致性。也就是说设置为此选项的本地节点必须要等待中继日志数据全部应用完成后，才会执行新的请求，否则会一直等待。等待的时间和中继日志里未应用的事务量成一定比率。为了清晰起见，清空表 t1 数据。truncate t1;Query OK, 0 rows affected (0.17 sec)

新启一个连接到节点 2，给表 t1 上共享读锁，对应的 SESSION ID =1。lock table t1 read;Query OK, 0 rows affected (0.01 sec)

在节点 1 上插入一条新记录。insert into t1 select 1,1,1,uuid();Query OK, 1 row affected (0.02 sec)Records: 1 Duplicates: 0 Warnings: 0

另外开启一个新连接到节点 2，对应的 SESSION ID = 2。设置参数 group_replication_consistency=before，完了立刻查询表 t1 数据，处于等待状态。set @@group_replication_consistency='before';

Query OK, 0 rows affected (0.00 sec)

select * from t1;

# 此处 HANG 住！

在节点 3 上查询表 t1 数据，立刻返回刚才插入的记录，也就是说对节点 3 没有影响。select * from t1;+----+------+------+--------------------------------------+| id | r1 | r2 | r3 |+----+------+------+--------------------------------------+| 1 | 1 | 1 | ee83837e-89ce-11ea-861d-08002753f58d |+----+------+------+--------------------------------------+1 row in set (0.00 sec)

此时切换到节点 2 的 SESSION ID = 1 的会话，解锁表 t1。unlock tables;Query OK, 0 rows affected (0.00 sec)

再次查看节点 2 的 SESSION ID = 2 的会话，结果已经返回，时间为 3 分 17 秒。相比 EVENTUAL，并不是立即返回结果。select * from t1;+----+------+------+--------------------------------------+| id | r1 | r2 | r3 |+----+------+------+--------------------------------------+| 1 | 1 | 1 | ee83837e-89ce-11ea-861d-08002753f58d |+----+------+------+--------------------------------------+1 row in set (3 min 17.51 sec)

可以看出，BEFORE 模式优先保证了本地节点永远读取到最新的数据。最大的缺点是必须煎熬等待本地节点中继日志里未应用的数据正常应用。如果日志里有很多写的不好的事务块或者大事务，则会造成本节点很大的延迟。

3.3 AFTER

这类选项代表全局强一致性。设置为此模式的节点，必须等待集群内其他所有其他节点应用完自己中继日志里的事务，才能返回结果。把节点 1 参数group_replication_consistency设置为 AFTER，清空表 t1。truncate t1;

Query OK, 0 rows affected (0.22 sec)

set @@group_replication_consistency='after';

Query OK, 0 rows affected (0.00 sec)

在节点 2 上，给表 t1 加共享读锁。lock table t1 read;Query OK, 0 rows affected (0.01 sec)

之后在节点 1 插入一条记录，并没有立即返回，处于等待状态，因为节点 2 上的表 t1 被锁了，节点 2 的日志要成功应用必须要等表 t1 解锁才可以。insert into t1 select 1,1,1,uuid();

# 处于等待状态

此时回到节点 2，由于模式默认，立即返回结果，不过数据很旧。select * from t1;Empty set (0.00 sec)

此时在节点 3 上对表 t1 进行查询，发现这个请求也处于等待状态。也就是说虽然节点 3 也是默认模式，但是由于主节点设置为 AFTER，节点 3 也必须等待其他的从节点日志应用完毕后才能返回结果。select * from t1;

现在在节点 2 上解锁表 t1，再次回到节点 1 上的 ID 为 121 的连接，结果已经返回，不过花费了 6 分 47 秒。insert into t1 select 1,1,1,uuid();Query OK, 1 row affected (6 min 47.14 sec)Records: 1 Duplicates: 0 Warnings: 0

此时在节点 3 上检查之前的查询，结果也已经返回。select * from t1;+----+------+------+--------------------------------------+| id | r1 | r2 | r3 |+----+------+------+--------------------------------------+| 1 | 1 | 1 | 49430687-89e9-11ea-861d-08002753f58d |+----+------+------+--------------------------------------+1 row in set (18.25 sec)

从以上过程可以看到，AFTER 是一个强同步的选项。优先保证了集群内所有节点的数据一致性，但是也带来一个很大的性能问题：集群对外总的事务提交时间依赖于组内最慢的那个节点。如果最慢的节点遇到故障，那其他节点就必须等待超时回滚了。

 

AFTER 执行流程
首先，在事务执行节点上的流程如下：

1.首先，事务进入提交阶段后，会执行一个before_commit的HOOK，在 mgr 中，对应的实现是 group_replication_trans_before_commit。AFTER 的一致性保证通过该接口实现。 2.假设事务 T1 在节点 M1 上执行，如果是 AFTER 级别，会通过 paxos 发送一个携带事务全部数据的Transaction_with_guarantee_message消息，消息类型为 CT_TRANSACTION_WITH_GUARANTEE_MESSAGE。 3.节点接收到该消息并处理时，首先会获取当前集群中的 online_members。这里需要注意的是，即使节点状态变为 UNREACHABLE，只要没有踢出集群，也会认为是 online_members。 4.节点 M1 需要等待其它节点的消息反馈 5.节点M1只有收到上述 online_members 中所有节点的 prepared 消息时，才能继续完成提交

接下来，看一下其它节点（以M2节点为例）处理 AFTER 事务的流程：

1.首先，paxos 接收到事务，并进入事务执行阶段 2.事务T1在M2进入提交阶段时，调用 before_hook进行处理，不同于 M1的用户线程，M2上的复制线程是在 GR_APPLIER_CHANNEL 上执行 3.将事务加入到 prepared 事务列表 4.发送 transaction_prepared 消息给所有的节点，并等待处理 5.接收到其它节点对 transaction_prepared 消息确认后，从 prepared 事务列表中移除该事务，并继续提交

对于 AFTER 模式，所有的节点在处理事务时，均需要发送一个 transaction_prepared 消息并等待所有节点的确认，之后，用户线程执行的事务才能成功提交。排除用户线程等待所有节点事务提交的时间开销，这些消息处理的网络开销也会对性能造成一定的影响。

BEFORE 执行流程
与 AFTER 相对应的是 BEFORE，如果一个 session 开启了 BEFORE 级别，则在事务开启时，需要等待所有已经提交的事务已经在本地完成提交，这是通过 WAIT_FOR_GTID_SET 实现。在事务的开启时刻，获取到节点已经同步接收到的所有的事务 gtid 集合，并等待集合内所有的 gtid 完成提交，即可保证事务执行时，读取到最新的数据。

但是在获取 gtid 集合之前，节点需要通过 paxos 发送一个 SYNC_BEFORE_EXECUTION 类型的消息。由于 paxos 会对消息进行排队，因此，当 SYNC_BEFORE_EXECUTION 处理完成时，可以保证该消息发送之前的所有的事务消息均完成在 paxos 中的处理。由于该消息是本次事务开启时产生的，因而此时节点收到的 gtid 集合符合 BEFORE 级别。

如果节点不发送 SYNC_BEFORE_EXECUTION 消息，则 BEFORE 级别未必能够读取到最新数据。假设当前存在网络分区，总共三个节点A，B，C，网络分区后，A，B节点组成多数派，C节点为少数派，此时，A，B节点上新的写入事务将不会继续同步到C节点。在 C 节点被踢出集群之前，如果 C 开启了 BEFORE 级别，却未发送 SYNC_BEFORE_EXECUTION 消息，那么 C 中不能读取到新的数据，违背了 BEFORE 的设计宗旨。但是发送该消息后，由于无法达成消息一致性，那么新的事务将失败、或者一直等待消息返回，而不会返回用户过时的数据

原文链接：https://blog.csdn.net/weixin_36187176/article/details/113338625