【私货】MongoDB 副本集的运维部署
微信公众号:当程序员以后
关注可了解更多的开发技巧。
前面几篇文章,我分享了关于MongoDB索引和常见的命令,今天趁给团队分享了MongoDB实战,继续给大家聊聊MongoDB的副本集配置部署。
副本集介绍
什么是副本集?副本集是MongoDB的复制系统,用于将数据同步到各个服务器的过程。
前面的文章中我演示的基本都是单节点mongod服务器,单节点在测试环境还行,但是在线上生产环境就不合适了,因为如果单节点出问题了,会导致应用宕机。
所以这个时候我们可以MongoDB的复制功能,使用多节点进行部署,其中一台服务器节点宕机了,还有其他节点运行,进行故障转移,让应用不会受到影响,从而更为高可用。
说到故障转移,MongoDB初支持一种叫「主从模式」(master-slave)这种模式下MongoDB不会做自动故障转移的。这种模式现在已经不推荐使用了,这里就不过多介绍了。
由于副本集新增节点或者删除节点都非常方便,建议即使你一开始是单节点也以副本集的方式启动,方便后续进行节点添加。
成员介绍
副本集成员这里主要介绍仲裁者arbiter, 延迟备份节点这两种成员。
说到仲裁者,这里需要说一个副本集成员之间选举主节点过程有一个满足「大多数」原则 即 n/2 + 1 。仲裁者作用就是「参与选举」,不保存数据。解决在一开始我们应用程序量很小的时候,没有资源,不想保存三分及以上数据副本。
rs.add({"_id": 3, "host": "server-3:27017", "arbiterOnly": true})
这里注意:
- 多只能使用一个仲裁者
- 奇数节点不需要仲裁者
- 尽可能使用奇数个数据节点,不使用仲裁者
说完仲裁者,我们说一下「延迟备份节点」,在给团队内部做分享的时候,我们公司的运维大神专门强调要讲这个,这个是有历史血泪的。
延迟备份节点主要作用避免有人不小心删除了主数据库,或者应用程序有一个严重Bug导致把所有数据玩坏了。为了避免这一类问题,设置一个延迟备份节点。强烈建议线上配置,这是有血泪史的。
rs.add( { _id:4, host: "server-4:27020", priority: 0, hidden:true, slaveDelay:7200, votes:0, buildIndexes:true, arbiterOnly:false } )
其实这也算是一个备份方式之一,保底计划。
副本集初始化
副本集成员启动之后,配置这里我放在后一节来说,这里我们直接说副本集启动后的初始化操作。
成员初始化操作主要有4个步奏:
- 成员在http://local.me自己创建标志符,删除本地已存在的数据,进行数据同步
- 将同步源的所有记录数据克隆到本地,这一步是耗时的
- 将个oplog同步中操作记录下来。
- 创建索引,同步创建索引期间的所有操作
通过上面的4个步奏,就完成了副本集初始化。
副本集备份
备份的方式简单小结有以下四种方式:
一、 文件系统快照:其中文件系统快照需要文件系统本身支持,mongod开启日记系统,后面我配置会说。
二、 复制数据目录:就是复制数据目录所有文件,在备份我们需要防止数据文件不能发生改变,否则将不可用。
保证数据不变,可以通过
db.fsyncLock() 进行锁定所有数据库,运行之后后续操作会加入队列等待。
cp -R /data/db/* /backup/
db.fsyncUnlock() # 解锁数据库能再次进行写操作
三、mongodump:备份恢复速度较慢,不推荐
四、延迟备份节点: 原则上不算备份策略,但是比较重要通过它来延迟防止数据误操作。
副本集部署
后我们终于说到了副本集配置,这里我们配置好mongod.conf配置,replaSetName设置为test_rs名,配置如下:
storage:
dbPath: /test/mongodb/rs1 # 配置路径
journal:
enabled: true # 开启日记系统
systemLog:
destination: file
logAppend: true
path: /test/log/mongodb/rs1.log # 日志
processManagement:
pidFilePath: /var/run/mongodb/rs1.pid
net:
port: 27018
bindIp: 1.2.3.4 # 绑定固定IP
replication:
replSetName: "test_rs" # 选定配置名
security:
authorization: enabled
keyFile: /test/mongodb/key/test_rs.key
相关文章