MongoDB集群中的一个典型的错误

1.案例

(1)现象:主备节点中,发生了切换,且原来的主节点mongo服务宕掉,且不能重新启动,检查了是不是防火墙和网路导致的,结果不是。

(2)从日志来看,报错信息如下:

部分粘贴:

复制代码
{"t":{"$date":"2024-12-16T14:11:50.300+08:00"},"s":"I",  "c":"ROLLBACK", "id":21611,   "ctx":"BackgroundSync","msg":"Transition to SECONDARY"}
{"t":{"$date":"2024-12-16T14:11:50.300+08:00"},"s":"I",  "c":"REPL",     "id":21358,   "ctx":"BackgroundSync","msg":"Replica set state transition","attr":{"newState":"SECONDARY","oldState":"ROLLBACK"}}
{"t":{"$date":"2024-12-16T14:11:50.300+08:00"},"s":"I",  "c":"REPL",     "id":21106,   "ctx":"BackgroundSync","msg":"Resetting sync source to empty","attr":{"previousSyncSource":"192.168.32.217:27017"}}
{"t":{"$date":"2024-12-16T14:11:50.300+08:00"},"s":"F",  "c":"REPL",     "id":21128,   "ctx":"BackgroundSync","msg":"Rollback failed with unrecoverable error","attr":{"error":{"code":127,"codeName":"UnrecoverableRollbackError","errmsg":"not willing to roll back more than 86400 seconds of data. Have: 226356 seconds."}}}
{"t":{"$date":"2024-12-16T14:11:50.300+08:00"},"s":"F",  "c":"-",        "id":23095,   "ctx":"BackgroundSync","msg":"Fatal assertion","attr":{"msgid":50666,"error":"UnrecoverableRollbackError: not willing to roll back more than 86400 seconds of data. Have: 226356 seconds.","file":"src/mongo/db/repl/bgsync.cpp","line":807}}
{"t":{"$date":"2024-12-16T14:11:50.300+08:00"},"s":"F",  "c":"-",        "id":23096,   "ctx":"BackgroundSync","msg":"\n\n***aborting after fassert() failure\n\n"}

2.原因

发现该错误是,主备节点数据不同步的一种表现:

这个错误信息来自MongoDB的复制集(replica set)环境,具体涉及到背景同步(BackgroundSync)过程。错误指出在尝试回滚数据时遇到了问题,因为它不愿意回滚超过86400秒(即24小时)的数据,但当前需要回滚的数据量已经达到了226356秒,远远超过了限制。

(1)原因1:回滚时间过长:MongoDB复制集中的从节点(secondary)在某些情况下(如网络分区、长时间离线后重新加入等)需要回滚(rollback)以保持一致性。这里的错误表明需要回滚的时间过长,超出了MongoDB预设的安全限制。

(2)原因2:预设限制:MongoDB默认设置了最大回滚时间为24小时(86400秒),这是为了防止在极端情况下从节点与主节点(primary)之间的差异过大,导致回滚操作过于复杂和耗时,进而影响系统的稳定性和性能。

3.解决办法

解决办法1:改大回滚时间则可;但是不建议这种方法,这种方法是在实在没有其他的解决办法的情况下紧急使用一下。

解决办法2:可以将正常的mongo机器中的数据传输到宕机的那一台的存放数据文件的文件夹中即可。再进行重启后发现集群状态正常。

各节点状态:

注意:我宕机的那一台的数据文件我也进行了备份存放到了其他的地方,万一恢复过程中有问题,需要用到的话,可以有仍有余。

相关推荐
踏月的造梦星球6 小时前
DMDPC 学习:架构、部署、运维与调优
运维·数据库·学习·架构
韩楚风6 小时前
【参天引擎】事务生命周期 / MVCC / Undo / ACID / 分布式事务 功能域整体解析
数据库·分布式·mysql·架构·cantian
renhongxia17 小时前
世界模型,是“空中楼阁”还是AGI的“最后一块拼图”?
运维·服务器·数据库·人工智能·算法·agi
程序员无隅7 小时前
Coding Agent 为什么压缩上下文后还能继续工作?上下文模块设计拆解
java·开发语言·数据库
愿做无知一猿7 小时前
Nacos连接MySQL异常?DataGrip竟成救星
数据库·mysql
G.O.G.O.G7 小时前
LeetCode SQL 从入门到精通(MySQL)06(上)
数据库·sql·mysql·leetcode
研究员子楚8 小时前
GEO行业发展标准体系白皮书V2.0-第10卷 · 全球篇:跨国标准协同与全球品牌语义治理框架
数据库·人工智能·microsoft·架构·geo
Omics Pro9 小时前
深度学习多组学互作:组内+组间
数据库·人工智能·深度学习·mysql·搜索引擎·自然语言处理
残*影10 小时前
如何优雅地保存MySQL数据变更历史?
数据库·mysql
乐观的Terry10 小时前
3、数据库设计与领域实体
java·数据库·spring boot·spring cloud·ai编程