网络分区引发的 oplog 乱序问题
OplogOutOfOrder problem线上一个Secondary节点crash，错误原因是出现了 OplogOutOfOrder 错误，也就是说Secondary 重放了一条比『已经重放过最新的 oplog』更早的操作，经过分析，发现问题是因网络分区导致出现2个 Primary 的问题导致，详细的过程如下表分析。说明：Node2、Node1、Node0分别是优先级为2、1、0的复制集成员。TIMESTAMPNODE2NODE1NODE0NOTES
t1PrimarySecondarySecondaryNode2被选为主
t2Primary write ASeconary sync ASecondary sync ANode2上写入A，并同步到 Node1、Node0
t3Primary write BSecondarySecondaryNode2上写入 B，但未同步到 Node1、Node0
t4PrimarySecondarySecondaryNode2网络与 Node1、Node0隔离，发生新的选举
t5PrimaryPrimarySecondaryNode1被选为主
t6PrimaryPrimary WRITE CSecondary SYNC CNode1上写入 C，同步到 Node0
t7PrimaryPrimary WRITE DSecondary SYNC DNode1上写入 D，同步到 Node0
t8Primary Write EPrimarySecondaryNode2上写入 E, a实际上是一个耗时很长的建索引操作结束
t9SecondaryPrimarySecondarynetwork recovered, Node1发现 Node2的选举时间戳更早，请求Node2降级
t10SecondarySecondarySecondaryNode1发现 Node2优先级更高，并且oplog 足够，主动降级
t11PrimarySecondarySecondaryNode2赢得新的选举
t12PriamrySecondarySecondaryNode1 Node0 从 Node2同步，先回滚 C D
t13PrimarySecondarySecondaryNode1从 Node2 同步 B E
t14PrimarySecondarySecondaryNode0从 Node2 同步 B E ，因为 Node0已经同步过 C D，时间戳比 B 更新，触发oplogOutOfOrder 错误 crash
上述问题也提给了MongoDB 官方团队，参考https://jira.mongodb.org/browse/SERVER-25838，这个问题在『3.0及以前的版本』或『使用 protocol version 为0的3.2版本』都有可能发生，但几率很小，使用 MongoDB 的同学不用担心，我们也是因为MongoDB云数据库 用户比较多，才触发了一例；MongoDB 3.2引入了 raft 协议，避免了上述场景发生，遇到类似问题的用户可以升级到 MongoDB-3.2，并使用复制集协议protocoal version 1。
页:
[1]