前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >《叶问》37期,三节点的MGR集群关掉两个节点后还能继续读写吗

《叶问》37期,三节点的MGR集群关掉两个节点后还能继续读写吗

作者头像
老叶茶馆
发布2021-11-23 15:30:24
7210
发布2021-11-23 15:30:24
举报

1. 三节点的MGR集群关掉两个节点后还能继续读写吗

这里要先明确一个前提,两个节点是正常关闭MGR服务,还是异常宕机。

如果两个节点是手动执行 stop group_replication 关闭的话,那仅剩的一个节点(会成为PRIMARY节点)是可以正常读写的,只不过这是MGR集群没任何容错能力了(想想MGR集群刚启动第一个节点时的场景...)。

但如果两个节点是异常宕机导致离开集群的话,那么相当于MGR里的多数派(两个节点)缺失了,只剩下少数派(一个节点),此时就无法提供读写服务了,类似下面这种情况:

代码语言:javascript
复制
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集群中意外宕机两个节点后,这时会发出报错:

代码语言:javascript
复制
"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出来吗。

回答:这种情况下,相当于整个集群所有节点都离线了。这时候,需要将第一个加入集群的节点设置为引导模式:

代码语言:javascript
复制
root@GreatSQL> SET GLOBAL group_replication_bootstrap_group=ON;

再启动MGR服务(启动完成后记得将该选项改回 OFF)。

特别提醒:其他节点只需直接启动MGR服务即可,而不能执行上述引导节点的操作,否则会又启动(分裂)一个新MGR集群。

3. MGR监控关键点

我一般重点关注MGR的几个状态:

  1. 等待认证的事务队列
  2. 等待被apply的事务队列 执行下面的SQL来查看即可:
代码语言:javascript
复制
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之间的差距:

代码语言:javascript
复制
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 :)

《实战MGR》视频课程

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2021-11-21,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 老叶茶馆 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 1. 三节点的MGR集群关掉两个节点后还能继续读写吗
    • 2. 三节点同时挂了,会自动选新主吗
      • 3. MGR监控关键点
      相关产品与服务
      云数据库 SQL Server
      腾讯云数据库 SQL Server (TencentDB for SQL Server)是业界最常用的商用数据库之一,对基于 Windows 架构的应用程序具有完美的支持。TencentDB for SQL Server 拥有微软正版授权,可持续为用户提供最新的功能,避免未授权使用软件的风险。具有即开即用、稳定可靠、安全运行、弹性扩缩等特点。
      领券
      问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档