一 检测机制
1 mongodb的每个节点成员都会同其他节点进行周期性的节点检测 如果超过一定的阈值没有反馈,就认为其他节点不可用
2 当主挂掉后.mongodb的所有从节点会进行选举
当选成新主的条件
0 原主已经挂掉
1 optime必须是所有成员中最新的,也即是数据是最新的
2 优先级非0(仲裁延时和备用节点)
3 收获超过集群所有成员超过一半以上的投票数
3 当选择新主后 其他从节点会指向新主
4 mongodb是类raft协议 但是不是raft协议
二 切换手段
1 调大seconday的priority的优先级切换
2 主节点发生故障,从节点切换
3 高负载情况下,从节点切换
三 rs.status解读
"health" : 1,//是否正常 正常未1
"stateStr" :
1 PRIMARY(主节点) SECONDARY(从节点) ARBITER(仲裁节点)
2 startup/startup2(新节点加入全量同步时)
3 RECOVERING(恢复中,需要人工介入进行重新全量同步,需要的oplog已经被覆盖)
ROLLBACK(造成原因:在选举一节中我们提到选举,如果一个主节点在写入一条数据后并没有来得及将该数据同步到从节点,此刻主节点突然宕机,这时从节点发起选举请求,选举出新的主节点,那么新的主节点是没有老的主节点那一条数据的,老主节点将会发生回滚)
(回滚中,状态会转换为RECOVERING或者SECONDARY,当处于RECOVERING状态中,仍需要人介入全量同步）
4 REMOVED(已移除) DOWN(服务不可达,需要启动服务,存在无法启动的情况(文件损坏,代码异常错误),仍需要人介入全量同步)
"syncto" : host //从哪里同步
四 同步具体细节
1 同步过程
3.2之前:建立_id索引->同步数据->建立其他索引->拉取增量oplog并应用(开始只记录时间,然后取这个时间段的oplog)
3.2之后:建立所有索引->同步数据->应用本地oplog并应用(从开始就缓存oplog到本地)
---拉取oplog缓存在本地---
2 同步关键点
1 initial sync单线程复制数据，效率比较低 可采用rsync先预先同步,再停止服务,rsync一次即可
2 如果oplog原因无法拉取成功,可以调整全量同步时间段,在业务低峰期进行操作
3 _initialSyncFlag
五 读写分类特性
1 在副本节点上设置rs.slaveOk();
2 代码层面，在读操作过程中设置从副本节点读取数据 在options里添加read-Preference=secondaryPreferred
以下为主要参数
primary:默认参数，只从主节点上进行读取操作；
primaryPreferred:大部分从主节点上读取数据,只有主节点不可用时从secondary节点读取数据。
secondary:只从secondary节点上进行读取操作，存在的问题是secondary节点的数据会比primary节点数据“旧”。
secondaryPreferred:优先从secondary节点进行读取操作，secondary节点不可用时从主节点读取数据；
nearest:不管是主节点、secondary节点，从网络延迟最低的节点上读取数据。
六 oplog相关
1 默认为磁盘5%(1G(下限)-50G(上限)),默认情况下即可,符合大多数情况
2 oplog不宜设置太大,也不能太小,要进行估算,条件就是单位时间内的数据变化次数,业务量大就可以设置调大
3 在线调整大小
在MongoDB 3.4及更早的版本中，直接删除并重建local.oplog.rs集合来调整操作日志的大小；
在MongoDB 3.6及后续的版本中，使用replSetResizeOplog命令来调整操作日志的大小(禁止删除local.oplog.rs集合)
1 use local
2 db.oplog.rs.stats().maxSize
3 db.adminCommand({replSetResizeOplog:1,size:1000})(单位MB）
4 db.runCommand({"compact" : "oplog.rs"}) 压缩oplog进行回收
相关文章：