最近在使用MySQL InnoDB Cluster中，遇到了一个比较大的问题。

问题背景：

在运行一个cluster中，其物理架构如下：

为了体验如何从整个cluster宕机到恢复的过程，本人手动将5台虚拟机直接关机，模拟物理断电下的cluster宕机场景。

问题描述

关闭所有机器后，手动重启整个cluster中的每一个server。这个时候我们需要重启整一个cluster。这一个在mysql shell 提供了对应的API。我们在mysql shell 重启整个cluster。shell> mysqlsh --log-level=DEBUG3

MySQL JS> shell.connect('root@vm000')

MySQL JS> let cluster = dba.rebootClusterFromCompleteOutage('cluster_name')

MySQL JS> cluster.status()

执行完以上命令后，我们使用cluster.status()查看，会发现secondary机器会处于RECOVERING状态，然后有一些机器有时候就能从RECOVERING状态转换到ONLINE状态。但是有一些机器会从RECOVERING状态转换成MISSING状态。

图中vm000 处于ONLINE状态，vm001处于RECOVERING状态，vm002、vm003、vm004均处于MISSING状态。

处于MISSING状态，一般是机器在线，但是因为数据同步出现错误而导致了MISSING状态。这个时候我们根据官方的mysql shell APIMySQL JS> cluster.rejoinInstance('root@vm001')

这个时候vm001会再次处于RECOVERING状态。cluster.status()

但是vm001、vm002、vm003、vm004在经过多次的cluster.rejoinInstance('root@vm001')、cluster.rejoinInstance('root@vm002')、cluster.rejoinInstance('root@vm003')、cluster.rejoinInstance('root@vm004')之后仍然会从RECOVERING状态转换到MISSING状态。

server加入cluster失败一直处于MISSING状态，导致该问题的原因是什么？解决该问题的方案又是什么?

解决过程导致该问题的原因？

解决该问题的方案？

因为以往我也曾经遇到过这个问题，因为vm000中的事务要远多于vm001、vm002、vm003、vm004，导致在RECOVERING过程中有时候网络抖动也会导致MISSING状态。我们使用cluster.rejoinInstance('root@vm001')几次后肯定能ONLINE。所以我一开始了rejoin了好几次，但是均失败了，这个时候我肯定不是我先前遇到过的那种情况。

这个时候我们打开MySQL的error log. 我们可以看到以下信息：

里面有几行引起了我的注意：

[ERROR] [MY-011574] [Repl] Plugin group_replication reported: 'Maximum number of retries when trying to connect to a donor reached. Aborting group replication recovery.'

这一句告知我们为什么每次RECOVERING一段时间之后就会变成MISSING状态，因为RECOVERING过程根本就没有完成，一开始连接建立时就已经失败了。

[ERROR] [MY-010584] [Repl] Slave I/O for channel 'group_replication_recovery': error connecting to master 'mysql_innodb_cluster_r1719717232@vm000:3306' - retry-time: 60 retries: 1, Error_code: MY-001045

我们可以通过这个猜测vm001连接vm000的过程出现了问题。

[ERROR] [MY-011582] [Repl] Plugin group_replication reported: 'There was an error when connecting to the donor server. Pleasecheck that group_replication_recovery channel credentials and all MEMBER_HOST column values of performance_schema.replication_group_members table are correct and DNS resolvable.'

这一行报错帮我们推测了两种可能：DNS出现问题。这个时候我在每台机器上ping了整个cluster的每一台server，均是正常响应。所以排除DNS问题。

group_replication_recovery channel credentials 这个困扰到我了，我一直不知道Group Replication 通信过程还有使用什么证书之类的东西。后面在mysql community 的 slack跟MySQL 的开发者 lefred交流后才知道问题确实时出现在这里(此处要感谢lefred耐心的指导)。

所以到这里，根据报错信息我们可以推断在cluster的机器在突然宕机的情况下，可能会造成一些credentials丢失，导致在建立replication recovery channel 失败。导致我们rejoin的时候出现总是从RECOVERING转换到MISSING的问题。

解决问题

那我们如何解决这个问题？因为现在大部分server处于MISSING，导致我们没有办法使用cluster.removeInstance('root@vm001')，因为Paxos需要超过一半以上的server来投票。这样直接remove会报错。

在这种情况下，我们可以通过以下方法来解决：MySQL JS> cluster.removeInstance('root@vm001'， {force: true})

MySQL JS>cluster.addInstance('root@vm001')

通过这个方法，cluster会自动更新相关的credentials信息，这样cluster内部的server就可以建立连接。

最终vm001可以重新ONLINE。vm002、vm003、vm004按照同样的解决方案操作一遍就可以解决问题，让整个cluster重新全部ONLINE。

对于credentials究竟是什么，建立replication recovery channel的过程中，这个credentials是怎么用的？我还没有弄清楚。如果有大佬已经知道了，还麻烦告诉我一声，万分感谢。