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

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

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

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

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

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

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

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

 

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

 

1、 建立四个节点，端口分别为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