注册 登录
  • 欢迎访问"运维那点事",推荐使用Google浏览器访问,可以扫码关注本站的"微信公众号"。
  • 如果您觉得本站对你有帮助,那么可以扫码捐助以帮助本站更好地发展。

MongoDB副本集write concern为majority的坑

MongoDB 彭东稳 5829次浏览 已收录 0个评论

故障现象

一个副本集下四个节点,一个primary,两个Secondary,一个arbiter,其中将一个Secondary关闭后,修改primary节点的密码,这时修改命令会卡住直到超时失败。

故障原因

查看MongoDB的错误日志

可以看到writeconcern为write majority,这种情况下修改密码不符合“大多数”原则。可能是majority在计算时需要符合”大多数数据节点”的需求,包括了仲裁节点,但是如果有仲裁节点存在,因为它无法实际写入数据,所以它却永远站在对立面。

故障复现

准备条件:一个primary,两个Secondary,一个arbiter,并关闭其中一台Secondary

方法1:采用普通写入,比如往一个db写入一条数据,通过设置不同的w值和writeconcern值

这时可以写入成功,是因为w为2表示副本集只要有2个节点写入成功就行,于是返回成功

这时无法写入成功,因为需要写入3个节点,但是arbiter无法写入成功,而其中一个Secondary节点宕了,无法满足。

这时也无法写入成功,因为4个majority其实也就是w为3,无法满足

总结

个人感觉这算是mongodb设计得不够合理的地方,容易引起误解。arbiter在主节点宕机选举新的primary时起到了作用,起到积极主动作用;而在writecern设置为majority后,因为其本身无法写入数据,故一直起到的是消极作用。像这种1主2从1仲裁的情况,如果主节点宕机,那么可以选举出新的主节点;如果1个从节点宕机,当设置为majority时,却无法再写入数据了,虽然数据节点中3个中的2个都是健康的(虽然现网环境下这个arbier完全是多余的,一般不会这么用)

转载:http://blog.csdn.net/cug_jiang126com/article/details/52251312


如果您觉得本站对你有帮助,那么可以支付宝扫码捐助以帮助本站更好地发展,在此谢过。
喜欢 (2)or分享 (0)
关于作者:

您必须 登录 才能发表评论!