windows平台搭建Mongo数据库复制集（类似集群）（三）

标签：oar   3.3   接下来   还原   应用程序   数据   set   恢复   环境   

在本篇里面，咱们重点总结一下复制集,以及分析一下它的工作原理

一、常见场景 

应用程序和数据库之间的网络连接丢失 

计划停机、断电、数据库服务硬盘故障等等

复制可以进行故障转移，复制能让你在副本间均衡读负载，保证复制节点与主节点保持同步

二、工作原理 

副本集依赖于两个基础机制：oplog和“心跳”（heartbeat）.oplog让数据的复制成为可能，而“心跳”则监控健康情况并出发故障转移；

2.1 关于oplog 

oplog是MongoDB复制的关键，oplog是一个固定集合，位于每个复制节点的local数据库中，记录了对数据库的所有变更，每次客户端向主节点写入数据，就会自动向主节点的oplog里添加爱一条记录，其中博客了足够的信息来再现数据。一旦写操作被复制到某个从节点上，从节点的oplog也会保存一条记录。

local数据库里保存了所有的副本集元数据和oplog，因为本身不能被复制；

那我们详细在看oplog

在此注意，每个从节点都有一份自己的oplog，从节点使用长轮询的方式立即应用来自主节点oplog的新条目。如果丛节点在主节点的oplog中找不到自己要同步的点，那么就永久停止复制。这是会在日志中有如下异常：

replcation data too stale, halting

caught syncException 

调整oplog的大小，利用命令db.getReplicationInfo()可以查看分配了多少oplog空间，同时利用如下命令可以改变默认oplog大小

2.2 心跳检测以及故障转移

副本集的心跳检测有助于选举和故障转移。默认情况下，每个副本集成员每隔2s ping一次其他成员。这样一来系统就可以弄清自己的健康状况了。运行rs.status()也可以看到健康状态。

注意：在三个节点中，如果两个从节点都被杀掉了，在主节点的log会多如下一句话：

replSet can‘t see a majority of the set, 

replSet Secondary 

意思是没有多数节点，主节点就把自己降级为从节点；

三、管理

由于副本集存在许多潜在的复杂配置项，接下来我们详细介绍这些复杂配置项目；

3.1 配置细节

3.2 故障转移与恢复

3.3 部署策略

windows平台搭建Mongo数据库复制集（类似集群）（三）

标签：oar   3.3   接下来   还原   应用程序   数据   set   恢复   环境   

原文地址：http://www.cnblogs.com/GtShare/p/7661432.html