技术栈

writeconcern

ly7689
18 天前
数据库·mongodb·writeconcern·readconcern·readpreference·因果一致性
MongoDB 读写策略与一致性取舍:readConcern、readPreference 与 causal session先看一个非常常见的线上现象。用户在页面点“下单”,接口返回成功,页面立刻跳转到订单详情,结果提示“订单不存在”;刷新两秒后又出现了。开发同学第一反应往往是“MongoDB 丢数据了”,于是去查 writeConcern,发现已经是 majority;再查日志,写入确实成功,只是详情页读到的是一台还没同步到这条数据的从节点。问题不在写,而在读与写的路径没有对齐。
ly7689
20 天前
数据库·mongodb·php·mongodb 副本集·选举风暴·journal 刷盘·writeconcern
MongoDB 副本集选举风暴排查:从心跳超时到 Journal 刷盘阻塞假设你负责一套三节点的 MongoDB 副本集,主节点负责所有写入,两个从节点做复制和读扩展。某天业务晚高峰,监控上出现一组奇怪的信号:应用抛出大量写超时异常,日志里反复出现“not master”和“operation exceeded time limit”;同时 MongoDB 的 PRIMARY 状态在几十秒内切换了三四次,rs.status() 里每个节点的 electionDate 频繁刷新。你第一反应可能是网络抖动,于是去查交换机、查带宽、查跨机房延迟,结果发现网络指标正常,CPU 也不高,
我是有底线的