MGR整个集群挂掉后，如能才能自动选主，不用手动干预
当集群中所有节点都宕机后，集群再次启动后，能否自动选主？
1、所有节点都宕机后，集群重启，能否自动选主和启动
这是个来自群友的问题。
首先，MySQL服务利用 systemd 即可实现故障后自启动，注意下面这个配置即可：
[root@GreatSQL ~]# cat /usr/lib/systemd/system/greatsql.service
...
Restart=on-failure
其次，mysqld进程启动后，想要实现MGR的自动选主及自启动也是可以的，利用MySQL Shell即可，例如：
[root@GreatSQL ~]# mysqlsh --uri greatsql@yejr-mgr3:3306
...
-- 不管干啥，都先看 help，这是玩转Linux的必备素养，啥事不清楚都先找男人（man）
-- 注意到有这样的一个方法 rebootClusterFromCompleteOutage()，看起来没跑了
MySQL yejr-mgr3:3306 ssl JS > \help dba
rebootClusterFromCompleteOutage([clusterName][, options])
Brings a cluster back ONLINE when all members are OFFLINE.
-- 跑一个试试看
MySQL yejr-mgr3:3306 ssl JS > dba.rebootClusterFromCompleteOutage()
Restoring the default cluster from complete outage...
The instance 'yejr-mgr4:3306' was part of the cluster configuration.
Would you like to rejoin it to the cluster? [y/N]: y
The instance 'yejr-mgr2:3306' was part of the cluster configuration.
Would you like to rejoin it to the cluster? [y/N]: y
Dba.rebootClusterFromCompleteOutage: The active session instance (yejr-mgr3:3306) isn't the most updated in comparison with the ONLINE instances of the Cluster's metadata. Please use the most up to date instance: 'yejr-mgr4:3306'. (RuntimeError)
可以看到错误信息提示我们当前节点上没有最新的数据，不能直接启动MGR，错误信息中还提供了该去哪个节点启动的建议，所以我们改成在 yejr-mgr4 节点上执行拉起MGR：
[root@GreatSQL ~]# mysqlsh --uri greatsql@yejr-mgr3:3306
...
MySQL yejr-mgr4:3306 ssl JS > dba.rebootClusterFromCompleteOutage()
Restoring the default cluster from complete outage...
The instance 'yejr-mgr3:3306' was part of the cluster configuration.
Would you like to rejoin it to the cluster? [y/N]: y
The instance 'yejr-mgr2:3306' was part of the cluster configuration.
Would you like to rejoin it to the cluster? [y/N]: y
yejr-mgr4:3306 was restored.
Rejoining 'yejr-mgr3:3306' to the cluster.
Rejoining instance 'yejr-mgr3:3306' to cluster 'GreatSQLMGR'...
The instance 'yejr-mgr3:3306' was successfully rejoined to the cluster.
Rejoining 'yejr-mgr2:3306' to the cluster.
Rejoining instance 'yejr-mgr2:3306' to cluster 'GreatSQLMGR'...
The instance 'yejr-mgr2:3306' was successfully rejoined to the cluster.
The cluster was successfully rebooted.
可以看到，MGR集群已经被正常启动了。
上面是利用MySQL Shell启动一个发生过故障的MGR集群，如果是手动的话该怎么办呢？
首先，在各个节点执行下面的SQL，确认各节点当前的事务执行情况：
-- yejr-mgr2节点
root@GreatSQL [none]> select RECEIVED_TRANSACTION_SET from performance_schema.replication_connection_status where
channel_name = 'group_replication_applier' union all
select variable_value from performance_schema.global_variables where
variable_name = 'gtid_executed'\G
*************************** 1. row ***************************
RECEIVED_TRANSACTION_SET:
*************************** 2. row ***************************
RECEIVED_TRANSACTION_SET: 1c293e90-3bdc-11ec-bca1-525400e2078a:1-4537605,
4b7b3b88-3b13-11ec-86e9-525400e2078a:1
-- yejr-mgr3节点
...
*************************** 1. row ***************************
RECEIVED_TRANSACTION_SET:
*************************** 2. row ***************************
RECEIVED_TRANSACTION_SET: 1c293e90-3bdc-11ec-bca1-525400e2078a:1-4542304,
4b7b3b88-3b13-11ec-86e9-525400e2078a:1
-- yejr-mgr4节点
...
*************************** 1. row ***************************
RECEIVED_TRANSACTION_SET:
*************************** 2. row ***************************
RECEIVED_TRANSACTION_SET: 1c293e90-3bdc-11ec-bca1-525400e2078a:1-4652391,
4b7b3b88-3b13-11ec-86e9-525400e2078a:1
从上面的结果可以看到，yejr-mgr4 节点上已执行完的事务GTID值最大：4652391 > 4542304 > 4537605，因此应该选择 yejr-mgr4 节点作为 Primary 节点。
将该节点设置为引导模式，然后启动MGR服务：
[root@GreatSQL ~]# mysql -hyejr-mgr4 -P3306 -ugreatsql -p
...
greatsql@mgr4:3306 [(none)]>set global group_replication_bootstrap_group=ON;
greatsql@mgr4:3306 [(none)]>start group_replication;
-- 启动完MGR后，记得立即将其设置为OFF
greatsql@mgr4:3306 [(none)]>set global group_replication_bootstrap_group=OFF;
在其他节点上，则直接启动MGR服务即可，切记无需再次设置引导模式，否则它就会变成一个全新的MGR集群的Primary节点了。
好了，自动、手动两种方式拉起一个故障MGR集群方法都介绍完毕了。
Enjoy GreatSQL :)