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

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

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

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

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

                     (2)标准节点与被动节点的区别:priority值高者是标准节点,低着则为被动节点。

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

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

MongoDB复制选举原理以及复制集的管理_第1张图片

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

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

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

MongoDB复制选举原理以及复制集的管理_第2张图片

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

MongoDB复制选举原理以及复制集的管理_第3张图片
MongoDB复制选举原理以及复制集的管理_第4张图片

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

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

MongoDB复制选举原理以及复制集的管理_第5张图片
MongoDB复制选举原理以及复制集的管理_第6张图片

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

MongoDB复制选举原理以及复制集的管理_第7张图片
MongoDB复制选举原理以及复制集的管理_第8张图片

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

MongoDB复制选举原理以及复制集的管理_第9张图片
MongoDB复制选举原理以及复制集的管理_第10张图片

6 开启这四个实例

MongoDB复制选举原理以及复制集的管理_第11张图片

7 查看这四个实例的端口

MongoDB复制选举原理以及复制集的管理_第12张图片

二 验证复制集的选举原理

(1)配置复制集的优先级

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

MongoDB复制选举原理以及复制集的管理_第13张图片

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

MongoDB复制选举原理以及复制集的管理_第14张图片

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

MongoDB复制选举原理以及复制集的管理_第15张图片
MongoDB复制选举原理以及复制集的管理_第16张图片

(2)模拟节点故障

1 关闭活跃节点

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

MongoDB复制选举原理以及复制集的管理_第17张图片

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

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

MongoDB复制选举原理以及复制集的管理_第18张图片

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

MongoDB复制选举原理以及复制集的管理_第19张图片

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

MongoDB复制选举原理以及复制集的管理_第20张图片

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

三 MongoDB复制集管理

(1)配置允许在从节点上读取数据

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

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

MongoDB复制选举原理以及复制集的管理_第21张图片

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

MongoDB复制选举原理以及复制集的管理_第22张图片

(2)查看复制状态信息

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

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

MongoDB复制选举原理以及复制集的管理_第23张图片

(3)更改oplog大小

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

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

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

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

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

MongoDB复制选举原理以及复制集的管理_第24张图片

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

MongoDB复制选举原理以及复制集的管理_第25张图片

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

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

MongoDB复制选举原理以及复制集的管理_第26张图片

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

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

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

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

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

MongoDB复制选举原理以及复制集的管理_第27张图片

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

MongoDB复制选举原理以及复制集的管理_第28张图片

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

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

MongoDB复制选举原理以及复制集的管理_第29张图片

(4)部署认证复制

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

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

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

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

MongoDB复制选举原理以及复制集的管理_第30张图片

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

MongoDB复制选举原理以及复制集的管理_第31张图片
MongoDB复制选举原理以及复制集的管理_第32张图片

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

MongoDB复制选举原理以及复制集的管理_第33张图片

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

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

你可能感兴趣的:(MongoDB复制选举原理以及复制集的管理)