MongoDB副本集的搭建

wedsddsa

MongoDB 副本集（Replica Set）是有自动故障恢复功能的主从集群，有一个Primary节点和一个或多个Secondary节点组成。副本集的工作模式如下图：

Diagram of default routing of reads and writes to the primary.

副本集中数据同步过程：

        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: true
storage:
   ##存储引擎
   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: true
processManagement:
##以后台进程运行
   fork: true
replication:
  ##副本集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() 以查看副本集状态，如果没有错误，副本集会在短时间内初始化成功，正常的输出会是这样的：

image2016-4-6%2018%3A7%3A50.png?version=

   有时可能需要修改副本集的配置信息，步骤如下：

   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()