mongodb 004——复制集RS及管理操作

4.1 基本原理

 基本构成是1主2从的结构，自带互相监控投票机制。
 如果发生主库宕机，复制集内部会进行投票选举，选择一个新的主库代替原有主库进行对外提供服务。同时复制集会自动通知客户端程序，主库已经发生切换了，应用就会连接到新库。
 （1）Primary：在一个复制集中只有并且必须有一个主节点，主节点也是众多实例中唯一可以接收客户端写操作的节点，当然也可以进行读操作
 （2）Secondary：从节点会复制主节点的操作，以获取完全一致的数据集。客户端不能够直接对从节点进行写操作，但是可以进行读操作，这个需要通过复制集选项进行设置。
 （3）投票节点：投票节点并不含有复制集中的数据集副本，且也无法升职为主节点。投票节点的存在是为了使复制集中的节点数量为奇数，这样保证在进行投票的时候不会出现票数相同的情况。如果添加了一个节点后，总节点数为偶数，那么就需要相应的增加一个投票节点。
 （4）arbiter：实际应用中，应用在资源有限(MongodDB需要运行在高性能服务器上)的情况下，不得不采用一主一从的架构，那么额外配置一台普通的服务器(即Arbiter)，一样可以允许主从两台机器挂一台。因为Arbiter可以运行在普通的机器上，是因为，Arbiter没有数据，既不同步复制主服务器的数据，也不给客户端提供读数据能力，它的存在目的是通过参与Leader投票，作为一台凑数的服务器来使用。

 主节点上的所有 数据库状态改变 的操作，称为oplog（operation log，主节点操作记录）。oplog存储在local数据库的"oplog.rs"表中。副本集中备份节点异步的从主节点同步oplog，然后重新执行它记录的操作，以此达到了数据同步的作用。后续写oplog。

4.2 Replication Set配置规划

三个以上的mongodb节点
 多实例：
（1）多个端口：28017/28018/28019/28020（第一次配置1主2从，第二次配置1主1从1个arbiter节点）
（2）多套目录

4.2.2 目录创建

su - mongod
mkdir -p /mongodb/28017/conf  /mongodb/28017/data  /mongodb/28017/log
mkdir -p /mongodb/28018/conf  /mongodb/28018/data  /mongodb/28018/log
mkdir -p /mongodb/28019/conf  /mongodb/28019/data  /mongodb/28019/log  
mkdir -p /mongodb/28020/conf  /mongodb/28020/data  /mongodb/28020/log

4.2.3 修改各节点配置文件

[mongodb@node1 mongodb]$ vi /mongodb/28017/conf/mongod.conf
systemLog:
    destination: file
    path: "/mongodb/28017/log/mongodb.log"
    logAppend: true
storage:
    dbPath: "/mongodb/28017/data"
    journal:
        enabled: true
    directoryPerDB: true
    #engine: wiredTiger
    wiredTiger:
        engineConfig:
            cacheSizeGB: 2
            directoryForIndexes: true
        collectionConfig:
            blockCompressor: zlib
        indexConfig:
            prefixCompression: true
processManagement:
    fork: true
net:
    bindIp