主要timeout参数说明

mgr 相关timeout参数

group_replication_unreachable_majority_timeout

用途：多数节点故障，或者网络分区情况下，节点等待退出的时间。

1. global变量
2. mgr运行过程可动态调整，并立即生效
3. 不要求mgr中各个节点的变量参数值保持一致
4. 取值范围0-31536000，单位为秒，默认值为0。需要特别说明的是，在greatdb-cluster集群中，节点加入集群后，会通过persist方式默认设置为30。

场景1：多数节点故障

假设A，B，C三个节点组成的MGR集群，状态均为ONLINE，B，C节点同时crash故障。此时，A节点的状态受该参数影响。A节点在检测到B、C节点故障后，故障节点会变成UNREACHABLE状态：

在等待unreachable_majority_timeout秒，A节点换成ERROR状态，如下：

但如果参数值设置为0，则A中查询状态一直保持不变，即A为ONLINE，B、C为UNREACHABLE。

需要说明的是，虽然在unreachable_majority_timeout超时之前，A的状态一直显示为ONLINE，但由于多数节点故障，A节点并不能完成事务提交。此时，如果事务进入提交阶段，会一直夯住，直至超时后报错。

场景2：网络分区

仍假设A，B，C三个节点，A节点发生网络故障，B、C节点间仍可以正常通信。此时，A的状态和B、C故障情况下是一致的。但B、C节点组成的子网，包含多数节点，仍可以达成paxos协议。此时，B，C节点会通过member_expel_timeout的超时机制，将A节点踢出集群。因此，总体的节点变化如下（此处，我们默认unreachable_majority_timeout > member_expel_timeout）：

首先，在member_expel_timeout超时之前：

member_expel_timeout超时后，unreachable_majority_timeout超时之前

unreachable_majority_timeout超时后

此时，在unreachable_majority_timeout超时之前，A节点无法完成事务提交。进入提交的事务会夯住，直至超时报错。

上述两个场景主要描述的mgr集群中节点故障的行为。具体到greatdb-cluster，由于sqlnode和datanode均部署为mgr，因此情况可能会稍显复杂。

场景3：datanode故障或者网络分区

1. datanode两个从节点crash，此时，在unreachable_majority_timeout（30s）之前，datanode主依旧为ONLINE状态，前端的业务还能发到主节点执行，但是事务提交语句（COMMIT，XA PREPARE，XA COMMIT）会夯住，直至超时后返回错误。超时之前，检测datanode主节点的状态正常，可以正常接收用户各类请求，但无法完成事务提交。超时后，节点异常，夯住的事务返回错误。不过，由于从节点均crash，本身该shard就无法提供服务了。
2. datanode主节点网络故障。此时，sqlnode无法连接datanode主节点，节点状态为ERROR，待两个从节点选出新主后，集群可以提供服务。故障时间可能在5-10s左右。
3. datanode主节点和两个从节点网络分区，但sqlnode可以正常访问所有的datanode节点。这种情况最为特殊，首先，两个从节点会选出新的主节点，但这个时候，原主节点的mgr依旧为ONLINE，此时，从sqlnode层面可能查询到shard中有两个节点处于ONLINE。目前集群逻辑，我们无法预知具体新的请求会发送到那个节点，如果是发送到新主，则可以正常执行；如果发送到老主，则在等待unreachable_majority_timeout超时后返回错误。

场景4：sqlnode故障或者网络分区

1. sqlnode网络故障，假设sqlnoe-A网络故障，则A根本无法接收外部请求。
2. sqlnode网络分区，在unreachable_majority_timeout之前，A的状态依旧为ONLINE，可以接收业务请求；同时，由于普通DML事务的commit节点，不会在sqlnode层面产生binlog，不会触发sqlnode间的mgr同步，A依旧可以正常完成事务的读写请求和进行事务提交。在unreachable_majority_timeout超时后，A节点无法提供服务，但仍可以完成已经进入commit阶段的事务。但是，DDL事务，由于需要在sqlnode层面进行mgr同步，因此A无法完成DDL事务，DDL语句会夯住并在超时后返回错误。
3. 多数sqlnode节点crash，A节点在unreachable_majority_timeout之前，同样可以完成DML事务的整个过程。DDL语句会在超时后返回操作。

场景5：DTM server故障

主要关注sqlnode网络分区问题。如果DTM server节点（A）网络分区，在unreachable_majority_timeout超时之前，A仍可以执行DML事务，因为A本身就是DTM server，也可以正常获取dtid，那么A依旧可以正常完成事务全过程。而B、C节点，在member_expel_timeout后，会将A踢出mgr集群，并选出新的DTM server节点，假设为B，之后，B、C也可以完成事务提交。那么，会存在一段时间，存在A，B两个DTM server节点。

需要后续进一步验证下，这种情况下，是否可能出现事务可见性问题。

group_replication_member_expel_timeout

用途：节点故障后，剩余多数派剔除故障节点的等待时间。

1. global变量
2. mgr运行过程可动态调整，并立即生效
3. 不要求mgr中各个节点的变量参数值保持一致， 但推荐各节点保持配置一致
4. 取值范围0-3600，单位为秒，默认值为5。greatdb-cluster集群未更改用户的配置值。
5. 强烈不建议将该值设置过大，一般情况下使用默认配置即可

假设A，B，C三个节点，如果C节点crash，或者网络故障，剩余的A，B两个节点仍可以达成paxos多数派协议。A，B在检测C故障后，首先会将C的状态设置为UNREACHABLE，然后，在member_expel_timeout超时后，将C踢出mgr集群。需要注意的是，检测故障本身也可能耗时0-5s，因此，当设置member_expel_timeout=5s的情况下，实际踢出故障C节点的时间可能在5-10s的范围内。

该值设置过大有几个问题：

1. 故障C节点长时间无法踢出mgr
2. 由于C未踢出mgr集群，如果C节点故障恢复，此时也无法加入mgr集群

group_replication_communication_flp_timeout

非MySQL官方的参数。

在MySQL官方的MGR中，各节点间会定期交换消息，当超过5秒（固定值）还没收到某个节点的任何消息时，就会将这个节点标记为可疑状态。当故障节点确定可疑状态后，会继续等待group_replication_member_expel_timeout超时，并在expel_timeout超时后，将该节点驱逐出MGR。

在GreatDB系列版本引入了group_replication_communication_flp_timeout参数，用于控制检测可疑状态的超时时间，用于替换官方固定的5秒时间值。目前，集群尚未配置该参数，使用的是默认配置参数5s的时间。

将该参数值设小后，可以更快的检测到节点的可疑状态；同时配合group_replication_member_expel_timeout参数，可以更快的剔除故障节点。

一般场景下，无需配置该参数值。