doc: 阅读mysql group replication文档

mysql/mysql集群/Mysql Group Replication.md

@@ -11,6 +11,11 @@
         - [Primary Election Algorithm](#primary-election-algorithm)
         - [Finding the Primary](#finding-the-primary)
       - [Multi-Primary Mode](#multi-primary-mode)
+        - [Transaction checks](#transaction-checks)
+        - [Data Definition Statements](#data-definition-statements)
+        - [Version Compatibility](#version-compatibility)
+    - [Group Membership](#group-membership)
+        - [group\_replication\_member\_expel\_timeout](#group_replication_member_expel_timeout)
 
 
 # Mysql Group Replication
@@ -181,3 +186,58 @@ group replication是一个最终一致性的系统，其代表当incoming traffi
 
 如果想要为group中的每个事务提供一致性保证，可以使用`group_replication_consistency`系统变量实现。可以根据group中工作负载和数据读写的优先级来选择合适的设置，同时应考虑提升一致性所引入的同步操作对性能带来的影响。可以针对独立的session来设置该系统变量，从而保护对并发性敏感的事务。
 
+##### Transaction checks
+当group在multi-primary mode下部署时，事务将会被校验，确保其和该模式兼容。如下strict consistency checks将会在multi-primary部署模式下被校验：
+- 如果事务在SERIALIZABLE的隔离级别下被执行，那么在`synchronizing itself with the group`时（指通过原子广播向group发送write set和write values时），提交操作将会失败
+- 如果事务执行时目标table拥有级联约束，那么在`synchronizing itself with the group`时，其提交将会失败
+  - 如果在MGR中允许级联，在不同的members中，级联操作影响的行可能有不同，这样会影响members中数据的一致性
+
+上述校验通过`group_replication_enforce_update_everywhere_checks`的system variable来进行控制。在multi-primary mode的场景下，system variable应该被设置为`ON`，但是该校验可以被关闭，通过将system variable设置为`OFF`。当在single-primary模式下部署时，system variable必须被设置为`OFF`
+
+##### Data Definition Statements
+在Group Replication在multi-primary模式下的拓扑中，需要额外关注DDL的执行场景。
+
+mysql 8.4支持atomic ddl，ddl语句的执行要么提交、要么删除，类似一个原子的事务。对于DDL语句，无论其是否是原子的，都会隐式的终止当前session中活跃的事务，如同在执行ddl statements之前执行了`COMMIT`。这将代表，DDL statements无法在另一事务中执行，也无法在`start transaction ... commit`中执行，更无法将多个ddl statements整合在一个事务中执行。
+
+Group Replication基于的是乐观的replication范式，statements首先会被乐观的执行，并且在后续有需要时回滚。每个server在执行statements之前，不会先确保在group内达成共识。故而，在multi-primary mode下，对DDL进行复制需要更加注意。
+
+`如果在执行DDL对schema进行变更时，也对同一张表的数据执行了DML变更，那么在DDL变更被完成并复制到所有members之前，需要确保DML操作在同一个server上被处理。`
+
+如果没有确保上述行为，那么可能会导致数据的不一致性，从而导致操作被中断或被部分完成。
+
+但是，当group通过single-primary模式被部署时，该问题则不会发生，所有修改操作都会被发送到同一server，即primary server。
+
+##### Version Compatibility
+为了实现最佳兼容性和性能，group中的所有members都应当运行在相同的mysql server版本下，从而保证相同版本的group replication。在multi-primary mode下，该要求将更加重要，因为所有加入到group的members都处于read/write模式。如果group中的成员运行了多个mysql版本，则存在部分成员和其他成员不兼容的风险，不同版本成员之间支持的方法可能有所不同。
+
+为了防范上述问题，当新member加入到group时（包含之前的member被升级或重启的场景），该member将会对group中的其他members进行兼容性检查。
+
+在multi-primary mode下，兼容性检查的结果尤为重要。如果新加入member运行的mysql server版本比`当前group中member最小的版本号`更高，那么其将以read-only的模式加入到group中。
+
+如果group运行在multi-primary mode下，使用了不同的mysql server versions，group replication将自动管理memebers的read/write和read-only状态。如果member离开group，那么离开后`当前运行最低版本的members`将会自动被设置为read/write模式。
+
+如果将运行在single-primary mode下的group修改为在multi-primary下运行，那么可以使用`group_replication_switch_to_multi_primary_mode()`方法，group replication将会自动将members设置为正确的模式。并且，对于运行的版本比lowest-version高的members，其状态将会被自动设置为read-only，而运行lowest-version则将会被设置为read/write状态。
+
+### Group Membership
+在mysql group replication中，多个servers组成了replication group。group拥有UUID形式的名称。group是动态的，server可以在任何时刻加入/离开group。在server加入或离开group时，group能够对自身进行调整。
+
+如果server加入到group，其会自动从现存的server处拉取最新的状态，令自身保持最新状态。如果server离开group（例如因维护而下线），那么剩余的servers将会监测到server已经离开，并且自动对group进行reconfigure。
+
+group replication中拥有一个group membership service，其定义了哪些servers处于online状态并加入到group。online servers的列表被称为`view`。group中每个server都拥有一致的view，能够获知给定时刻哪些servers作为group中的members是活跃的。
+
+group members不仅需要对事务的提交达成一致，也需要对当前的view达成一致。如果现有members认同一个新的server应该成为group的一部分，那么group将被reconfigure，并将该server纳入group，这也将触发view的变更。如果server离开group，不管是主动还是非预期退出，group将会动态调整配置并且触发view的变更。
+
+如果member自愿离开group，那么其首先会触发动态的group reconfiguration，在此期间所有的members都应该就`new view without the leaving server`达成一致。
+
+但是，如果member非预期的退出group（例如因网络连接中断而停止运行），则非预期退出的member无法发起reconfiguration。在该场景下，group replication的failure detection mechanism将会在member离开的短暂时间期间之后检测到该退出行为，并且提出`a reconfiguration of the group without the failed member`。
+
+当member主动离开group时，reconfiguration需要majority of servers达成一致，但是如果该group无法达成一致（例如因为网络分区导致在线servers数量没有达到majority），那么系统将无法动态的更改configuration；为了防止split-brain场景，系统会处于阻塞状态。对于该种情况，需要管理员的干预。
+
+对于member而言，下线一小段时间，并且在failure detection mechanism探知到该failure前尝试重新加入group是可能的，此时group也不会reconfigre并移除该member。在该场景下，重新加入group的member将会忘记之前的状态，`但是，若存在其他members发送给其崩溃前状态的消息`，这将可能会造成数据不一致的问题。
+
+为了检测这种情况，MGR会检测相同server的新实例（server address和port号相同）想要加入到group，而server的旧实例也被作为member的场景。那么，在这种情况下，新实例的加入操作将会被阻塞，直到旧实例可以通过reconfiguration被移除。
+
+##### group_replication_member_expel_timeout
+通过`group_replication_member_expel_timeout`的system variable，引入了一个waiting period，允许members该时间内重新连接到group，从而避免被从group中驱逐。如果member在该时间范围内重新连接到了group，那么该member可以重新在group中处于活跃状态。但是，当member超过expel timeout并且从group中被驱逐时，或通过`STOP GROUP_REPLICATION`语句停止group replication时，或server failure时，其必须作为新的实例加入到group中。
+
+