不发碎碎念了，唠叨那些没啥意思，重回『叶问』正轨。
1. 三节点的MGR集群关掉两个节点后还能继续读写吗
这里要先明确一个前提，两个节点是正常关闭MGR服务，还是异常宕机。
如果两个节点是手动执行 stop group_replication 关闭的话，那仅剩的一个节点（会成为PRIMARY节点）是可以正常读写的，只不过这是MGR集群没任何容错能力了（想想MGR集群刚启动第一个节点时的场景...）。
但如果两个节点是异常宕机导致离开集群的话，那么相当于MGR里的多数派（两个节点）缺失了，只剩下少数派（一个节点），此时就无法提供读写服务了，类似下面这种情况：
root@GreatSQL> select * from performance_schema.replication_group_members; +---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | +---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+ | group_replication_applier | 99999999-9999-9999-9999-99999999999a | yejr-mgr4 | 3306 | ONLINE | PRIMARY | 8.0.25 | | group_replication_applier | 99999999-9999-9999-9999-99999999999b | yejr-mgr3 | 3306 | UNREACHABLE | SECONDARY | 8.0.25 | | group_replication_applier | 99999999-9999-9999-9999-99999999999c | yejr-mgr2 | 3306 | UNREACHABLE | SECONDARY | 8.0.25 | +---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
这时候就要通过设置 group_replication_force_members 选项，去掉异常的两个节点，然后再将这两个节点的MGR服务重启，没其他异常的话即可自行重新加入集群。这部分内容可以回顾这个视频：MGR集群管理及节点异常处理，节点异常退出后重新加入。
P.S，如果前端挂着MySQL Router，则三节点的MGR集群中意外宕机两个节点后，这时会发出报错：
"statusText": "Cluster has no quorum as visible from 'yejr-mgr4:3306' and cannot process write transactions. 2 members are not active.",
然后MySQL Router完全不可提供服务，无论是读写端口还是只读端口，都不行。
2. 三节点同时挂了，会自动选新主吗
问题：想一个极端的情况，对MGR不是很熟悉，就是如果三个节点都offline 了，（反正不能用了）都让三个节点重启一下，这三个之间会自动选择一个master出来吗。
回答：这种情况下，相当于整个集群所有节点都离线了。这时候，需要将第一个加入集群的节点设置为引导模式：
root@GreatSQL> SET GLOBAL group_replication_bootstrap_group=ON;
再启动MGR服务（启动完成后记得将该选项改回 OFF）。
特别提醒：其他节点只需直接启动MGR服务即可，而不能执行上述引导节点的操作，否则会又启动（分裂）一个新MGR集群。
3. MGR监控关键点
我一般重点关注MGR的几个状态：
- 等待认证的事务队列
- 等待被apply的事务队列
执行下面的SQL来查看即可：
root@GreatSQL> select MEMBER_ID as id, COUNT_TRANSACTIONS_IN_QUEUE as trx_tobe_verified, COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE as trx_tobe_applied, COUNT_TRANSACTIONS_CHECKED as trx_chkd, COUNT_TRANSACTIONS_REMOTE_APPLIED as trx_done, COUNT_TRANSACTIONS_LOCAL_PROPOSED as proposed from performance_schema.replication_group_member_stats; +--------------------------------------+-------------------+------------------+----------+----------+----------+ | id | trx_tobe_verified | trx_tobe_applied | trx_chkd | trx_done | proposed | +--------------------------------------+-------------------+------------------+----------+----------+----------+ | 4b2b46e2-3b13-11ec-9800-525400fb993a | 0 | 0 | 21384 | 40 | 21349 | | 4b51849b-3b13-11ec-a180-525400e802e2 | 0 | 0 | 21370 | 21374 | 0 | | 4b7b3b88-3b13-11ec-86e9-525400e2078a | 0 | 0 | 21255 | 21255 | 0 | +--------------------------------------+-------------------+------------------+----------+----------+----------+
另外，也关注已获取的事务GTID及本地已执行的GTID之间的差距：
root@GreatSQL> select RECEIVED_TRANSACTION_SET from performance_schema.replication_connection_status union all select variable_value from performance_schema.global_variables where variable_name = 'gtid_executed'; +--------------------------------------------------------------------------------------------------------+ | RECEIVED_TRANSACTION_SET | +--------------------------------------------------------------------------------------------------------+ | 1c293e90-3bdc-11ec-bca1-525400e2078a:1-3822271:4800902-4800919, 4b7b3b88-3b13-11ec-86e9-525400e2078a:1 | | | | 1c293e90-3bdc-11ec-bca1-525400e2078a:1-3822271:4800902-4800919, 4b7b3b88-3b13-11ec-86e9-525400e2078a:1 | +--------------------------------------------------------------------------------------------------------+
Enjoy MySQL :)
