MongoDB 副本集（Replica Set）是有自动故障恢复功能的主从集群，有一个Primary节点和一个或多个Secondary节点组成。副本集的工作模式如下图：
副本集中数据同步过程：
Primary节点写入数据，Secondary通过读取Primary的oplog得到复制信息，开始复制数据并且将复制信息写入到自己的oplog。如果某个操作失败，则备份节点停止从当前数据源复制数据。如果某个备份节点由于某些原因挂掉了，当重新启动后，就会自动从oplog的最后一个操作开始同步，同步完成后，将信息写入自己的oplog，由于复制操作是先复制数据，复制完成后再写入oplog，有可能相同的操作会同步两份，不过MongoDB在设计之初就考虑到这个问题，将oplog的同一个操作执行多次，与执行一次的效果是一样的。
简单的说就是：
当Primary节点完成数据操作后，Secondary会做出一系列的动作保证数据的同步：
1：检查自己local库的oplog.rs集合找出最近的时间戳。
2：检查Primary节点local库oplog.rs集合，找出大于此时间戳的记录。
3：将找到的记录插入到自己的oplog.rs集合中，并执行这些操作
环境搭建(以下为linux系统，windows系统同理)
1：下载安装程序，地址为：https://www.mongodb.org/downloads 根据需要下载合适的版本
2：解压，进入bin目录，创建配置文件(否则每次启动时都要输入各个参数)：mongod.conf
输入配置内容（仅供参考，各个参数请以实际需求调整）：
配置参数
##端口配置net: port: 27017##日志文件systemLog: destination: file path: "mongod.log" logAppend: truestorage: ##存储引擎 engine: wiredTiger ##数据文件存储位置 dbPath: /home/soft/mongodb-3.2.1/data ##数据会先写入日记文件，然后定时刷新到磁盘，生产环境必须打开 journal: enabled: true #enable at production wiredTiger: engineConfig: cacheSizeGB: 1 statisticsLogDelaySecs: 3600 journalCompressor: snappy directoryForIndexes: true collectionConfig: blockCompressor: snappy indexConfig: prefixCompression: trueprocessManagement:##以后台进程运行 fork: truereplication: ##副本集oplog大小 oplogSizeMB: 2048 ##副本集名称 replSetName: candao_qc secondaryIndexPrefetch: all enableMajorityReadConcern: false |
(启动前，记得有创建了dbPath: /home/soft/mongodb-3.2.1/data 这个目录)
3：以同样方式配置好其他2台服务器（官方推荐副本集成员为3或奇数个），分别运行./mongod -f mongod.conf 以启动mongodb。此时各个机器仍为单机模式，需要运行mongo程序进行初始化（且只能以此方式初始化）
4：在任意一台服务器上运行./mongo 输入命令：
初始化副本集
var conf = { "_id":"candao_qc", members : [{ "_id":0,//机器在副本集中的ID "host":"192.168.86.73:27017",//本机的IP地址 "priority":1,//优先级(最高优先级的节点总是会被选为主节点，默认值为1) },...]}rs.initiate(conf); //现在Mongo的primary中的priority是配置最高的，这样把primary停掉，再其他副本集种推举primary，当再把刚刚停掉的primary再次启动，由于它的priority是最高的，它会再次推举当选为primary.//只需要在任意一台服务器上进行执行，然后，这台服务器会把这个配置信息推送到其他服务器上 |
更多配置参数，请访问：https://docs.mongodb.org/manual/reference/replica-configuration/
5：输入 rs.status() 以查看副本集状态，如果没有错误，副本集会在短时间内初始化成功，正常的输出会是这样的：
有时可能需要修改副本集的配置信息，步骤如下：
1.在主机器上运行mongo 程序
2.输入 var conf = rs.conf();
3.conf.members[n] = {.........各种json参数 }//和初始化一样修改
4.rs.reconfig(conf, {force:true});
5.rs.status()查看副本集状态，是否修改成功
mongo的数字是从0开始，和java中的起始位置一样。
注意
在复制集运行的过程中，难免会遇到需要重启节点的场景，比如复制集版本升级、节点维护等，在重启节点的过程中，建议不要直接shutdown Primary，这样可能导致已经写入primary但未同步到secondary的数据丢失，过程类似如下：
shutdown Primary （shutdown会等待Secondary oplog追到10s以内）
Primary退出后，剩余的节点选举出一个新的Primary（复制集只包含1或2节点例外）
Primary重新启动，因为当前复制集已经有了新的Primary，这个Primary将以Secondary的角色运行。
从新的Primary同步的过程中，发现自己有无效的oplog，会先进行rollback。（rollback的数据只要不超过300M是可以找回的）
如果想不丢数据重启复制集，更优雅的打开方式应该是这样的
逐个重启复制集里所有的Secondary节点
对Primary发送stepDown命令，等待primary降级为Secondary
重启降级后的Primary
注意：如果Secondary的同步一直追不上Primary，步骤2可能会失败，这时应该重试步骤2直到stepDown成功；步骤2也可以通过调用replSetReconfig命令，来调整节点优先级来实现，让Secondary拥有更高的优先级，然后等待Primary降级为Secondary。
所以连接复制集一定不要直连Primary，否则在节点角色切换时不能正确容错，服务高可用无法保证。
#关闭
mmm:PRIMARY> use admin
switched to db admin
mmm:PRIMARY> db.shutdownServer()
本文出自 “萌哥，卡恩” 博客，请务必保留此出处http://xjf721.blog.51cto.com/889836/1902031
原文：http://xjf721.blog.51cto.com/889836/1902031