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

创新互联建站是一家以网站建设、网页设计、品牌设计、软件运维、成都网站推广、小程序App开发等移动开发为一体互联网公司。已累计为成都酒店设计等众行业中小客户提供优质的互联网建站和软件开发服务。

复制的原理：复制是基于操作日志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数据库下输入验证就可以进行查看

另外有需要云服务器可以了解下创新互联cdcxhl.cn，海内外云服务器15元起步，三天无理由+7*72小时售后在线，公司持有idc许可证，提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案，具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势，专为企业上云打造定制，能够满足用户丰富、多元化的应用场景需求。

文章名称：MongoDB复制选举原理以及复制集的管理-创新互联
转载注明：http://chengdu.cdxwcx.cn/article/dgeoej.html