首页
学习
活动
专区
工具
TVP
发布

一次MongoDB故障的复盘

前段时间笔者的客户遇到了一个主从延迟导致的业务故障故障的原因本来是较为简单易查的,但是由于客户环境的安全、保密性要求,监控和指标只能间接获知,信息比较片段化与迟缓。...当时涉及到了主从延迟,慢查询,cursor的不当使用等mongodb问题,本文将从这几个方面全面复盘整个故障的排查过程,其中包含了如下内容: 背景(简单介绍背景情况) 临时应对与考量(该情况下快速恢复业务的选择...根据已有信息初步判断故障原因可能为“主从延迟”导致的数据一致性问题。...回归到此次故障的场景,虽然db.printSlaveReplicationInfo()存在不准确的可能,但是以当时的pqs情况来判断,应该是真实出现了主从延迟。...end / 作者简介 / 周李洋(eshujiushiwo): Teambition运维负责人 MongoDB Master MongoDB中文社区联席主席 MongoDB上海用户组发起人 MongoDB

1.2K20
您找到你想要的搜索结果了吗?
是的
没有找到

(2)MongoDB副本集自动故障转移原理(含客户端)

前文我们搭建MongoDB三成员副本集,了解集群基本特性,今天我们围绕下图聊一聊背后的细节。 ? 默认搭建的副本集均在主节点读写,辅助节点冗余部署,形成高可用和备份,具备自动故障转移能力。...在发生故障转移时,集群不能再执行写入操作;若客户端配置在辅助节点读取(read preference),则集群可继续提供读取能力。 你的应用程序可用重试逻辑应对自动故障转移和后续的重选。...从MongoDB3.6版本开始,MongoDB Driver可侦测主节点的失联,并执行一次重试操作。...mongodb://account:passward@mongodb0.example.com:27017,mongodb1.example.com:27017,mongodb2.example.com...replicaSet=rs0 OK, 以上便是MongoDB副本集心跳保活、异步复制、自动故障转移的背景知识。 留一个作业?

1.8K10

MongoDB特定场景性能数十倍提升优化实践(记一次MongoDB核心集群雪崩故障)

问题背景 某核心JAVA长连接服务使用MongoDB作为主要存储,客户端数百台机器连接同一MongoDB集群,短期内出现多次性能抖动问题,此外,还出现一次“雪崩”故障,同时流量瞬间跌零,无法自动恢复。...本文分析这两次故障的根本原因,包括客户端配置使用不合理、MongoDB内核链接认证不合理、代理配置不全等一系列问题,最终经过多方努力确定问题根源。...因此,分析反复建链断链为何引起系统sy%负载100%就成为了本故障的关键点。 2.3.1 模拟故障过程 模拟频繁建链断链故障步骤如下: 1....2.3.2 故障模拟测试结果 为了保证和故障的mongos代理硬件环境一致,因此选择故障同样类型的服务器,并且操作系统版本一样(2.6.32-642.el6.x86_64),程序都跑起来后,问题立马浮现...问题总结及疑问解答 从上面的分析可以看出,该故障由多种因素连环触发引起,包括客户端配置使用不当、MongoDB服务端内核极端情况异常缺陷、监控不全等。总结如下: 1.

1K20

MongoDB副本集(一主两从)读写分离、故障转移功能环境部署记录

(在另一个副本节点172.16.60.207也如上操作即可) 四、测试副本集故障转移功能 先停掉主节点172.16.60.205,查看mongodb副本集状态,可以看到经过一系列的投票选择操作,172.16.60.206...1)停掉原来的主节点172.16.60.205的mongodb,模拟故障 [root@mongodb-master01 ~]# ps -ef|grep mongodb|grep -v grep|awk..."keyId" : NumberLong(0) } } } 发现原来的主节点172.16.60.205在故障恢复后...Mongodb副本集可以完美支持故障转移。至于主节点的读写压力过大如何解决?常见的解决方案是读写分离。...基于这个问题,Mongodb已有了相应的解决方案 - 引用仲裁节点: 在Mongodb副本集中,仲裁节点不存储数据,只是负责故障转移的群体投票,这样就少了数据复制的压力。

1.9K40

故障分析 | cassandra 集群数据故障转移

---一、前情提要:我们知道 cassandra 具有分区容错性和强一致性,但是当数据所在主机发生故障时,该主机对应的数据副本该何去何从呢?是否跟宿主机一样变得不可用呢?...测试并查看集群中出现故障节点后的数据分布情况:94机器关闭服务:systemctl stop cassandra[cassandra@data01 ~]$ nodetool statusDatacenter...,因此可以看到,在 dc1 数据中心中,数据随机仍只分布在其中三个节点上,而 dc2 数据中心的数据将分布在了仅有的三个节点上,发生了数据转移;如果此时 dc2 数据中心还有节点继续故障,那么故障节点上的数据不可能再移动到其他节点上了...,dc1 是不变的,owns 还是300% ,但是 dc2 的 owns都是100% ,没办法故障转移了,只能存在自身的数据了;此时重启所有主机,所有主机 Cassandra 服务都会开启,包括之前故障模拟的节点也会自启...,那么此时就会达到了另一种效果:故障模拟节点后的状态,再添加到了集群中,那么此时数据又会进行了自动的分发。

1.2K20

事中故障处理(4)故障定位

故障恢复指恢复业务连续性的应急操作,很多故障是在不断尝试验证解决恢复的动作,所以故障恢复环节与故障定位环节有一定的交叠,或在这两个环节之间不断试错的循环,即故障恢复操作可能和故障诊断是同时,也可能是诊断之后或诊断之前...1.已知预案下的恢复三把斧 在故障管理过程中,通常大部分故障有一些明确的故障恢复预案,比如基础设施、服务器、网络设备、网络线路,以及应用系统层中关于服务可用性等故障因素,以及基于历史故障经验积累的方案。...以一个复杂故障应急场景中,很多时候故障处置的决策人员通常一方面协调人员现场分析问题,另一方面指挥启动已知预案的应急。...、数据完整性的故障恢复,这些故障恢复通常需要现场临时决断恢复。...结束 注:“3.4 事中处置”另外3个环节内容链接: 1.故障发现、故障响应 2.故障定位

1.3K30

mongodb 集合_mongodb原理

数据模式简单而强大) 动态查询 全索引支持,扩展到内部对象和内嵌数组 查询记录分析 快速,就地更新 高效存储二进制大对象 (比如照片和视频) 复制和故障切换支持 Auto...不可靠环境保证高可用性 设置副本集(主-从服务器设置)不仅方便而且很快,此外,使用MongoDB还可以快速、安全及自动化的实现节点(或数据中心)故障转移。...而在其他数据库产品中想实现以上功能,往往需要额外安装复杂的中间件,大大提升了系统复杂度,故障排查难度和运维成本。...5 故障处理 使用MongoDB云数据库,当DB所在的物理机出现硬件故障或者DB本身出现性能问题,云计算厂商往往具备非常丰富的故障处理经验,可保障在最短的时间内恢复服务。...另外,虽然云数据库虽然禁止客户登陆DB所在的物理机,不过一般云计算厂商比如UCloud可以提供错误日志下载等功能,方便客户去定位故障原因。

1.9K40

3.4 事中故障处理(3)故障定位

故障定位指诊断故障直接原因或根因,故障定位有助于故障恢复动作更加有效。故障定位通常是整个故障过程中耗时最长的环节,定位的目标围绕在快速恢复的基础上,而非寻找问题根因,后者由问题管理负责。...通常大部分可用性故障,要借助运维专家经验的假设判断或已知预案的执行得到解决,但仍有部分故障,尤其是性能、应用逻辑、数据故障需要多方协同与工具支持。...判断应用逻辑层面的异常,比如功能、菜单级别的故障,如何更加主动、从容的找到逻辑上的故障点,并作出应急。...应用逻辑故障的问题定位与“故障传染”场景类似,如何在大量病态的功能中找到根因功能,并对功能进行降级等恢复是难点。...如果运维知识图谱准确性有保证,可以预见还能够支持数据源/指标/文本异常检测、基于人工故障库/数据挖掘的故障诊断、故障预测、故障自愈、 成本优化、资源优化、容量规划、性能优化等场景。

1.3K20

故障改进

当你解决故障的时候,一定要防止对方对问题提前下结论,如果对方局部的证明是能证明结论是正确的,那从全局来看呢?不要在二手信息上深入讨论,不要用二手信息作为重要依据。...那从整体来看,需要怎么故障改进? 第一,优化故障获知和故障定位的时间。 从故障发生到我们知道的时间是否可以优化得更短? 定位故障的时间是否可以更短? 有哪些地方可以做到自动化?...第二,优化故障的处理方式。 故障处理时的判断和章法是否科学,是否正确? 故障处理时的信息是否全透明? 故障处理时人员是否安排得当? 第三,优化开发过程中的问题。...做个简短的总结:循序渐进的让故障定位时间变短,持续改善,不要出现好像又是人品的问题,莫名的日了狗,不存在的,归根结底是自己的基础理论修养不够。关于严谨程度,是工程师很重要的品质。

57520
领券