MongoDB复制选举原理以及复制集的管理

MongoDB复制集的节点是通过选举产生主节点的。

复制的原理：复制是基于操作日志oplog，相当于MySQL的二进制日志，只记录发生改变的记录。复制将主节点的oplog日志同步并应用到其他从节点的过程

选举的原理：节点类型分为标准节点，被动节点，仲裁节点。

                     （1）只有标准节点可能被选为活跃（primary）节点,有选举权。被动节点有完整副本，不可能成为活跃节点，有选举权。仲裁节点不复制数据，不可能成为活跃节点，只有选举权。

                     （2）标准节点与被动节点的区别：priority值高者是标准节点，低着则为被动节点。

                     （3）选举规则是票数高者获胜，priority是优先权为0-1000的值，相当于额外增加0-1000的票数。选举结果：票数高者获胜：若票数相同，数据新者获胜

下图为MongoDB复制集节点间选举的结构图

下面我会通过几个实验来验证复制集的选举原理

一、 创建四个节点，端口分别为27017，27018，27019，27020，其中27017和27018作为标准节点，27019作为被动节点，27020作为仲裁节点

1 创建三个节点的数据存放路径和日志存放路径，其中27017为默认节点，所以不需要创建

2 对27017的配置文件进行更改，将可以访问的地址改为所有，同时开启复制集模块，将复制集名称定为kgcrs

3 第一个实例的配置文件改完之后复制三分，分别作为剩下三个实例的配置文件，完成之后再逐个修改

4 对第二个实例的配置文件进行修改，其中需要定义好数据的存放路径和日志文件的存放路径，接着将端口改为27018

4 接着更改第三个实例的配置文件，同样要修改文件路径，将端口改为27019

5 第四个实例将端口改为27020

6 开启这四个实例

7 查看这四个实例的端口

二 验证复制集的选举原理

（1）配置复制集的优先级

1 进入第一个实例，配置四个节点的复制集，设置两个标准节点，一个被动节点和一个仲裁节点

2 复制集配置完成后就可以进行初始化

3 初始化完成后查看该复制集的状态，可以看到27017变为了活跃节点，27018和27019变为了从节点，最后的27020是仲裁节点

（2）模拟节点故障

1 关闭活跃节点

2 进入另一个标准节点，可以发现第二个标准节点成为了活跃节点

3 接着我再关闭第二个标准节点

4 进入被动节点进行查看，可以发现角色并没有切换，依然是从节点

5 接着我再次将两个标准节点打开

6 进入第一个标准节点进行查看，可以发现它已经变成了活跃节点

最后总结：如果主节点出现故障，另一个标准节点将会选举成为新的主节点，如果所有标准节点都出现故障，被动节点也不会成为主节点

三 MongoDB复制集管理

（1）配置允许在从节点上读取数据

默认MongoDB复制集的从节点不能读取数据，可以使用rs.slaveOK()命令允许能够在从节点读取数据

1 在从节点上对数据库进行查看时并不会显示信息

2 执行rs.slaveOK()后再次进行查看便可以显示了

（2）查看复制状态信息

可以使用rs.printReplicationInfo()和rs.printSlaveReplicationInfo()命令来查看复制集状态

这里rs.printReplicationInfo()可以查看日志文件的大小，rs.printSlaveReplicationInfo()会显示有哪些节点会对数据进行复制，可以看到这里并没有仲裁节点，因为仲裁节点不会复制数据

（3）更改oplog大小

oplog即operations log的简写，储存在local数据库中。oplog中新操作会自动替换旧的操作，以保证oplog不会超出预设的大小。默认情况下，oplog大小会占用64位实例5%的可用磁盘空间

在MongoDB复制过程中，主节点应用业务操作修改到数据库中，然后记录这些操作到oplog中，从节点复制这些oplog，然后应用这些修改。这些操作是异步的。如果从节点的操作已经被主节点落下很远，oplog在从节点还没执行完，oplog可能已经轮滚一圈了，从节点跟不上同步，复制就会停下，从节点需要从节点需要重新做完整的同步，为了避免这种情况，尽量保证主节点的oplog足够大，能够存放相当长时间的操作记录。

可以调用db.runCommand命令来更改oplog的大小

1 这里我是在从节点上进行的操作，最后将该节点改为主节点即可

  首先查看当前日志的大小，这里显示为990M

2 关掉该节点，先将它从复制集中移除，让它变成一个单实例，然后才好进行操作

3 对该节点的配置文件进行更改

4 修改这个节点的端口号，接着注释掉复制集模块

5 文件更改完成后就可以启动该实例了

6 首先将该实例的日志文件进行完整性的备份

7 接着进入该实例的local数据下删除原有的oplog

8 接着重新创建一份oplog，大小由自己自行定义

9 再次关闭该节点，因为我们还是要把这个实例加到复制集当中

10 再次对主配置文件进行配置，将端口改为原来的27018，同时开启复制集模块，最后写上oplog的大小

11 文件配置完成后再次启动该实例

12 进入到这个实例中可以看到它已经被添加到复制集当中，角色为从，oplog大小为2048M

（4）部署认证复制

下面演示了如何部署带用户身份认证的MongoDB复制集

1 在活跃节点中创建root用户，密码为123

2 在四个实例的配置文件中分别开启密码认证模块，认证类型为文件认证，并且写上密码文件的路径，文件配置玩成后重启四个实例

3 依照配置文件里指定的路径分别创建四个密码文件，权限设为600

4 在没有输入验证的情况下查看下数据库信息和复制集的状态，可以看到是不会显示我们想要的信息的

5 在admin数据库下输入验证就可以进行查看

©著作权归作者所有：来自51CTO博客作者BK白小白的原创作品，如需转载，请注明出处，否则将追究法律责任

转：http://blog.51cto.com/13706760/2175709