关于windows平台搭建Mongo数据库复制集这个话题，我已经在前面写了两篇博客
第一篇： 怎样在windows平台搭建Mongo数据库复制集
第二篇： 数据同步和故障自适应測试
在本篇里面，咱们重点总结一下复制集,以及分析一下它的工作原理
一、常见场景
应用程序和数据库之间的网络连接丢失
计划停机、断电、数据库服务硬盘故障等等
复制能够进行故障转移，复制能让你在副本间均衡读负载，保证复制节点与主节点保持同步
二、工作原理
副本集依赖于两个基础机制：oplog和“心跳”（heartbeat）.oplog让数据的复制成为可能，而“心跳”则监控健康情况并出发故障转移；
2.1 关于oplog
oplog是MongoDB复制的关键，oplog是一个固定集合，位于每一个复制节点的local数据库中，记录了对数据库的全部变更，每次client向主节点写入数据，就会自己主动向主节点的oplog里加入爱一条记录，当中博客了足够的信息来再现数据。
一旦写操作被拷贝到某个从节点上。从节点的oplog也会保存一条记录。
local数据库里保存了全部的副本集元数据和oplog，由于本身不能被复制。
那我们具体在看oplog
在此注意，每一个从节点都有一份自己的oplog，从节点使用长轮询的方式马上应用来自主节点oplog的新条目。假设丛节点在主节点的oplog中找不到自己要同步的点。那么就永久停止复制。
这是会在日志中有例如以下异常：
replcation data too stale, halting
caught syncException
调整oplog的大小，利用命令db.getReplicationInfo()能够查看分配了多少oplog空间。同一时候利用例如以下命令能够改变默认oplog大小
mongod.exe --replSet myapp --oplogSize 1024
2.2 心跳检測以及故障转移
副本集的心跳检測有助于选举和故障转移。
默认情况下，每一个副本集成员每隔2s ping一次其它成员。这样一来系统就能够弄清自己的健康状况了。执行rs.status()也能够看到健康状态。
注意：在三个节点中。假设两个从节点都被杀掉了，在主节点的log会多例如以下一句话：
replSet can't see a majority of the set,
replSet Secondary
意思是没有多数节点。主节点就把自己降级为从节点；
三、管理
因为副本集存在很多潜在的复杂配置项，接下来我们具体介绍这些复杂配置项目；
3.1 配置细节
利用config.members.push({})添加节点；
其它的一些方法：
3.2 故障转移与恢复
第一类就是包括全部的无损故障，直接重新启动服务就好。
另外一种是明白故障。主要是数据文件损坏等等，非正常关闭mongodb服务，假设不更改主机名称和port号则又一次运行数据目录，启动后数据后同步过来。假设改动属性。则要用rs.reconfig();
3.3 部署策略
包括两个副本和一个仲裁节点。在生产环境中。仲裁机节点能够执行在应用server上，而副本则执行在自己的机器上。对于多数环境而言。这样配置经济又高校
转载于:
关于windows平台搭建Mongo数据库复制集这个话题，我已经在前面写了两篇博客
第一篇： 怎样在windows平台搭建Mongo数据库复制集
第二篇： 数据同步和故障自适应測试
在本篇里面，咱们重点总结一下复制集,以及分析一下它的工作原理
一、常见场景
应用程序和数据库之间的网络连接丢失
计划停机、断电、数据库服务硬盘故障等等
复制能够进行故障转移，复制能让你在副本间均衡读负载，保证复制节点与主节点保持同步
二、工作原理
副本集依赖于两个基础机制：oplog和“心跳”（heartbeat）.oplog让数据的复制成为可能，而“心跳”则监控健康情况并出发故障转移；
2.1 关于oplog
oplog是MongoDB复制的关键，oplog是一个固定集合，位于每一个复制节点的local数据库中，记录了对数据库的全部变更，每次client向主节点写入数据，就会自己主动向主节点的oplog里加入爱一条记录，当中博客了足够的信息来再现数据。
一旦写操作被拷贝到某个从节点上。从节点的oplog也会保存一条记录。
local数据库里保存了全部的副本集元数据和oplog，由于本身不能被复制。
那我们具体在看oplog
在此注意，每一个从节点都有一份自己的oplog，从节点使用长轮询的方式马上应用来自主节点oplog的新条目。假设丛节点在主节点的oplog中找不到自己要同步的点。那么就永久停止复制。
这是会在日志中有例如以下异常：
replcation data too stale, halting
caught syncException
调整oplog的大小，利用命令db.getReplicationInfo()能够查看分配了多少oplog空间。同一时候利用例如以下命令能够改变默认oplog大小
mongod.exe --replSet myapp --oplogSize 1024
2.2 心跳检測以及故障转移
副本集的心跳检測有助于选举和故障转移。
默认情况下，每一个副本集成员每隔2s ping一次其它成员。这样一来系统就能够弄清自己的健康状况了。执行rs.status()也能够看到健康状态。
注意：在三个节点中。假设两个从节点都被杀掉了，在主节点的log会多例如以下一句话：
replSet can't see a majority of the set,
replSet Secondary
意思是没有多数节点。主节点就把自己降级为从节点；
三、管理
因为副本集存在很多潜在的复杂配置项，接下来我们具体介绍这些复杂配置项目；
3.1 配置细节
利用config.members.push({})添加节点；
其它的一些方法：
3.2 故障转移与恢复
第一类就是包括全部的无损故障，直接重新启动服务就好。
另外一种是明白故障。主要是数据文件损坏等等，非正常关闭mongodb服务，假设不更改主机名称和port号则又一次运行数据目录，启动后数据后同步过来。假设改动属性。则要用rs.reconfig();
3.3 部署策略
包括两个副本和一个仲裁节点。在生产环境中。仲裁机节点能够执行在应用server上，而副本则执行在自己的机器上。对于多数环境而言。这样配置经济又高校
