MGR节点全部关闭后的启动

大家好！ 今天大表哥分享一个真实的MGR的测试环境重启的案例。

近日公司的测试数据库环境掉电，造成了机器意外的关机，测试环境大多数都是mysql 3 节点的MGR， 重启之后，发现有些节点的状态是异常的并且无法加不到MGR的组复制组中。

我们今天在实验环境下模拟一下：

如果MGR节点全部down掉：

可能是MGR集群意外crash,并且集群已经做了多次主从切换，并且最后所有的节点全部关闭

或者

可能是计划内的人工维护， 先关闭从库，最后关闭主库

我们改如何重启动MGR集群呢？

在哪个节点引导 group_replication_bootstrap_group 组复制，保证顺利启动为不丢数据？

我们的3台试验节点环境：

我们在主节点 3308 创建表：插入测试数据

此时，我们模拟OOM, kill掉一个从库 3307的mysqld 进程：

这个时候MGR的集群试图是：

现在这个MGR的集群依然是可用的，我们来继续插入数据

然后我们来正常关闭节点 3306：

这个时候我们只有一个节点存活 3308：

我们是依然可以插入成功的：

（这个是MGR的特点，正常shutdown, MGR会认为是节点正常的退出，所以只有一个节点，依然是可读可写）

最后我们 kill点 3308这个唯一存活的节点的mysqld 进程。

至此MGR中的3个节点全部都已经down了, 我们现在尝试恢复一下：

首先先把3个几点mysqld全部启动：

我们看到3个节点的MGR的状态都是offline的：

我们应该在哪个节点去引导group_replication_bootstrap_group？ 这里假设我们并不知道集群到底是如何crash的顺序。

我们只能通过 @@gtid_executed 来判断哪个节点最靠后了，证明他的数据是最后的，他就是最后的主库。

我们可以看到 3308 的GTID 是最大的，那么他就是最后的主库，我们需要在 3308上引导组复制 group_replication_bootstrap_group

3306–》 b965e3bb-be27-11ec-ba80-525400743c33:1-22

3307–》 b965e3bb-be27-11ec-ba80-525400743c33:1-21

3308–》 b965e3bb-be27-11ec-ba80-525400743c33:1-23

全部启动完毕后，MGR集群满血复活：

如果我们很不幸运，引导在错误的节点（GTID低的节点上）上引导了 group_replication_bootstrap_group, 那么我们将面临丢数据的危险，并且GTID 大的节点是拒绝加入到MGR组里面的。

下面我们具体来看一下： 测试环境，丢失数据可以接受的情况

我们先清空上一次实验的表：

最原始MGR的主从信息：

现在我们向主库3308 插入记录：

然后我们来正常关闭数据库3306 ：

我们再次向主库 3008插入数据：

然后我们再次关闭 3307 这个从库：

我们再一次向主库 3008插入数据：

我们最后关闭掉主库 3308：

至此MGR上的所有的节点全部down掉。

我们现在把3个节点全部起来：

我们登陆各个节点查看一下GTID的值：

MGR各个节点的GITD:

3308->b965e3bb-be27-11ec-ba80-525400743c33:1-58

3307->b965e3bb-be27-11ec-ba80-525400743c33:1-57

3306->b965e3bb-be27-11ec-ba80-525400743c33:1-56

很明显3308是集群中最后的主库，其GTID的值为最大： 1-58

这个时候，我们人为失误把 3306 这个节点作为了主节点： 来引导 group_replication_bootstrap_group:

我们从日志中可以看到，这个时候 3306 这个节点被选为了主节点：

2022-04-20T14:04:27.161451+08:00 0 [Note] [MY-013519] [Repl] Plugin group_replication reported: 'Elected primary member gtid_executed: 9915aff5-bbd6-11ec-9110-525400743c33:1-13,
b965e3bb-be27-11ec-ba80-525400743c33:1-57'
2022-04-20T14:04:27.161470+08:00 0 [Note] [MY-013519] [Repl] Plugin group_replication reported: 'Elected primary member applier channel received_transaction_set: 9915aff5-bbd6-11ec-9110-525400743c33:1-12,
b965e3bb-be27-11ec-ba80-525400743c33:1-28:32:36-39:46-49:53-57'
2022-04-20T14:04:28.161566+08:00 0 [Note] [MY-011507] [Repl] Plugin group_replication reported: 'A new primary with address 82.156.200.136:3306 was elected. The new primary will execute all previous group transactions before allowing writes.'
2022-04-20T14:04:28.162211+08:00 24 [Note] [MY-011485] [Repl] Plugin group_replication reported: 'Primary had applied all relay logs, disabled conflict detection.'


这个时候我们再启动GTID最高的 3308 这个节点：

启动报错：

ERROR 3092 (HY000): The server is not configured properly to be an active member of the group. Please see more details on error log.

查看具体的日志信息是

2022-04-20T14:05:29.120482+08:00 0 [ERROR] [MY-011526] [Repl] Plugin group_replication reported: ‘This member has more executed transactions than those present in the group. Local transactions: 9915aff5-bbd6-11ec-9110-525400743c33:1-13,

b965e3bb-be27-11ec-ba80-525400743c33:1-58 > Group transactions: 9915aff5-bbd6-11ec-9110-525400743c33:1-13,

b965e3bb-be27-11ec-ba80-525400743c33:1-57’

2022-04-20T14:05:29.120514+08:00 0 [ERROR] [MY-011522] [Repl] Plugin group_replication reported: ‘The member contains transactions not present in the group. The member will now exit the group.’

这个报错信息已经很明显了， 从节点的GTID 1-58 大于 主节点的GTID 1-57。

如果数据可以忽略掉，我们可以在主库3306 上手动的设置GTID_NEXT跳到 1-58 这个值：

我们再次重启3308 这个节点：

这次可以顺利启动成功， MGR集群中也恢复了正常。

我们另外一个节点也启动起来：

目前只是看起来很集群很正常，但是数据在不同的节点上已经存在了差异。

在数据一致性上，是不能够被接受的。

所以手动指定GTID_NEXT,然后跳过空事务，造成了数据的不一致，对后续的业务测试也会产生不可预知的影响。

最后的结论： MGR 集群down机后（人工正常维护或者是异常crach），正确的方式必须确定在GTID是最大的节点上来引导 group_replication_bootstrap_group 最为主节点， 从而保证各个节点数据的一致性。

今天也在官方文档上得到了证实： https://dev.mysql.com/doc/refman/8.0/en/group-replication-restarting-group.html

大家可以参考一下，官网是最严谨的。