mongoDB pair replication [ two master when remote unreachable ]

简介:
测试环境如图:
使用对外连接的网卡作为心跳网卡,VIP作为与外部应用服务器通信的端口。

mongoDB pair replication [ two master when remote unreachable ] - 德哥@Digoal - The Heart,The World.

当比较神奇的现象出现的时候,假设这两台服务器不通了,但是和外面的应用服务器已经交换机是通的。正常情况下mongoDB会选出新的primary(下面用iptables来模拟)
如下图,A机和B机都变成primary了,
在mongo shell中的表现:
A(原来的primary)机器:
经过一段时间之后(约20秒)
> db.isMaster()
{
        "ismaster" : 1,
        "remote" : "192.168.169.90:5281",
        "info" : "remote unreachable",
        "ok" : 1
}
B机器:
经过一段时间之后(约20秒)
> db.isMaster()
{
        "ismaster" : 1,
        "remote" : "192.168.169.90:5281",
        "info" : "remote unreachable",
        "ok" : 1
}
对于VIP的漂移来说,判断对方不可达了就启VIP。当然你可以选择另外的心跳(比如串口),这里是模拟两台都primary了后面会怎么样?
那么在交换机上192.168.169.99的mac地址会不断的被这两台mongodb服务器刷新成自己的MAC。
应用程序幸运的话可能会对两个数据库都有写入操作.
模拟:
A机器写入数据:
> db.tbl_test.insert({"id" : "a"})
> db.tbl_test.insert({"id" : "a"})
> db.tbl_test.insert({"id" : "a"})
> db.tbl_test.insert({"id" : "a"})
> db.tbl_test.insert({"id" : "a"})
> db.tbl_test.insert({"id" : "a"})
> db.tbl_test.insert({"id" : "a"})
B机器写入数据:
> db.tbl_test.insert({"id" : "b"})
> db.tbl_test.insert({"id" : "b"})
> db.tbl_test.insert({"id" : "b"})
> db.tbl_test.insert({"id" : "b"})
> db.tbl_test.insert({"id" : "b"})
> db.tbl_test.insert({"id" : "b"})
> db.tbl_test.insert({"id" : "b"})

 
mongoDB pair replication [ two master when remote unreachable ] - 德哥@Digoal - The Heart,The World.
 

假设A机器和B机器之间的网络恢复正常了,两台mongodb将重新协商谁将成为primary。(具体的选择算法参考mongoDB手册)
假设A又变成primary了。
来查询一下刚才插入的数据表:
> db.tbl_test.find()
{ "_id" : ObjectId("4d26c6127073f6939f0149e1"), "id" : "b" }
{ "_id" : ObjectId("4d26c6197073f6939f0149e2"), "id" : "b" }
{ "_id" : ObjectId("4d26c6197073f6939f0149e3"), "id" : "b" }
{ "_id" : ObjectId("4d26c6197073f6939f0149e4"), "id" : "b" }
{ "_id" : ObjectId("4d26c6197073f6939f0149e5"), "id" : "b" }
{ "_id" : ObjectId("4d26c61a7073f6939f0149e6"), "id" : "b" }
{ "_id" : ObjectId("4d26c61a7073f6939f0149e7"), "id" : "b" }
{ "_id" : ObjectId("4d26c60355fd2c402a5c025c"), "id" : "a" }
{ "_id" : ObjectId("4d26c61555fd2c402a5c025d"), "id" : "a" }
{ "_id" : ObjectId("4d26c61655fd2c402a5c025e"), "id" : "a" }
{ "_id" : ObjectId("4d26c61655fd2c402a5c025f"), "id" : "a" }
{ "_id" : ObjectId("4d26c61655fd2c402a5c0260"), "id" : "a" }
{ "_id" : ObjectId("4d26c61655fd2c402a5c0261"), "id" : "a" }
{ "_id" : ObjectId("4d26c61655fd2c402a5c0262"), "id" : "a" }
数据被合并了!

mongoDB pair replication [ two master when remote unreachable ] - 德哥@Digoal - The Heart,The World.
 
总结:
1. 选择好的心跳。加入更完善的判断。
目录
相关文章
|
NoSQL MongoDB 网络安全
|
NoSQL 数据库 数据安全/隐私保护
|
9月前
|
NoSQL MongoDB 数据库
数据库数据恢复—MongoDB数据库数据恢复案例
MongoDB数据库数据恢复环境: 一台操作系统为Windows Server的虚拟机上部署MongoDB数据库。 MongoDB数据库故障: 工作人员在MongoDB服务仍然开启的情况下将MongoDB数据库文件拷贝到其他分区,数据复制完成后将MongoDB数据库原先所在的分区进行了格式化操作。 结果发现拷贝过去的数据无法使用。管理员又将数据拷贝回原始分区,MongoDB服务仍然无法使用,报错“Windows无法启动MongoDB服务(位于 本地计算机 上)错误1067:进程意外终止。”
|
9月前
|
缓存 NoSQL Linux
在CentOS 7系统中彻底移除MongoDB数据库的步骤
以上步骤完成后,MongoDB应该会从您的CentOS 7系统中被彻底移除。在执行上述操作前,请确保已经备份好所有重要数据以防丢失。这些步骤操作需要一些基本的Linux系统管理知识,若您对某一步骤不是非常清楚,请先进行必要的学习或咨询专业人士。在执行系统级操作时,推荐在实施前创建系统快照或备份,以便在出现问题时能够恢复到原先的状态。
948 79
|
9月前
|
存储 NoSQL MongoDB
MongoDB数据库详解-针对大型分布式项目采用的原因以及基础原理和发展-卓伊凡|贝贝|莉莉
MongoDB数据库详解-针对大型分布式项目采用的原因以及基础原理和发展-卓伊凡|贝贝|莉莉
376 8
MongoDB数据库详解-针对大型分布式项目采用的原因以及基础原理和发展-卓伊凡|贝贝|莉莉
|
8月前
|
运维 NoSQL 容灾
告别运维噩梦:手把手教你将自建 MongoDB 平滑迁移至云数据库
程序员为何逃离自建MongoDB?扩容困难、运维复杂、高可用性差成痛点。阿里云MongoDB提供分钟级扩容、自动诊断与高可用保障,助力企业高效运维、降本增效,实现数据库“无感运维”。
|
NoSQL MongoDB 数据库
数据库数据恢复——MongoDB数据库服务无法启动的数据恢复案例
MongoDB数据库数据恢复环境: 一台Windows Server操作系统虚拟机上部署MongoDB数据库。 MongoDB数据库故障: 管理员在未关闭MongoDB服务的情况下拷贝数据库文件。将MongoDB数据库文件拷贝到其他分区后,对MongoDB数据库所在原分区进行了格式化操作。格式化完成后将数据库文件拷回原分区,并重新启动MongoDB服务。发现服务无法启动并报错。

推荐镜像

更多