MySQL Group Replication 节点状态详解
来源:互联网 发布:约瑟夫环java 编辑:程序博客网 时间:2024/06/05 06:21
replication_group_members表
通过查询performance_schema下的replication_group_members表可以知道MGR集群中节点的状态:
mysql> desc performance_schema.replication_group_members;+--------------+----------+------+-----+---------+-------+| Field | Type | Null | Key | Default | Extra |+--------------+----------+------+-----+---------+-------+| CHANNEL_NAME | char(64) | NO | | NULL | || MEMBER_ID | char(36) | NO | | NULL | || MEMBER_HOST | char(60) | NO | | NULL | || MEMBER_PORT | int(11) | YES | | NULL | || MEMBER_STATE | char(64) | NO | | NULL | |+--------------+----------+------+-----+---------+-------+5 rows in set (0.01 sec)
- CHANNEL_NAME : 显示的值永远为group_replication_applier
- MEMBER_ID : 节点serer_uuid
- MEMBER_PORT : 节点服务端口,取值为server_port指定的端口
- MEMBER_HOST : 如果没有配置report_host选项,那么取值为机器的hostname,可以通过report_host配置指定具体的IP
- MEMBER_STATE : 节点状态,取值下一节讨论
MEMBER_STATE取值
MEMBER_STATE字段显示当前节点的状态,根据官方文档,取值和介绍如下所示:
从上表可以知道,只有ONLINE和RECOVERING两种状态会在集群中得到同步。这个状态同步是指状态在所有节点上面查询均能保持一致的意思。至于OFFLINE,ERROR和UNREABLE,做以下说明:
- 只有在当前OFFLINE节点查询replication_group_members表才能得到OFFLINE状态,在其他节点上查询replication_group_members表,则一般没有该节点的状态(很好理解,因为OFFLINE节点已经不属于这个GR组了)
- 只有在当前ERROR节点查询replication_group_members表才能得到ERROR状态,同上面的OFFLINE,在其他节点上查询也看不到该节点
- 假设节点A与B网络通讯失败,那么在节点A上查询replication_group_members表,有可能得到B的状态为UNREACHABLE
那么,从状态是否自身可见或者其他节点可见的角度来区分,有如下区分,
状态对自身可见的有:
- ONLINE
- OFFLINE
- RECOVERING
- ERROR
状态在其他节点上可见的有:
- ONLINE
- RECOVERING
- UNREACHABLE
节点状态转移
当一个节点加进一个GR组,其状态首先变成RECOVERING,表示当前节点正处于集群恢复阶段,这个阶段下,节点会选择集群中一个节点(donor节点),利用传统的异步复制,做recovery。当数据能够成功追平,节点的状态将会变成ONLINE,这个过程中通过其他节点也可以看到该节点的状态,不管是RECOVERING还是最后的ONLINE。
假如该节点在RECOVERING阶段出现了异常(选donor进行复制失败 or 在donor追数据的过程中失败),那么该节点的状态将会变成ERROR,注意,这时候在其他节点上查询时,发现该RECOVERING节点已经从组里面被踢出。
另外,如果一个ONLINE节点失去与其他节点的通讯(可能因为节点crash或者网络异常),则该节点在其他节点上面查询到的状态将会是UNREACHABLE。如果这个UNREACHABLE节点在规定的超时时间内没有恢复过来,那么节点将会被踢出去。这个规定的超时时间是多少呢?下面会讲这个时间在集群失去这个节点是否可用的条件下是不一样的。
可疑的UNREACHABLE状态
前面提到,UNREACHABLE节点在规定的超时时间内如果没有恢复过来,那么节点将会被踢出去。这个规定的超时时间,取决于你集群失去这个节点下还是不是达到可用状态(之前的文章里面强调的2N + 1)。假设失去这个节点,集群仍然可用,那么这个UNREACHABLE的超时时间很短,几乎看不到这个状态;但是,如果失去这个节点后集群马上不可用,那么这个UNREACHABLE节点的超时时间,近似于无线大,将会一直处于UNREACHABLE!
以一个例子来验证:
3节点组成的集群,最开始3个节点均为ONLINE状态:
mysql> select * from performance_schema.replication_group_members;+---------------------------+--------------------------------------+---------------+-------------+--------------+| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |+---------------------------+--------------------------------------+---------------+-------------+--------------+| group_replication_applier | 748703ac-dbcc-11e6-a668-90e2bac5d924 | 10.202.44.215 | 24801 | ONLINE || group_replication_applier | 8f8bc352-2566-11e7-aa5e-d4ae52ab91b3 | 10.202.44.214 | 24801 | ONLINE || group_replication_applier | 9c09340a-e04c-11e6-9916-0024e869a606 | 10.202.44.213 | 24801 | ONLINE |+---------------------------+--------------------------------------+---------------+-------------+--------------+3 rows in set (0.00 sec)
这时候,kill(注意是kill实例而不是正常down实例)掉其中的一个实例(10.202.44.214),通过其他可用节点查询到,那一个kill掉的实例从集群中被踢走了:
mysql> select * from performance_schema.replication_group_members;+---------------------------+--------------------------------------+---------------+-------------+--------------+| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |+---------------------------+--------------------------------------+---------------+-------------+--------------+| group_replication_applier | 748703ac-dbcc-11e6-a668-90e2bac5d924 | 10.202.44.215 | 24801 | ONLINE || group_replication_applier | 9c09340a-e04c-11e6-9916-0024e869a606 | 10.202.44.213 | 24801 | ONLINE |+---------------------------+--------------------------------------+---------------+-------------+--------------+2 rows in set (0.00 sec)
接下来我们再kill掉一个实例(10.202.44.213)
mysql> select * from performance_schema.replication_group_members;+---------------------------+--------------------------------------+---------------+-------------+--------------+| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |+---------------------------+--------------------------------------+---------------+-------------+--------------+| group_replication_applier | 748703ac-dbcc-11e6-a668-90e2bac5d924 | 10.202.44.215 | 24801 | ONLINE || group_replication_applier | 9c09340a-e04c-11e6-9916-0024e869a606 | 10.202.44.213 | 24801 | UNREACHABLE |+---------------------------+--------------------------------------+---------------+-------------+--------------+2 rows in set (0.00 sec)
这个时候,UNREACHABLE状态将一直持续,而且此时,集群不满足2N + 1,集群已经不可用(即使有主节点,主节点也是不可写的)。恢复主节点可写有两种方式:
- 把前面kill掉的一个节点拉起来,加入GR组里面
- 暴力地使用group_replication_force_members参数,强制设置节点组成一个新的GR组(强制剔除UNRECHABLE节点)
- MySQL Group Replication 节点状态详解
- MySQL Group Replication增加节点
- mysql group replication 搭建详解
- MySQL Group Replication 动态添加成员节点
- MySQL Group Replication的RECOVERING状态深度理解
- MySQL Group Replication初测
- MySQL Group Replication 介绍
- MySQL Group Replication实践
- MySQL Group Replication 介绍
- MySQL Group Replication简介
- MySQL Group Replication 介绍
- Mysql Group Replication
- MySQL Group Replication 介绍
- MySQL Group Replication 正式发布
- MySQL Group Replication 技术点
- mysql group replication集群搭建
- MySQL Group Replication调研剖析
- MySQL Group Replication调研剖析
- Django学习2-使用模板
- PAT乙级1062
- 数据结构之栈和队列
- Range Sum Query
- [python爬虫] 招聘信息定时系统 (一).BeautifulSoup爬取信息并存储MySQL
- MySQL Group Replication 节点状态详解
- Shell——输入/输出重定向
- Android解压/重新打包system.img
- Linux内核学习总结
- AngularJS的方法
- 百练_2765八进制小数
- java基础总结16-面向对象12(接口)
- 概率图模型综述——by MIT 林达华博士
- 站点https化教程