Mongodb和KT的双机房灾备配置方案尝试

简介: 假设有2个机房(测试服务器2/3以及123/124)互为灾备(灾备机房在主机房对外服务时处于待命),应用都只连接自己机房的存储服务(mongodb1.6.5和kt 0.9.28),两个机房之间的存储服务需要相互同步,尝试方案如下: 编号 ...

假设有2个机房(测试服务器2/3以及123/124)互为灾备(灾备机房在主机房对外服务时处于待命),应用都只连接自己机房的存储服务(mongodb1.6.5和kt 0.9.28),两个机房之间的存储服务需要相互同步,尝试方案如下:

编号

机器IP和端口

服务

备注

1

192.168.2.2:10000

主机房Mongodb masterA

和8双向同步

2

192.168.2.2:20000

主机房Mongodb replica set1

2,5,9,12是数据节点,7,14是鉴证节点

3

192.168.2.2:30000

主机房Kt node1

和10双向同步

4

192.168.2.3:10000

主机房Mongodb slaveA

从1,8复制数据

5

192.168.2.3:20000

主机房Mongodb replica set2

2,5,9,12是数据节点,7,14是鉴证节点

6

192.168.2.3:30000

主机房Kt node2

和13双向同步

7

192.168.2.3:40000

主机房Mongodb replica arb1

鉴证服务器1

8

192.168.2.123:10000

灾备机房Mongodb masterB

和1双向同步

9

192.168.2.123:20000

灾备机房Mongodb replica set3

2,5,9,12是数据节点,7,14是鉴证节点

10

192.168.2.123:30000

灾备机房Kt node1

和3双向同步

11

192.168.2.124:10000

灾备机房Mongodb slaveB

从1,8复制数据

12

192.168.2.124:20000

灾备机房Mongodb replica set4

2,5,9,12是数据节点,7,14是鉴证节点

13

192.168.2.124:30000

灾备机房Kt node2

和6双向同步

14

192.168.2.124:40000

灾备机房Mongodb replica arb2

鉴证服务器2

此套配置特点如下:

1 Mongodb Master / Slave 结构数据保存4份

2 Mongodb Replica Sets 结构数据保存4份

3 KT2个节点,每一个节点数据保存2份(如果把KT像memcached那样使用,在客户端hash key到不同节点的话,需要客户端支持对于不同的服务器IP可以使用相同的hash,也就是不以endpoint作为hash的值,在故障转移之后保持相同key存和取相同的节点,这仅是客户端的逻辑,对于服务端来只需要考虑一组节点之间的同步)

4 切换到灾备机房之后,不需要做任何配置改动,主机房起来之后,需要确定Replica Set的活动服务器在灾备机房,否则可能会存在灾备机房的应用还是在访问主机房的存储服务

说明:

1 之所以除了4个replica set还需要两个鉴证节点是因为经测试如果同一机房两个replica set快速关闭的话,不能正确选举master,如果不需要保证同一机房数据备份的话,可以考虑只用两个数据节点

2 经测试发现如果11不订阅1,只能接受8的数据改动,1的数据改动不会过来,这也是Mongodb的一个缺陷吧,不能级联复制,如果订阅1,那么会在专线中产生两份带宽

 

具体配置如下

192.168.2.2

mongodb 端口 10000/11000

/root/mongodb-linux-x86_64-1.6.5/bin/mongod --fork --port 10000 --dbpath /opt/mongodb/10000 --logpath /opt/mongodb/10000/log --rest --oplogSize 1024 --logappend --master --slave --source 192.168.2.123:10000 --slavedelay 10 --autoresync

mongodb relica set 1 端口 20000/21000

/root/mongodb-linux-x86_64-1.6.5/bin/mongod --fork --port 20000 --dbpath /opt/mongodb/20000 --logpath /opt/mongodb/20000/log --replSet blub --rest --oplogSize 1024 –logappend

/root/mongodb-linux-x86_64-1.6.5/bin/mongo --port 20000

config = {_id: 'blub', members: [

{_id: 0, host: '192.168.2.2:20000'},

{_id: 1, host: '192.168.2.3:20000'},

{_id: 2, host: '192.168.2.123:20000'},

{_id: 3, host: '192.168.2.124:20000'},

]}

rs.initiate(config)

rs.status()

rs.addArb("192.168.2.124:40000")

rs.addArb("192.168.2.3:40000")

kt node1 端口 30000/31000

kchashmgr create /opt/kt/30000.kch

ktserver -port 30000 -ulog /opt/kt/30000-ulog -sid 1 -mhost 192.168.2.123 -mport 30000 -rts /opt/kt/30000.rts -plsv /usr/local/libexec/ktplugservmemc.so -plex "port=31000#opts=f" -dmn /opt/kt/30000.kch

192.168.2.3

mongodb 端口 10000/11000

/root/mongodb-linux-x86_64-1.6.5/bin/mongod --fork --port 10000 --dbpath /opt/mongodb/10000 --logpath /opt/mongodb/10000/log --rest --oplogSize 1024 --logappend –slave --slavedelay 2 --autoresync

/root/mongodb-linux-x86_64-1.6.5/bin/mongo --port 10000

use local

db.sources.insert({"host":"192.168.2.2:10000"});

db.sources.insert({"host":"192.168.2.123:10000"});

mongodb relica set 2 端口 20000/21000

/root/mongodb-linux-x86_64-1.6.5/bin/mongod --fork --port 20000 --dbpath /opt/mongodb/20000 --logpath /opt/mongodb/20000/log --replSet blub --rest --oplogSize 1024 –logappend

/root/mongodb-linux-x86_64-1.6.5/bin/mongod --fork --port 40000 --dbpath /opt/mongodb/40000 --logpath /opt/mongodb/40000/log --replSet blub --rest --oplogSize 1 –logappend

/root/mongodb-linux-x86_64-1.6.5/bin/mongo --port 20000

config = {_id: 'blub', members: [

{_id: 0, host: '192.168.2.2:20000'},

{_id: 1, host: '192.168.2.3:20000'},

{_id: 2, host: '192.168.2.123:20000'},

{_id: 3, host: '192.168.2.124:20000'},

]}

rs.initiate(config)

rs.status()

rs.addArb("192.168.2.124:40000")

rs.addArb("192.168.2.3:40000")

kt node2 端口 30000/31000

kchashmgr create /opt/kt/30000.kch

ktserver -port 30000 -ulog /opt/kt/30000-ulog -sid 1 -mhost 192.168.2.124 -mport 30000 -rts /opt/kt/30000.rts -plsv /usr/local/libexec/ktplugservmemc.so -plex "port=31000#opts=f" -dmn /opt/kt/30000.kch

192.168.2.123

mongodb 端口 10000/11000

/root/mongodb-linux-x86_64-1.6.5/bin/mongod --fork --port 10000 --dbpath /opt/mongodb/10000 --logpath /opt/mongodb/10000/log --rest --oplogSize 1024 --logappend --master --slave --source 192.168.2.2:10000 --slavedelay 10 --autoresync

mongodb relica set 3 端口 20000/21000

/root/mongodb-linux-x86_64-1.6.5/bin/mongod --fork --port 20000 --dbpath /opt/mongodb/20000 --logpath /opt/mongodb/20000/log --replSet blub --rest --oplogSize 1024 –logappend

/root/mongodb-linux-x86_64-1.6.5/bin/mongo --port 20000

config = {_id: 'blub', members: [

{_id: 0, host: '192.168.2.2:20000'},

{_id: 1, host: '192.168.2.3:20000'},

{_id: 2, host: '192.168.2.123:20000'},

{_id: 3, host: '192.168.2.124:20000'},

]}

rs.initiate(config)

rs.status()

rs.addArb("192.168.2.124:40000")

rs.addArb("192.168.2.3:40000")

kt node1 端口 30000/31000

kchashmgr create /opt/kt/30000.kch

ktserver -port 30000 -ulog /opt/kt/30000-ulog -sid 2 -mhost 192.168.2.2 -mport 30000 -rts /opt/kt/30000.rts -plsv /usr/local/libexec/ktplugservmemc.so -plex "port=31000#opts=f" -dmn /opt/kt/30000.kch

192.168.2.124

mongodb 端口 10000/11000

/root/mongodb-linux-x86_64-1.6.5/bin/mongod --fork --port 10000 --dbpath /opt/mongodb/10000 --logpath /opt/mongodb/10000/log --rest --oplogSize 1024 --logappend --slave --slavedelay 2 --autoresync

/root/mongodb-linux-x86_64-1.6.5/bin/mongo --port 10000

use local

db.sources.insert({"host":"192.168.2.123:10000"});

db.sources.insert({"host":"192.168.2.2:10000"});

mongodb relica set 4

/root/mongodb-linux-x86_64-1.6.5/bin/mongod --fork --port 20000 --dbpath /opt/mongodb/20000 --logpath /opt/mongodb/20000/log --replSet blub --rest --oplogSize 1024 --logappend

/root/mongodb-linux-x86_64-1.6.5/bin/mongod --fork --port 40000 --dbpath /opt/mongodb/40000 --logpath /opt/mongodb/40000/log --replSet blub --rest --oplogSize 1 --logappend

/root/mongodb-linux-x86_64-1.6.5/bin/mongo --port 20000

config = {_id: 'blub', members: [

{_id: 0, host: '192.168.2.2:20000'},

{_id: 1, host: '192.168.2.3:20000'},

{_id: 2, host: '192.168.2.123:20000'},

{_id: 3, host: '192.168.2.124:20000'},

]}

rs.initiate(config)

rs.status()

rs.addArb("192.168.2.124:40000")

rs.addArb("192.168.2.3:40000")

kt node2 端口 30000/31000 (和192.168.2.4:30000同步)

kchashmgr create /opt/kt/30000.kch

ktserver -port 30000 -ulog /opt/kt/30000-ulog -sid 2 -mhost 192.168.2.3 -mport 30000 -rts /opt/kt/30000.rts -plsv /usr/local/libexec/ktplugservmemc.so -plex "port=31000#opts=f" dmn /opt/kt/30000.kch

作者: lovecindywang
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。
相关文章
|
NoSQL 网络协议 Unix
第6期 MongoDB配置启动方式
第6期 MongoDB配置启动方式
1195 0
|
存储 NoSQL MongoDB
mongodb 存引擎及配置
mongodb 存引擎及配置
245 0
|
NoSQL 数据可视化 MongoDB
Windows MongoDB的安装及配置图文说明(非常详细)
Windows MongoDB的安装及配置图文说明(非常详细)
1634 0
|
存储 JSON 分布式计算
MongoDB【部署 01】mongodb最新版本6.0.5安装部署配置使用及mongodb-shell1.8.0安装使用(云盘分享安装文件)
MongoDB【部署 01】mongodb最新版本6.0.5安装部署配置使用及mongodb-shell1.8.0安装使用(云盘分享安装文件)
780 0
|
8月前
|
存储 NoSQL MongoDB
Docker中安装MongoDB并配置数据、日志、配置文件持久化。
现在,你有了一个运行在Docker中的MongoDB,它拥有自己的小空间,对高楼大厦的崩塌视而不见(会话丢失和数据不持久化的问题)。这个MongoDB的数据、日志、配置文件都会妥妥地保存在你为它精心准备的地方,天旋地转,它也不会失去一丁点儿宝贵的记忆(即使在容器重启后)。
1019 4
|
NoSQL Linux MongoDB
MongoDB配置用户名和密码
MongoDB配置用户名和密码
2775 0
|
NoSQL 容灾 MongoDB
MongoDB主备副本集方案:两台服务器使用非对称部署的方式实现高可用与容灾备份
在资源受限的情况下,为了实现MongoDB的高可用性,本文探讨了两种在两台服务器上部署MongoDB的方案。方案一是通过主备身份轮换,即一台服务器作为主节点,另一台同时部署备节点和仲裁节点;方案二是利用`priority`设置实现自动主备切换。两者相比,方案二自动化程度更高,适合追求快速故障恢复的场景,而方案一则提供了更多的手动控制选项。文章最后对比了这两种方案与标准三节点副本集的优缺点,指出三节点方案在高可用性和数据一致性方面表现更佳。
1314 5
|
NoSQL MongoDB Windows
MongoDB 读写分离——Windows MongoDB 副本集配置
MongoDB 读写分离——Windows MongoDB 副本集配置
443 0
|
监控 NoSQL 安全
【MongoDB 专栏】MongoDB 的复制集:高可用性配置
【5月更文挑战第10天】MongoDB的复制集是实现数据高可用性的重要机制,由主节点和次节点构成,主节点处理写操作,次节点同步数据确保一致。在主节点故障时,次节点自动提升接替,保证服务不间断。通过复制集,可实现数据保护、持续服务,适用于关键业务系统和数据备份。配置时需关注网络稳定性、节点性能和数据一致性。案例显示,复制集能有效保障服务高可用,防止数据丢失和业务中断,是现代数据库管理的关键工具。在数据驱动的世界,复制集为高可用性提供了坚实保障。
319 0
【MongoDB 专栏】MongoDB 的复制集:高可用性配置
|
DataWorks NoSQL 关系型数据库
DataWorks操作报错合集之在使用 DataWorks 进行 MongoDB 同步时遇到了连通性测试失败,实例配置和 MongoDB 白名单配置均正确,且同 VPC 下 MySQL 可以成功连接并同步,但 MongoDB 却无法完成同样的操作如何解决
DataWorks是阿里云提供的一站式大数据开发与治理平台,支持数据集成、数据开发、数据服务、数据质量管理、数据安全管理等全流程数据处理。在使用DataWorks过程中,可能会遇到各种操作报错。以下是一些常见的报错情况及其可能的原因和解决方法。
324 1

推荐镜像

更多