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

MongoDB复制集的选举原理

MongoDB复制的原理

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

MongoDB选举的原理

MongoDB的节点分为三种类型,分别为标准节点(host)、被动节点(passive)和仲裁节点(arbiter)

  • 只有标准节点才有可能被选举为活跃节点(主节点),拥有选举权。被动节点有完整副本,不可能成为活跃节点,具有选举权。仲裁节点不复制数据,不可能成为活跃节点,只有选举权。说白了就是只有标准节点才有可能被选举为主节点,即使在一个复制集中说有的标准节点都宕机,被动节点和仲裁节点也不会成为主节点。后续有示例演示验证。
  • 标准节点与被动节点的区别:priority值高者是标准节点,低者则为被动节点
  • 选举规则是票数高的获胜,priority是优先权0~1000的值,相当于额外增加0~1000的票数。选举结果:票数高者获胜;若票数相同,数据新者获胜。

MongoDB复制集节点间选举所示

前文链接
Yum安装MongoDB及数据库管理
配置MongoDB复制集

示例验证复制集选举原理

创建4个实例

创建新实例的path文件和dbpath的文件目录,并为日志文件设置权限

mkdir -p /data/mongodb/logs
//  path目录,因为在安装完成之后就会有一个实例,所以这里我们只需要创建三个实例即可
mkdir -p /data/mongodb/mongo{2,3,4}           //创建dbpath目录
touch /data/mongodb/logs/mongod{2,3,4}.log    //创建日志文件
chmod 777 /data/mongodb/logs/*.log            //为日志文件赋予权限

修改配置文件(/etc/mongod.conf)

path:
dbPath:
  port:
  bindIp:
replication:
  replSetName:      //修改配置文件中这五个项目的值

关闭防火墙及selinux防火墙

systemctl disable firewalld.service
systemctl stop firewalld.service
setenforce 0

启动实例

mongod -f /etc/mongod.conf

配置复制集

创建有四个节点组成的复制集,创建时设置优先级

本次复制集由四个节点组成,分别包括两个标准节点,一个被动节点,一个仲裁节点。

mongo //=进入数据库
chen={"_id":"chenrs","members":[{"_id":0,"host":"172.16.10.29:27017","priority":100},{"_id":1,"host":"172.16.10.29:27018","priority":100},{"_id":2,"host":"172.16.10.29:27019","priority":0},{"_id":3,"host":"172.16.10.29:27020","arbiterOnly":true}]}

初始化复制集

rs.initiate(chen)

查看各节点的的身份

rs.isMaster()

查看oplpog日志

此时对数据库进行一些增删改查的操作,注意在oplog日志中不会记录查询的语句,只会记录对数据库进行更改的语句

use stady                                      //使用stady库
db.abc.insert({"id":1,"name":"zhangsan"})      //向表abc中写入一条数据
db.abc.insert({"id":2,"name":"lisi"})          //再次插入一条数据
db.abc.find()                                  //查看表中内容
db.abc.update({"id":2},{$set:{"name":"jack"}}) //修改表数据
db.abc.remove({"id":1}                         //删除表数据

查看oplog中内容

use local
show collections    //可以看到其中有一个oplog.rs文件
db.oplog.rs.find()
//由于内容过多,在这里就不展示,查看之后就会发现,没有记录查询的记录,只有记录对数据库做更改的操作

模拟主节点故障

关闭主节点

kill -9 + 进程号                         //关闭主节点
mongod -f /etc/mongod4.conf --shutdown   //关闭主节点
mongo --port 27018
chenrs:PRIMARY> rs.status()      //此时该节点已经成为主节点
{
    "set" : "chenrs",
    "date" : ISODate("2018-07-16T05:30:04.152Z"),
    "myState" : 1,
        ···省略部分内容
    "members" : [
            "_id" : 0,
            "name" : "172.16.10.29:27017",
            "health" : 0,                 //健康值为0,处于非活跃状态
            "state" : 8,
            "stateStr" : "(not reachable/healthy)",
        ···省略部分内容
            "_id" : 1,
            "name" : "172.16.10.29:27018",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",    //此时1为主节点
        ···省略部分内容
            "_id" : 2,
            "name" : "172.16.10.29:27019",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
        ···省略部分内容
            "_id" : 3,
            "name" : "172.16.10.29:27020",
            "health" : 1,
            "state" : 7,
            "stateStr" : "ARBITER",
        ···省略部分内容
        ]

模拟另外一个主节点故障

mongod -f /etc/mongod2.conf --shutdown
mongo --port 27019
chenrs:SECONDARY> rs.status()     //仍处于secondary状态
{
    "set" : "chenrs",
    "date" : ISODate("2018-07-16T05:40:09.740Z"),
    "members" : [
        {
            "_id" : 0,
            "name" : "172.16.10.29:27017",
            "health" : 0,
            "state" : 8,
            "stateStr" : "(not reachable/healthy)",
            ···省略部分内容
            "_id" : 1,
            "name" : "172.16.10.29:27018",
            "health" : 0,
            "state" : 8,
            "stateStr" : "(not reachable/healthy)",
        ···省略部分内容
            "_id" : 2,
            "name" : "172.16.10.29:27019",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",          //即使两个标准节点都处于宕机状态,被动节点和仲裁节点也没有成为主节点
        ···省略部分内容
            "_id" : 3,
            "name" : "172.16.10.29:27020",
            "health" : 1,
            "state" : 7,
            "stateStr" : "ARBITER",
        ]
        ···省略部分内容

MongoDB复制集管理

配置允许在从节点读取数据

默认MongoDB复制集的从节点是不能读取数据的,但是可以使用密令来允许能够在从节点读取数据

rs.slaveOk()    //允许从节点能够读取数据

查看复制集状态信息

rs.help
rs.printReplicationInfo()        //查看oplog日志文件的大小及时间范围
rs.printSlaveReplicationInfo()   //查询节点及节点复制的时间

调整oplog日志文件大小

如果节点属于复制集成员,此时你想要修改oplog的大小是不被允许的,所以要将节点移出复制集想要修改日志文件的默认大小。此时要做的是首先要关闭节点的服务,然后退出复制集

关闭节点服务(属于离线升级)

use admin            //在复制集的从节点上做
db.shutdownServer()  //关闭服务,此时再想登陆该节点则会失败

节点退出复制集

注销掉replication的值和修改port值,将其作为单实例启动

vim /etc/mongod2.conf
#replication:
#  replSetName: chenrs
port: 27028
mongod -f /etc/mongod2.conf   //启动实例,此时该实例不属于复制集

完全备份oplog日志

mongodump --port 27028 --db local --collection ‘oplog.rs‘   //在linux界面操作

删除节点中oplog文件

> use local
> db.oplog.rs.drop()

重建oplog日志

db.runCommand( { create: "oplog.rs", capped: true, size: (2 * 1024 * 1024 * 1024) } )

再次关闭节点服务

use admin
db.shutdownServer() 

将节点加入到复制集

回调参数,同时要加一个参数指定日志文件大小

vim /etc/mongod2.conf
replication:
  replSetName: chenrs
  oplogSizeMB: 2048    //单位为兆
mongod -f /etc/mongod2.conf      //启动实例
mongo -port 27018                //进入实例

查看oplog大小

rs.printReplicationInfo()

对于日志文件大小的更改,只对该节点生效,其他节点仍然是默认值

部署认证复制

创建管理用户

use admin
db.createUser({"user":"root","pwd":"123123","roles":["root"]})

配置密钥验证

为了使其他的节点还能够和主节点进行同步,创建密钥文件使其他节点能够同步

  • 创建验证文件

    # cd /usr/bin/
    # echo "chenrs key"> chenrskey1
    # echo "chenrs key"> chenrskey2
    # echo "chenrs key"> chenrskey3
    # echo "chenrs key"> chenrskey4    //密钥内容自定义,但是要保证内容的一致性
    # chmod 600 chenrskey{1..4}        //设置文件权限,不设置在接下来的启动中会报错
  • 修改配置文件,开启mongodb的安全验证功能(四个配置文件都要修改,注意内容差异)
    vim /etc/mongod.conf
    security:
    keyFile: /usr/bin/chenrskey1     //每个节点的验证文件不同,要根据不同的节点修改
    clusterAuthMode: keyFile        //认证类型,密钥文件认证

  • 重启服务
    mongod -f /etc/mongod.conf --shutdown
    mongod -f /etc/mongod.conf              /其他几台的重启方式都相同,重复操作即可

    身份验证登陆(先验证主,再验证从)

    当你直接使用登陆命令登陆系统时,使用show dbs 是不能够查看数据的,此时就需要使用身份验证

    mongo --port 27018
    use admin
    db.auth("root","123123")

原文地址:http://blog.51cto.com/13643643/2144954

时间: 2024-08-05 17:19:34

MongoDB复制选举原理及复制集管理的相关文章

MongoDB 复制集 第 二 部 之【选举原理】

目录: 1·复制与选举的原理与验证2·oplog 日志调整3·配置复制集的优先级4·部署认证的复制5·总结 复制与选举的原理: 上一篇文章搭建了多台实例,部署成复制集,我们能知道复制集的作用,且进行了模拟故障,知道了从节点会主动切换为主节点,那么它是怎么推选出由哪一个从节点担任主节点呢? MongoDB 复制集的节点是通过选举产生主节点的,下面将介绍复制集节点间选举的过程: 1)复制的原理: 复制是基于操作日志 oplog ,相当于 MySQL 中的二进制日志,只会记录发生改变的记录.复制是将主

MySQL数据的主从复制、半同步复制和主主复制详解

一.MySQL复制概述 ⑴.MySQL数据的复制的基本介绍 目前MySQL数据库已经占去数据库市场上很大的份额,其一是由于MySQL数据的开源性和高性能,当然还有重要的一条就是免费~不过不知道还能免费多久,不容乐观的未来,但是我们还是要能熟练掌握MySQL数据的架构和安全备份等功能,毕竟现在它还算是开源界的老大吧! MySQL数据库支持同步复制.单向.异步复制,在复制的过程中一个服务器充当主服务,而一个或多个服务器充当从服务器.主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环

【亲测】教你如何搭建 MongoDB 复制集 + 选举原理

目录 1·MongoDB 复制集概述2·MongoDB 复制集部署3·MongoDB 复制集管理(添加.移除等)4·复制集的总结 MongoDB 复制集是什么? 之前的一片文章讲了 MongoDB 的安装和日常的操作,有兴趣的朋友可以看看 MongoDB 的安装和简单操作 1)什么是复制集? 复制集是额外的一种数据副本,是跨多个服务器同步数据的过程,通俗的说就是可以在不同的服务器上备份数据,专业点说就是冗灾处理.通过复制集可以对硬件和终端的服务进行恢复. 2)复制集的优势如下: 1-让数据更加安

MongoDB复制集管理优化

本文章将介绍MongoDB复制集的基本配置和管理,分别包括配置从节点可以读取数据.查看复制集状态.更改oplog大小.配置带认证的复制集 复制集的选举原理 复制是基于操作日志oplog,相当于Mysql中的二进制日志,只记录发生改变的记录.复制是将主节点的oplog日志同步并应用到其他从节点的过程. 选举的原理 节点的类型分为标准(host)节点.被动(passive)节点和仲裁(arbiter)节点. 标准节点可能被选举为活跃(primary)节点,有选举权. 被动节点有完整副本,不可能成为活

MongoDB复制集管理(后续)

简介:复制集:1:标准节点:参与primary选举2:被动节点:只能成为secend,不参与选举3:仲裁节点:负责投票选举,不存放数据 实验环境:2台标准节点 1台被动节点 1台仲裁点具体实验步骤:(前半部分实验为上次实验操作) [[email protected] ~]# mkdir -p /data/mongodb/mongodb{2,3,4}[[email protected] ~]# mkdir -p /data/mongodb/logs[[email protected] ~]# to

分布式系统之中心化复制集管理

文章首发于公众号 松花皮蛋的黑板报 作者就职于京东,在稳定性保障.敏捷开发.高级JAVA.微服务架构有深入的理解 为了避免分布式系统单点异常引发的系统可靠性和高可用问题,可行的办法就是数据冗余,也称为复制集,那么复制集是怎么管理的呢? 实际上管理方式可以有去中心化副本集和中心化副本集两种. 去中心化副本集的特点是,无中心节点,所有节点地位平等,都可以接受读写请求,通过协商达到数据的一致.这种方式可用性比较强,只要大多数节点存活就可以对外提供服务,缺点也很明显,它的协议流程复杂. 中心化副本集的特

认识复制及原理

作用: 利用从库读能力***** 从库做master故障的接管****** 从库做备份减少业务的影响 复制升级 slave进行特殊sql统计 复制配置: 一个简单的主从复制 SBR复制配置 RBR复制配置 MIX复制配置 GTID复制配置 传统与GTID的比较 复制中配置管理 复制实现原理 复制结构缺点分析 (1)简单的主从复制 MySQL版本:MySQL-5.6.22 角色   ip port      server-id    必备条件 master 192.168.0.11  113306

MySQL 5.7 并行复制实现原理与调优

MySQL 5.7并行复制时代 众所周知,MySQL的复制延迟是一直被诟病的问题之一,然而在Inside君之前的两篇博客中(1,2)中都已经提到了MySQL 5.7版本已经支持“真正”的并行复制功能,官方称为为enhanced multi-threaded slave(简称MTS),因此复制延迟问题已经得到了极大的改进,甚至在Inside君所在的网易电商应用中已经完全消除了之前延迟长达几小时的问题.然而,Inside君发现还是有很部分小伙伴不了解这个足以载入史册的“伟大”的特性,故作分享.总之,

Mysql的AB复制(主从复制)原理及实现

Mysql复制(replication)是一个异步的复制,从一个Mysql 实例(Master)复制到另一个Mysql 实例(Slave).实现整个主从复制,需要由Master服务器上的IO进程,和Slave服务器上的Sql进程和IO进程共从完成.         要实现主从复制,首先必须打开Master端的binary log(bin-log)功能,因为整个MySQL 复制过程实际上就是Slave从Master端获取相应的二进制日志,然后再在自己slave端完全顺序的执行日志中所记录的各种操作