MongoDB之复制集篇

发表评论

A+

MongoDB复制集

MongoDB复制集简介

一组Mongodb复制集，就是一组mongod进程，这些进程维护同一个数据集合。复制集提供了数据冗余和高等级的可靠性，这是生产部署的基础

复制集的目的

保证数据在生产部署时的冗余和可靠性，通过在不同的机器上保存副本来保证数据的不会因为单点损坏而丢失。能够随时应对数据丢失、机器损坏带来的风险。
换一句话来说，还能提高读取能力，用户的读取服务器和写入服务器在不同的地方，而且，由不同的服务器为不同的用户提供服务，提高整个系统的负载。

复制集功能介绍

一组复制集就是一组mongod实例掌管同一个数据集，实例可以在不同的机器上面。实例中包含一个主导，接受客户端所有的写入操作，其他都是副本实例，从主服务器上获得数据并保持同步。
主服务器很重要，包含了所有的改变操作（写）的日志。但是副本服务器集群包含有所有的主服务器数据，因此当主服务器挂掉了，就会在副本服务器上重新选取一个成为主服务器。
每个复制集还有一个仲裁者，仲裁者不存储数据，只是负责通过心跳包来确认集群中集合的数量，并在主服务器选举的时候作为仲裁决定结果。

副本集中数据同步

副本集中数据同步过程：Primary节点写入数据，Secondary通过读取Primary的oplog得到复制信息，开始复制数据并且将复制信息写入到自己的oplog。如果某个操作失败，则备份节点停止从当前数据源复制数据。如果某个备份节点由于某些原因挂掉了，当重新启动后，就会自动从oplog的最后一个操作开始同步，同步完成后，将信息写入自己的oplog，由于复制操作是先复制数据，复制完成后再写入oplog，有可能相同的操作会同步两份，不过MongoDB在设计之初就考虑到这个问题，将oplog的同一个操作执行多次，与执行一次的效果是一样的。简单的说就是：

当Primary节点完成数据操作后，Secondary会做出一系列的动作保证数据的同步：

检查自己local库的oplog.rs集合找出最近的时间戳。
检查Primary节点local库oplog.rs集合，找出大于此时间戳的记录。
将找到的记录插入到自己的oplog.rs集合中，并执行这些操作。

副本集的同步和主从同步一样，都是异步同步的过程，不同的是副本集有个自动故障转移的功能。其原理是：slave端从primary端获取日志，然后在自己身上完全顺序的执行日志所记录的各种操作（该日志是不记录查询操作的），这个日志就是local数据库中的oplog.rs表，默认在64位机器上这个表是比较大的，占磁盘大小的5%，oplog.rs的大小可以在启动参数中设定：–oplogSize 1000,单位是M。

注意：在副本集的环境中，要是所有的Secondary都宕机了，只剩下Primary。最后Primary会变成Secondary，不能提供服务。

复制的基本架构

　基本的架构由3台服务器组成，一共三成员的复制集，由三个有数据，或者两个有数据，一个作为仲裁者

三个存储数据的复制集

一个主库；两个从库组成，主库宕机时，这两个从库都可以被选为主库

当主库宕机后,两个从库都会进行竞选，其中一个变为主库，当原主库恢复后，作为从库加入当前的复制集群即可

当存在arbiter节点

一个主库，一个从库，可以在选举中成为主库，一个aribiter节点，在选举中，只进行投票，不能成为主库

由于arbiter节点没有复制数据，因此这个架构中仅提供一个完整的数据副本。arbiter节点只需要更少的资源，代价是更有限的冗余和容错。
当主库宕机时，将会选择从库成为主，主库修复后，将其加入到现有的复制集群中即可。

Primary选举

复制集进行初始化，初始化后各个成员间开始发送心跳消息，并发起Priamry选举操作获得『大多数』成员投票支持的节点，会成为Primary，其余节点成为Secondary。
设置节点范式：N/2 + 1，通常建议将复制集成员数量设置为奇数

复制集中成员说明

成员	说明
Secondary	正常情况下，复制集的Seconary会参与Primary选举（自身也可能会被选为Primary），并从Primary同步最新写入的数据，以保证与Primary存储相同的数据。Secondary可以提供读服务，增加Secondary节点可以提供复制集的读服务能力，同时提升复制集的可用性。另外，Mongodb支持对复制集的Secondary节点进行灵活的配置，以适应多种场景的需求。
Arbiter	Arbiter节点只参与投票，不能被选为Primary，并且不从Primary同步数据。比如你部署了一个2个节点的复制集，1个Primary，1个Secondary，任意节点宕机，复制集将不能提供服务了（无法选出Primary），这时可以给复制集添加一个Arbiter节点，即使有节点宕机，仍能选出Primary。Arbiter本身不存储数据，是非常轻量级的服务，当复制集成员为偶数时，最好加入一个Arbiter节点，以提升复制集可用性。
Priority0	Priority0节点的选举优先级为0，不会被选举为Primary,比如你跨机房A、B部署了一个复制集，并且想指定Primary必须在A机房，这时可以将B机房的复制集成员Priority设置为0，这样Primary就一定会是A机房的成员。（注意：如果这样部署，最好将『大多数』节点部署在A机房，否则网络分区时可能无法选出Primary）
Vote0	Mongodb 3.0里，复制集成员最多50个，参与Primary选举投票的成员最多7个，其他成员（Vote0）的vote属性必须设置为0，即不参与投票。
Hidden	Hidden节点不能被选为主（Priority为0），并且对Driver不可见。因Hidden节点不会接受Driver的请求，可使用Hidden节点做一些数据备份、离线计算的任务，不会影响复制集的服务。
Delayed	Delayed节点必须是Hidden节点，并且其数据落后与Primary一段时间（可配置，比如1个小时）。因Delayed节点的数据比Primary落后一段时间，当错误或者无效的数据写入Primary时，可通过Delayed节点的数据来恢复到之前的时间点。

复制集中成员说明

系统环境说明

三台虚拟机，环境同mongodb基础篇中的环境一致
ip:172.16.2.136，172.16.2.137，172.16.2.138

创建副本集

修改配置文件增加如下配置 # 三台mongodb都需要操作

1.[root@master ~]# vim /etc/mongod.conf

2.replication:

3. replSetName: testrs0 设置副本集名称

登录mongodb执行初始化操作

1.config = {_id: 'testrs0', members: [

2. {_id: 0, host: '172.16.2.136:27017'},

3. {_id: 1, host: '172.16.2.137:27017'}]

4.}

5.rs.initiate(config)

查看副本集状态

1.rs.status()

此处主上操作

添加从副本集
- testrs0:PRIMARY> rs.add(“172.16.2.138:27017”) # 添加一个节点
插入一个文档
- testrs0:PRIMARY> use testdb
- testrs0:PRIMARY> db.testcoll.insert({Nmme:”roy”,Age:22,Gender:”F”})
  此处从上操作
提升从节点，并可读
- estrs0:SECONDARY> rs.slaveOk()
- testrs0:SECONDARY> use testdb
- testrs0:SECONDARY> db.testcoll.find()
  停掉主节点，实现故障转移
主节点操作
- [root@node1 ~]# systemctl stop mongod
从节点查看状态
- testrs0:SECONDARY> rs.status() # 主切换到138

修改节点的优先级

查看现有的配置信息

1.testrs0:PRIMARY> rs.conf()

修改优先级

1.testrs0:PRIMARY> config = rs.config()

2.testrs0:PRIMARY> config.members[0].priority = 2

3.testrs0:PRIMARY> rs.reconfig(config)

副本集其他操作

查看当前是否是主节点

1.rs.isMaster();

添加删除节点

1.rs.add("ip:port"); # 新增从节点

2.rs.addArb("ip:port"); # 新增仲裁节点

3.rs.remove("ip:port"); # 删除一个节点

4.添加特殊节点时:

5. 可以在搭建过程中设置特殊节点

6. 可以通过修改配置的方式将普通从节点设置为特殊节点

参考文献

https://www.cnblogs.com/zhoujinyi/p/3554010.html
https://www.cnblogs.com/clsn/p/8214345.html

来源：https://my.oschina.net/u/3367404/blog/3105581

标签

Arbiter

mongodb