查看复制集状态
rs.status()
查看配置文件
rs.conf()
查看复制集的主节点
db.isMaster()
查看副本集的配置
rs.conf()
查看复制的情况
rs.printSlaveReplicationInfo()
或
rs.printReplicationInfo()
检查oplog日志时间和大小
rs.printReplicationInfo()
增加从节点
mkdir -p /data/mongodb_27116/{db,logs}
chown -R mongodb:mongodb /data/mongodb_27116
cp /etc/mongodb_27117.conf /etc/mongodb_27116.conf
sed -i "s#27117#27116#g" /etc/mongodb_27116.conf
/usr/local/mongodb/bin/mongod -f /etc/mongodb_27116.conf
rs.add({"host":"127.0.0.1:27116"})
或者 指定 "_id" 、"hidden":false 、 "hidden":true 、"arbiterOnly":true 等：
rs.add({"_id":31,"host":"127.0.0.1:27116","hidden":false})
删除节点
rs.remove("127.0.0.1:27116")
增加投票节点
rs.addArb("127.0.0.1:27116")
或者
rs.add({"_id":5,"host":"127.0.0.1:27116","arbiterOnly":true})
修改节点参数=> 将Secondary节点设置为隐藏节点
cfg = rs.conf()
cfg.members[0].priority = 0
cfg.members[0].hidden = true
rs.reconfig(cfg)
修改节点参数=> 配置一个节点为延迟复制节点
PRIMARY> cfg=rs.conf()
PRIMARY> cfg.members[2].priority=0
PRIMARY> cfg.members[2].hidden=true
PRIMARY> cfg.members[2].slaveDelay=3600
PRIMARY> rs.reconfig(cfg)
最后通过 rs.conf() 命令查看，截取到的部分输出如下，其中，"slaveDelay" : NumberLong(3600) ，说明一件配置成功
{
"_id" : 2,
"host" : "127.0.0.1:27119",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : true,
"priority" : 0,
"tags" : {
},
"slaveDelay" : NumberLong(3600),
"votes" : 1
}
注意：
优先级为 0 的成员永远不能成为主节点。slaveDelay要求成员的优先级是0，即 priority=0。
3600 单位为秒，即一个小时。
输入 rs.status() 之后，输出结果的 "_id" : 2 和 cfg.members[2] 这两个数字 2，不是同一回事，不是ID号哦。
cfg.members[2] ，这个2 的获取方法为： rs.status()输出结果，往下数，第一个节点为0，第二个为1，以此类推。
修改优先级，此操作需在PRIMARY上执行
PRIMARY> config=rs.conf()
PRIMARY> config.members[1].priority=3
PRIMARY> rs.reconfig(config)
{
"ok" : 1,
"$clusterTime" : {
"clusterTime" : Timestamp(1568179129, 1),
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : NumberLong(0)
}
},
"operationTime" : Timestamp(1568179129, 1)
}
PRIMARY> rs.conf()
SECONDARY> db.isMaster()
说明：
先级的有效取值是0~1000，可为小数，默认为1。
如果将priority设置为0，则这个Secondary节点永远不会为为Primary节点。
将Primary节点降级为Secondary节点
PRIMARY> rs.stepDown()
也可手动指定时间
PRIMARY> rs.stepDown(30)
冻结Secondary节点
如果需要对Primary做一下维护，但是不希望在维护的这段时间内将其它Secondary节点选举为Primary节点，可以在每次Secondary节点上执行freeze命令，强制使它们始终处于Secondary节点状态。
注：只能在Secondary节点上执行
SECONDARY> rs.freeze(100)
解冻Secondary节点
SECONDARY> rs.freeze()
强制节点进入维护模式（recovering）
db.adminCommand({"replSetMaintenance":true});
为Secondary节点显式指定复制源
rs.syncFrom("127.0.0.1:27119")
以单机模式启动成员
原来是副本集成员，成为一个以单机模式启动成员，只要在重启的时候不使用replSet选项即可。
副本集主从切换方法
方法一：
将Primary节点降级为Secondary节点，也可手动指定时间
PRIMARY> rs.stepDown(30)
方法二：
修改config变量，第三组（members[2]）成员的优先级为3
PRIMARY> cfg=rs.conf()
PRIMARY> cfg.members[2].priority = 3
PRIMARY> rs.reconfig(cfg)
PRIMARY> rs.conf()
SECONDARY> rs.status()
修改Oplog集合的大小
如果是主节点，则先将primary 降为 secondary。最后确保没有其他secondary 从该节点复制数据。rs.status()
1、关闭该mongod服务 use admin > db.adminCommand({shutdownServer:1});
2、以单机方式重启该mongod（注释掉 配置文件中的 replSet shardsvr ，修改端口号）
3、将local.oplog.rs中的最后一条 insert 操作记录保存到临时集合中
mongo> use local
mongo>var cursor=db.oplog.rs.find({"op":"i"});
mongo>var lastinsert=cursor.sort({$natural:-1}).limit(1).next();
mongo>db.templastop.save(lastinsert);
mongo>db.templastop.findOne()#确保写入
4、将oplog.rs 删除： db.oplog.rs.drop();
5、创建一个新的oplog.rs集合：
db.createCollection("oplog.rs":{"capped":true,"size":10240});
6、将临时集合中的最后一条insert操作记录写回新创建的oplog.rs：
确保写回，否则 该节点重新加入副本集后会删除该节点上所有数据，然后重新同步所有数据。
var temp=db.templastop.findOne();
db.oplog.rs.insert(temp);
db.oplog.rs.findOne()
7、最后将该节点以副本集成员的身份重新启动即可。
修改服务器hostname
1、首先修改 secondary 服务器的 hostname;然后 stop secondary;
2、重启 secondary 以修改后的新hostname；
3、登录 primary ，用rs.reconfig()命令修改 复制集的配置信息；
conf=rs.conf()
conf.members[x].host='new_address:27017'
rs.reconfig(conf)
测试副本集数据复制功能
在Primary 上插入数据：
for(var i=0;i<10000;i++){db.test.insert({"name":"test"+i,"age":123})}
db.test.count()
在Secondary上查看是否已经同步：
SECONDARY> rs.slaveOk()
SECONDARY> db.test.count()
测试副本集故障转移功能
关闭Primary节点，查看其他2个节点的情况：
PRIMARY> use admin
PRIMARY> db.shutdownServer()
复制集状态，即rs.status()输出结果说明
"_id": 副本集的名称，服务器的唯一ID
"members": 副本集的服务器列表
"host": 服务器主机
"priority": 是优先级，默认为1，优先级0为被动节点，不能成为活跃节点。优先级不位0则按照有大到小选出活跃节点。
"arbiterOnly": 仲裁节点，只参与投票，不接收数据，也不能成为活跃节点。
"state" : 1, 成员状态，1：Primary
"stateStr" : "PRIMARY", 状态描述
"uptime" : 27104, 副本集运行时间，Primary为MongoDB运行时间，单位秒
"optime" : Timestamp(1435301307, 10), 最近一次更改数据库的时间：1435301307;每秒执行操作数据库的次数：10
"optimeDate" : ISODate("2020-08-26T10:01:42Z") 最后一个操作发生的时间
"electionDate" : ISODate("2020-08-26T05:27:20Z") 最后选举时间
"lastHeartbeat" : ISODate("2020-08-26T04:07:28.589Z"), #最后一次收到其他成员心跳时间
"pingMs" : 0, #心跳发送到达时间，根据其选择从哪个成员进行同步
"syncingTo" : "127.0.0.1:27017", #同步成员地址
复制集介绍
1.Primary节点为主节点，所有的写操作或者更改操作都只能从Primary节点中操作(复制集内的所有成员都可以接收读操作，
但是，默认情况下，应用程序将其读操作指向主成员)，主节点上所有的更改及写操作都会记录到oplog日志中。
2.两台Secondary节点复制Primary节点的oplog日志，通过异步的方式去执行oplog日志中的记录来和Primary节点达到数据一致性。
3.oplog作用主要是记录主节点的写入操作，充当复制源。
4.如果Primary节点无故Down机之后，复制集集群会通过投票机制在两台Secondary中选举一台升级为Primary节点。
关于oplog
Replica Sets复制集用于在多台服务器之间备份数据。MongoDB的复制功能是使用操作日志oplog实现的，操作日志包含了主节点的每一次写操作。
oplog是主节点的local数据库中的一个固定集合。备份节点通过查询这个集合就可以知道需要进行复制的操作。
一个mongod实例中的所有数据库都使用同一个oplog，也就是所有数据库的操作日志(插入，删除，修改)都会记录到oplog中
每个备份节点都维护着自己的oplog,记录着每一次从主节点复制数据的操作。这样，每个成员都可以作为同步源给其他成员使用。
如图所示，备份节点从当前使用的同步源中获取需要执行的操作，然后在自己的数据集上执行这些操作，
最后再将这些操作写入自己的oplog,如果遇到某个操作失败的情况(只有当同步源的数据损坏或者数据与主节点不一致时才可能发生),那么备份节点就会停止从当前的同步源复制数据。
oplog中按顺序保存着所有执行过的写操作，replica sets中每个成员都维护者一份自己的oplog，每个成员的oplog都应该跟主节点的oplog完全一致(可能会有一些延迟)。
如果某个备份节点由于某些原因挂了，但它重新启动后，就会自动从oplog中最后一个操作开始进行同步。
由于复制操作的过程是想复制数据在写入oplog,所以备份节点可能会在已经同步过的数据上再次执行复制操作。
MongoDB在设计之初就考虑到了这种情况:将oplog中的同一个操作执行多次，与只执行一次的效果是一样的。
由于oplog大小是固定的，它只能保持特定数量的操作日志。
通常，oplog使用空间的增长速度与系统处理写请求的速率几乎相同：如果主节点上每分钟处理了1KB的写入请求，那么oplog很可能也会在一分钟内写入1KB条操作日志。
但是，有一些例外：如果单次请求能够影响到多个文档(比如删除多个文档或者多文档更新),oplog中就会出现多条操作日志。
如果单个操作会影响多个文档，那么每个受影响的文档都会对应oplog的一条日志。
因此，如果执行db.student.remove()删除了10w个文档，那么oplog中也就会有10w条操作日志，每个日志对应一个被删除的文档。如果执行大量的批量操作，oplog很快就会被填满。
投票选举机制
MongoDB节点之间维护心跳检查，主节点选举由心跳触发。
心跳检查
MongoDB复制集成员会向自己之外的所有成员发送心跳并处理响应信息，因此每个节点都维护着该节点看到的其它所有节点的状态信息，
节点根据自己的集群状态判断是否需要更新新的Primary。在实现的时候主要由两个异步的过程分别处理心跳响应和超时，
每个复制集成员都会在后台运行与复制集所有节点的心跳线程，在以下几种情况下会触发状态检测过程：
1.Secondary节点权重(Priority)比Primary节点高时，发起替换选举；
2.Secondary节点发现集群中没有Primary时，发起选举；
3.Primary节点不能访问到大部分成员时主动降级，降级操作会断开连接，终止用户请求等；
4.复制集成员心跳检测结果发生变化，比如某个节点挂了或者新增节点，发起重新投票选举规则；
5.超过4s没有执行状态检测过程，发起替换选举；
成员状态
STARTUP
成员刚启动时处于这个状态。在这个状态下，MongoDB会尝试加载成员的副本集配置，配置加载成功后，就会进入STARTUP2。
STARTUP2
整个初始化同步过程都处于这个状态，但是如果是在普通成员上，这个状态只会持续几秒钟，
这个状态下，Mongodb会创建几个线程，用于处理复制和选举，然后切换到RECOVERING状态。
RECOVERING
这个状态表明成员运转正常，但是暂时不能处理读取请求，之后才可以处理读取请求，可能会造成轻微的系统过载。
启动时，成员需要做一些检查以确保自己处于有效状态，以后才可以处理读取请求，
在启动过程中，成为备份节点之前，每个成员都要经历RECOVERING状态。在处理非常耗时的操作时，
成员也可能进入RECOVERING状态；当一个成员与其他成员脱节时，也会进入RECOVERING状态。
ARBITER
在正常的操作中，仲裁者应该始终处于该状态。
出现错误时的状态
DOWN
如果一个正常运行的成员不可达，就处于DOWN状态。注意，此状态有可能仍然处于正常运行状态，不可达原因可能是网络问题。
UNKNOWN
如果一个成员无法到达其他任何成员，其他成员不知道它处于什么状态，会将其报告为UNKNOWN状态。
通常此状态表明这个未知状态的成员挂掉了，或者是两个成员之间存在网络访达问题。
REMOVED
成员被移除副本集时，就处于该状态。如果被移出的成员又被重新添加到副本集中，它就会回到正常状态。
ROLLBACK
表明该成员正处于数据回滚。回滚过程结束就会转换成RECOVERING状态，然后成为备份节点。
FATAL
成员发生了不可挽回的错误，也不在尝试恢复正常。通过应该重启服务器，进行重新同步或者是从备份中恢复。
选举发起
发起选举的节点首先需要做一些条件判断，维护主节点的有N个备用节点，备用节点中的所有节点都可能被选举成为主节点，
成为主节点前每个备节点都会检测自身以及全局条件是否满足，检测条件如下：
1.是否看见复制集中是否有Majority在线
2.自身Priority是否大于0
3.自身不为arbiter
4.自身opTime不能落后于最新节点10s以上
5.自身存储的集群程序按信息为最新
如果所有条件满足，则将自身添加到主节点的备用列表中，否则，将自身从列表中移除
自身检测
1.MongoDB选举需要获得大多数投票才能通过，如果没有节点投反对票，且获得成票数超过有权投票节点总数的1/2，则能成为Primary。
否则进入下一轮选举。为避免陷入无限重复选举，MongoDB建议复制集的成员个数为奇数，当Secondary为双数时，可以增加一个Arbiter节点。
2.选举过程中，复制集没有主节点，所有成员都是只读状态
3.选举过程很复杂，一般情况下需要5s左右进行选主。
4.如果新选择的主节点立刻挂掉，至少需要30s时间重新选主。
大多数的定义
假设复制集内投票成员数量为N，则大多数 = N/2 + 1 ，当复制集内存活成员数量不足大多数时，整个复制集将无法选举出Primary，复制集将无法提供写服务，处于只读状态。
举例来说，三台MongoDB，一台Primary，两台Secondary，主节点挂了之后，只有两台Secondary可以投票，
根据公式我们来算 “2/2 + 1 = 2”，也就是算大多数等于2，但是当复制集内存活的成员数量不足大多数时，
我们的大多数为2，集群成员也为2，所以这两台集群成员会发起选举投票机制，
如果两台Secondary节点自身条件都满足的情况下，则先发起选举节点的成员成为Primary节点
投票成员数 大多数 容忍失效数
1 1 0
2 2 0
3 2 1
4 3 1
5 3 2
6 4 2
7 4 3
复制集群成员说明
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节点的数据来恢复到之前的时间点。
浙公网安备 33010602011771号