共计 1494 个字符,预计需要花费 4 分钟才能阅读完成。
MySQL Shell 无奈拉起 MGR 集群解决办法
用 MySQL Shell 要从新拉起一个 MGR 集群时,可能会提醒上面的错误信息:
Dba.rebootClusterFromCompleteOutage: Unable to get an InnoDB cluster handle. The instance '172.16.130.197:3306' may belong to a different cluster from the one registered in the Metadata since the value of 'group_replication_group_name' does not match the one registered in the Metadata: possible split-brain scenario. Please retry while connected to another member of the cluster. (RuntimeError)
意思是该节点属于其余 MGR 集群(从元数据读取到的 group_replication_group_name
值判断的),因而不能间接拉起。
这种谬误常见于 MySQL 5.7 版本构建的 MGR 集群环境下,如果是运行 MySQL 8.0 的话则个别很少见。
之所以会这样,是因为 MySQL 5.7 中还不反对 SET PERSIST 性能。
在 MySQL 8.0 中,用 MySQL Shell 构建 MGR 集群时,会随机生成一个 UUID 作为 group_replication_group_name,并以 SET PERSIST 的形式长久化(保留到 mysqld-auto.cnf
文件中),实例重启时还能持续读取。
而在 MySQL 5.7 中,因为没有这个性能,实例重启时还会从原来的 my.cnf
中读取旧的 group_replication_group_name 值,导致被判断为该节点属于另一个集群。
当初曾经晓得问题的起因了,解决办法也简略。
- 获取正确的 group_replication_group_name。
实例重启实现后,读取mysql_innodb_cluster_metadata.clusters
这个元数据表,获取正确的 group name。
mysql> select attributes->'$.group_replication_group_name' from clusters;
+----------------------------------------------+
| attributes->'$.group_replication_group_name' |
+----------------------------------------------+
| "bc664a9b-9b5b-11ec-8a73-525400c5601a" |
+----------------------------------------------+
- 在每个节点上手动批改 group_replication_group_name。
mysql> set global group_replication_group_name = "bc664a9b...";
- 再次执行
dba.rebootClusterFromCompleteOutage()
就行了。
MySQL 172.16.130.197:3306 ssl JS > dba.rebootClusterFromCompleteOutage()
Restoring the default cluster from complete outage...
Enjoy GreatSQL :)
本文由博客一文多发平台 OpenWrite 公布!
正文完