本文详细介绍了MongoDB副本集中Primary节点故障后，如何通过选举产生新的Primary节点的过程。主要内容包括不同类型的节点（Primary、Secondary、Arbiter、Passive Node）的角色，OpOrdinal的概念，以及选举过程中的策略，如多数节点存活原则、最大maxLocalOpOrdinal选择等。文章还讨论了votes和priority参数在选举中的影响，并提到了数据丢失和系统短暂不可用的可能性。
Mongodb replica set的主要作用就是保障整个系统的高可用.当primary down掉的时候,secondary可以迎难而上,但是,整个replica set每个参数非常详细的作用,以及primary down机后会发生什么事,这个在mongo的主页上讲的不是特别详细,我以前没有找到相关的资料.今天抽空看找了下相关资料,终于找到这篇文章,也不知道啥时候冒出来的.
总结一下:在replica set里,有四种结点(官方的说法是三种,把secondary,primary认为是同一种Standard node):
- Primary. 负责client的读写.
- Secondary.热备.从Primary的oplog读取操作日志,以便与Primary保持一致.
其实secondary有两种类型: a) normal secondary 随时和Primay保持同步, b) delayed secondary, 延时指定时间和primary保持同步,防止误操作. 话说delayed secondary 其实在实际中作用真的不是很大,一般情况都不太愿意浪费机器去做这个事,延时的时间也不好定,定短了,来不及反应,定长了嘛,要注意primary的oplog size要保证在这个延时的时间段内可以保存所有的操作日志.事实上用incremental back up 也可以很好的解决误操作的问题,但是怎么incremental back up其实也不是个简单的事.本质上和使用delayed secondary + replay oplog from primary上区别不大,只是incremental back 会比delayed secondary更加灵活 - Arbiter
最低0.47元/天 解锁文章
扫一扫
617
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
