mongodb副本集架构搭建
高可用性通常描述一个系统经过专门的设计 , 从而减少停工时间 . 保存其服务的高度连续可用性 ,MongoDB 提供的主从复制机制保证了多个数据库的数据同步 , 这对实现数据库的容灾、备份、恢复、负载均衡都是有极大的帮助 .
主从集群
主从复制的优点 :
从服务器可以执行查询工作 , 降低主服务器访问压力
在从服务器执行备份 , 避免备份期间锁定主服务器的数据
当主服务器出现故障时 , 可以快速切换到从服务器 , 减少当机时间 .
MongoDB支持在多个机器中通过异步复制到底故障转移和实现冗余 , 多 台 机器中同一时刻只有一台是用于写操作 , 这 为 mongoDB 提供了数据一致性的保障 . 担当 Primary 角色的机器能把读操作分发给 slave 机器 .
MongoDB的主从集群分为两种
Master-Slave 复制 ( 主从 复制 )
Replica Sets 复制 ( 副本集 )
主服务器支持增删该 , 从服务器主要支持读 .
Master-Slave(主从复制 )
只需要在某一个服务启动时加上 -master 参数 , 以指明此服务器的角色是 primary, 而另一个服务加上 -slave 与 -source 参数 , 以指明此服务器的角色是 slave. 即可实现同步 ,
MongoDB的最新版本已经不推荐使用这种方法了 .
Replica Sets 复制 ( 副本集 )
MongoDB在 1.6 版本开发了 replica set, 主要增加了故障自动切换和自动修复成员节点 . 各个 DB 之间数据完全一致 , 最为显著的区别在于 , 副本集没有固定的主节点 , 它是整个集群选举得出的一个主节点 . 当其不工作时变更其它节点 .
部署 Replica Sets【windows环境模拟】
创建数据文件存储路径 D:\program files\mongo\data\data1\ D:\program files\mongo\data\data2\ 创建日志文件路径 D:\program files\mongo\logs\dblog1.log D:\program files\mongo\logs\dblog2.log 创建主从key文件用于标识集群的私钥的完整路径.如果各个实例的key file内容不一致,程序将不能正常用. D:\program files\mongo\key\key1.txt D:\program files\mongo\key\key2.txt
启动2个实例
mongod --replSet rs1 --keyFile=key/key1.txt --port 8888 --dbpath=data/data1/ --logpath=logs/ dblog1.log mongod --replSet rs1 --keyFile=key/key2.txt --port 8889 --dbpath=data/data2/ --logpath=logs/ dblog2.log 参数说明 --replSet rs1副本集的名字
如图
另起一个窗口
注意 : 服务不能启动时 , 可以去日志文件中查看出现什么错 .
比如 : Sat Jan 19 11:08:50 key file key/key1.txt has length 3, must be between 6 and 1024 chars
重新启动一个窗口 , 登录其中一台
mongo --port 8888
config_rs1 = {
_id : "rs1" ,
members : [ { _id: 0, host:"localhost:8888", priority:1 }, { _id:1, host:"localhost:8889" } ]
}
初始化配置
rs.initiate(config_rs1);
查看副本集状态
rs.status();
可以看到当前 8888 的为主服务器
另起窗口登录从服务器
使用 rs.isMaster() 查看 Replica Sets 状态 .
读写分离
大部分 web 应用都用数据库作为数据持久化工具 , 在并发访问频繁且负载压力较大的情况下 , 也能成为系统性能的 ” 瓶颈 ” ,即使使用本地缓存等方式解决频繁访问数据库的问题 , 但仍会有大量的并发请求访问动态数据 , ” 读写分离 ” 是一种被广泛采用的方案
“ 读写分离 ” ,机制首先将那些使用 CPU 以及内存消耗严重的操作分离到一台或几台性能很高的机器上 , 而将频繁读取的操作放到几台配置较低的机器上 , 然后 , 通过数据同步机制 , 实现多个数据库之间快速高效地同步数据 , 从而实现将 ” 读写请求 ” 按实际负载情况进行均衡分布 .
注意 :在从服务器进行查询操作时报错 ” not master and slaveok= ” false ” ” 说明从库不能执行查询的操作 , 可以让从库可以读 , 分担主库的压力命令如下：
db.getMongo().setSlaveOk();
或者使用 rs.slaveOk()
主从操作日志
数据复制的目的是使数据得到最大的可用性 , 避免单点故障的发生 ,MongoDB 支持在服务器之间进行数据的异步复制 , 以满足数据的最终一致性 , 但是同一时刻只有一台服务器是可以写的 ,MongoDB 的主从复制是一个异步的复制过程 , 数据从一个 primary 实例复制到另一个 slave, 整个复制过程实际上是 slave 端从 primary 端获取日志 , 然后在自己身上完全顺序执行日志中所有记录的各种操作 .
MongoDB的 Replica Sets 架构是通过一个 primary 数据库中的日志表来存储写操作的 , 这个日志表叫做 oplog.rs.oplog.rs 是一个固定长度的 capped collection, 存在于 local 数据库中 , 用于记录 Replica Sets 操作日志 .
通过 db.oplog.rs.find(); 命令查看复制集产生的日志信息 .
rs1:PRIMARY> db.oplog.rs.find();
主从切换
有时候由于种种原因 , 需要调整复制集中的主从角色 . 步骤如下
1. 除了现在的主实例 , 和目标实例以外 , 其它的实例全部设为 ” 冰冻 ” 状态 (freeze 状态 , 即非主状态 )
Eg.rs.freeze(30),将当前实例 ” 冰冻 ” ,其中的 30 单位是秒 , 说明 30 秒内这个实例不会参与 primary 的内部选举工作 ,
2. 将当前主库的实例降级 (stepDown)
Eg.rs.stepDown(30),将当前主库实例 ” 降级 ” 30秒 .
3. 上面的操作结束后 , 用 rs.status 查看复制集的状态 .
过程很简单 , 其它的不参与选举 , 自己降级 , 目标机肯定优先级就提升了 , 成为了主库 .
将上面的主从集实现主从切换
主从配置信息
在 local 库中不仅有主从日志 oplog.rs, 还有一个集合用于记录主从配置信息 system.replset, 通过执行 ” db.system.replset.find() ” 命令查看复制集的配置信息
为复制集中添加节点
MongoDB提供了 2 种增加节点的方案 .
1. 通过 oplog 增加节点
这种添加方式 , 使数据库的同步完全依赖于 oplog, 即 oplog 中有多少操作日志 , 这些操作日志就完全在新添加的节点中执行一遍 . 已完成数据同步 .
对实例中的 2 个节点中添加一个节点
创建数据存放文件路径 D:\program files\mongo\data\data3
创建 key 文件输出路径 D:\program files\mongo\key /key3.txt [注意 key 文件中的密钥必须跟之前节点中的一致 ]
创建日志存放文件路径 D:\program files\mongo\logs \ dblog3.log
D:\program files\mongo\bin>mongod --replSet rs1 --keyFile=key/key3.txt --port 9999 --dbpath=data/data3/ --logpath=logs/dblog3.log
然后添加此新节点到现有的 replica collection 中 .
rs1:PRIMARY> rs.add("localhost:9999");
可以使用 rs.status()查看复制集状态 , 新增的节点已经添加成功
登录新增节点 , 查寻数据 , 如下说明数据同步成功
2. 通过数据库快照和 oplog 增加节点
通过 oplog 直接执行增加节点操作简单且无需人工干预 , 但 oplog 是 capped collection, 采用循环的方式执行日志处理 , 所以采用 oplog 的方式执行增加节点 , 有可能导致数据的不一致 , 因为日志中存储的信息可能已经被刷新过 , 为了解决这个问题 , 可以通过数据库快照和 oplog 结合的方式来增加节点 .
这种方式的操作流程是 , 先取某一个复制集成员的物理文件作为初始化数据 , 剩余的部分用 oplog 日志来补充 , 最终达到数据一致性 .
减少节点
减少节点很简单 , 只需要执行 ” rs.remove( “ ip:port ” ) ” 即可 .
例如 , 将实例中的 9999 节点移除 .
可以通过 rs.status()查看移除后的状态 members 成员中已经没有 9999 节点了 .
故障转移
副本集比传统的 Master-Slave 有改进的地方就是它可以进行故障的自动转移 , 如果我们停掉复制集中的一个成员 , 那么剩余成员会再自动选举一个成员 , 作为主库 .
这种故障处理机制 ,能极大的提供系统的稳定性和扩展性 .
转载请注明出处:[ http://www.cnblogs.com/dennisit/archive/2013/01/28/2880166.html ]
热爱生活,热爱Coding,敢于挑战,用于探索 ...
分类: NoSQL
标签: MongoDB , 副本集 , Replica Sets , 架构 , 搭建
作者： Leo_wl
出处： http://www.cnblogs.com/Leo_wl/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
版权信息