2020-12-08
mysql mgr 一节点状态始终是RECOVERING,但是同步正常
环境
mgrb01和mgrb02在ubuntu20.4 docker容器上
mgrb03在一个虚拟机上centos 8.2.2004
数据库软件为8.0.22
现象
- mgrb03再加入集群后一直处于RECOVERING状态
root@172.20.3.11:3308 : (none) : 10:54:19>SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 3661b76a-38f7-11eb-9d7a-0242ac1e000a | mgrb01 | 3308 | ONLINE | SECONDARY | 8.0.22 |
| group_replication_applier | 4ced7a3e-38fa-11eb-bcc5-0242ac10000a | mgrb02 | 3308 | ONLINE | PRIMARY | 8.0.22 |
| group_replication_applier | eda990af-1e5c-11eb-9895-00155d011502 | mgrb03 | 3306 | RECOVERING | SECONDARY | 8.0.22 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
复制
- 数据同步正常,mgrb02是primary,上面的一切操作都同步到mgrb03了,show master status看到的Executed_Gtid_Set都是一致的
- mgrb03的error日志中没有报错,其余两节点error日志也没报错
- 主动将master角色的mgrb02停止后,mgrb03的状态变为online
- 对比了下日志,发下mgrb03刚加入组的时候日志中少了一句:This server was declared online within the replication group,此时才出现这个日志
2020-12-08T03:03:45.197782Z 0 [Warning] [MY-011499] [Repl] Plugin group_replication reported: 'Members removed from the group: mgrb02:3308' 2020-12-08T03:03:45.197800Z 0 [System] [MY-011500] [Repl] Plugin group_replication reported: 'Primary server with address mgrb02:3308 left the group. Electing new Primary.' 2020-12-08T03:03:45.197883Z 0 [System] [MY-011507] [Repl] Plugin group_replication reported: 'A new primary with address mgrb01:3308 was elected. The new primary will execute all previous group transactions before allowing writes.' 2020-12-08T03:03:45.198100Z 0 [System] [MY-011503] [Repl] Plugin group_replication reported: 'Group membership changed to mgrb01:3308, mgrb03:3306 on view 16073947051824521:6.' 2020-12-08T03:03:45.198962Z 0 [System] [MY-011490] [Repl] Plugin group_replication reported: 'This server was declared online within the replication group.' 2020-12-08T03:03:46.916812Z 36 [System] [MY-011511] [Repl] Plugin group_replication reported: 'This server is working as secondary member with primary member address mgrb01:3308.'
复制
我来答
添加附件
收藏
分享
问题补充
6条回答
默认
最新
回答交流
Markdown
请输入正文
提交
相关推荐
mysql中有子事务吗?
回答 1
好像没有这个概念
mysql8.0 如何删除系统库
回答 4
既然是恢复的话,直接删表就可以啊.本来逻辑备份恢复就是这个原理…注:8.0的统计信息表不会被删除.直接更新即可.sys下面的是视图,就当作普通库就行.
mysql 5.6.39数据库无法启动还有救吗?
回答 5
如果mysql实例都无法启动的话,确实是怀疑表空间已经损坏了。建议备份数据目录和日志目录,通过修复表空间的方式恢复。
如何检查mysql数据库的数据准确性语句是什么?
回答 1
checksum是不是你要的?
mysql查询百万条数据耗时太高,有什么优化的方法吗?
回答 3
已采纳
1、建索引2、优化sql,用上索引3、机械盘换ssd,加快io4、加大内存参数,缓存更多的表
mysql支持手动checkpoint吗?
回答 2
FLUSHNOWRITETOBINLOGENGINELOGS;上面那个命令有类似的作用
MySQL不提供数组,只能做成表吗?
回答 4
已采纳
数据库几乎(没见过有,可能有)都不提供,数据需要在程序中去实现。
针对MySQL 8.0 Group Replication,当一个组成员明显落后于组时会发生什么?
回答 1
已采纳
在默认的配置下,当一个成员明显落后于组时,可能会触发流量控制,进而拖慢整个组。在发生流量控制时并没有能够自动将成员从组中驱逐出组的策略,也并没有相应的系统变量进行配置,但流量控制阈值可以根据需要自行调
MySQL 全文检索,无法完整匹配的问题,怎么解决?
回答 1
MySQL全文检索,表的引擎要是MYISAM,另外语法要正确。
MySQL count有必要做冗余吗?
回答 2
已采纳
不知道我对你的问题理解的对不对,简单说下我的想法,仅供参考:innodb的话没必要count冗余吧,InnoDB支持事务,其中大部分操作都是行级锁,所以可能表的行数可能会被并发修改,那么缓存记录下来的