MongoDB复制集管理优化

本文章将介绍MongoDB复制集的基本配置和管理,分别包括配置从节点可以读取数据、查看复制集状态、更改oplog大小、配置带认证的复制集

  • 复制集的选举原理

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

  • 选举的原理

节点的类型分为标准(host)节点、被动(passive)节点和仲裁(arbiter)节点。

  • 标准节点可能被选举为活跃(primary)节点,有选举权。
  • 被动节点有完整副本,不可能成为活跃节点,有选举权。
  • 仲裁节点不复制数据,不可能成为活跃节点,只有选举权。
  • 标准节点和被动节点的区别:priority值高的是标准节点,低的是被动节点。
  • 选举规则是票高者获胜,priority是优先权为0~1000的值,相当于额外增加0~1000的票数。选举结果:票高者获胜。若票数相同:数据新者获胜。
  • 配置复制集的优先级
  • 先创建4个实例 教程
  • 设置2个标准节点,一个被动节点,一个仲裁节点。
    > cfg={"_id":"kgcrs","members":[{"_id":0,"host":"192.168.86.128:27017","priority":100},{"_id":1,"host":"192.168.86.128:27018","priority":100},{"_id":2,"host":"192.168.86.128:27019","priority":0},{"_id":3,"host":"192.168.86.128:27020","arbiterOnly":true}]}

    > rs.initiate(cfg)    //初始化配置
    > rs.isMaster()    //查看复制集的状态

  • 模拟主节点故障

    # mongod -f /etc/mongod.conf --shutdown   //主节点服务关掉
    # mongo --port 27018
    > rs.isMaster()   //查看节点的身份状态  主节点已经换到27018

  • 模拟所有标准节点故障
    # mongod -f /etc/mongod.conf --shutdown
    # mongod -f /etc/mongod2.conf --shutdown
    # mongo --port 27019
    > rs.isMaster()   //查看节点身份状态 可以看到主节点没有了(当所有标准节点故障,被动节点也不能成为主节点)

  • 允许从节点读取数据
  • 默认的MongoDB复制集的基本配置和管理,可以使用rs.slaveOK() 命令允许能够在从节点读取数据。
    # mongo --port 27018
    > rs.slaveOk()        //允许默认从节点读取数据
    > show dbs

  • 查看复制状态信息
  • 查看Master的oplog元数据信息:
    > rs.printReplicationInfo()
  • 查看Slave的同步状态:
    > rs.printSlaveReplicationInfo()
  • 查看主从配置信息:
    > rs.conf() //或db.system.replset.find()

  • 更改oplog大小
  • oplog简介:

oplog:operations log的简写,存储在一个特殊的数据库中(local),oplog就存储在其中的oplog.$main集合里面,这个集合是一个固定集合,新操作会自动替换旧的操作,以保证oplog不会超过预设的大小,其中的每个文档都代表主节点上执行的一个操作,oplog会包含所有对数据有修改的的操作(查询操作不会记录),默认下,oplog大小会占用64位的实例5%的可用磁盘空间。
mongo复制的过程:主节点应用业务操作修改到数据库中,然后记录这些操作到oplog中,从节点复制这些oplog,然后应用这些修改。ps:这些操作是异步的。如果从节点的操作已经被主节点落下很远,oplog日志在从节点还没执行完,oplog可能已经轮滚一圈了,从节点跟不上同步,复制就会停下,从节点需要重新做完整的同步,为了避免此种情况,尽量保证主节点的oplog足够大,能够存放相当长时间的操作记录。


    > use local
    >  db.oplog.rs.find()             //查看.oplog
    > db.oplog.rs.stats()             //查看.oplog内容
    > rs.printReplicationInfo()    //查询oplog的大小及保存的操作记录持续的时长

  • 这里仅是单实例27018的修改,其他实例参照如下
  • 关闭服务
     # mongo --port 27018
     > use admin
     > db.shutdownServer()      //关闭服务
  • 注销replication:相关启动参数,并修改port端口号27028

    # vim /etc/mongod2.conf 

  • 备份当前节点的所有oplog记录
    # mongodump --port 27028 --db local --collection ‘oplog.rs‘
    # mongo --port 27028
    > use local
    > db.oplog.rs.drop()    //删除原来的oplog
    > db.runCommand( { create: "oplog.rs", capped: true, size: (2 * 1024 * 1024 * 1024) } )    //创建新的
    > use admin
    > db.shutdownServer()


  • 开启replication:相关启动参数,并修改port端口号27018
    # vim /etc/mongod2.conf 

    mongod -f /etc/mongod2.conf

    mongo //进入主节点

    rs.stepDown() //让出主节点位置

  • 部署认证复制
  • 在主节点创建root用户
    kgcrs:PRIMARY> use admin
    kgcrs:PRIMARY> db.createUser({"user":"root","pwd":"123","roles":["root"]})
  • 生成4个实例的密钥文件
     # cd /usr/bin/
     # echo "kgcrs key"> kgcrskey1
     # echo "kgcrs key"> kgcrskey2
     # echo "kgcrs key"> kgcrskey3
     # echo "kgcrs key"> kgcrskey4
     # chmod 600 kgcrskey{1..4}
    
     # vim /etc/mongod.conf  (mongod2.conf /mongod3.conf/mongod4.conf 都要改)
    security:
       keyFile: /usr/bin/kgcrskey1     //(分别为 kgcrskey2、kgcrskey3、kgcrskey4)
       clusterAuthMode: keyFile
  • 4个实例依次重启
    # mongod -f /etc/mongod.conf --shutdown
    # mongod -f /etc/mongod.conf
  • 进入主节点验证
    > show dbs   #无法查看数据库
    > rs.status()   #无法查看复制集

    > use admin    #身份登录验证
    > db.auth("root","123")
    > rs.status()  #可以查看数据库
    > show dbs    #可以查看复制集

原文地址:http://blog.51cto.com/13630803/2145010

时间: 2024-07-31 09:09:14

MongoDB复制集管理优化的相关文章

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

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

MongoDB复制集的选举原理 MongoDB复制的原理 MongoDB的复制是基于操作日志oplog,相当于MySQL中的二进制日志,只记录发生改变的记录.复制是将主节点的oplog日志同步并应用到其他从节点的过程. MongoDB选举的原理 MongoDB的节点分为三种类型,分别为标准节点(host).被动节点(passive)和仲裁节点(arbiter) 只有标准节点才有可能被选举为活跃节点(主节点),拥有选举权.被动节点有完整副本,不可能成为活跃节点,具有选举权.仲裁节点不复制数据,不可

MongoDB复制集及管理

MongoDB复制集及管理 MongoDB复制集概述 什么是复制集 复制集是额外的数据副本,是跨多个服务器同步数据的过程,复制集提供了冗余并增加了数据可用性,通过复制集可以对硬件故障和中断的服务进行恢复. 复制集的优点如下: 1).让数据更安全:2).高数据可用性:3).灾难恢复:4).无停机恢复(如备份.索引重建.故障转移):5).读缩放(额外的副本读取):6).副本集对应用程序是透明的: 复制集工作原理 MongoDB的复制集至少需要两个节点.其中一个是主节点(Primary),负责处理客户

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

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

MongoDB复制集部署和基本管理

MongoDB复制集部署和基本管理 MongoDB复制集概述 复制集(Replica Sets)是额外的数据副本,是跨多个服务器同步数据的过程,复制集提供了冗余并增加了数据的可用性,通过复制集可以对硬件故障和中断服务进行恢复. 复制集由下列优点: 让数据更安全 高数据可用性(7*24) 灾难恢复 无停机维护(如备份.索引重建.故障转移) 读缩放(额外的副本读取) 副本集对应用程序是透明的 复制集工作原理 MongoDB的复制集至少需要两个节点.其中一个节点是主节点(Primary),负责处理客户

MongoDB复制集架构

MongoDB复制集架构 由数据结点,投票结点组成,需要配置集群信息,可自动检测集群中的结点健康状态,当有结点出故障时,自动下线和切换主从结点.适用于数据量较大,高可用服务 通常,为了防止单点故障应用程序需要做集群.然而在数据库中除了防止单点故障,还需要做到数据库备份,读写分离,故障转移等.而 MongoDB 的 Replica Set 恰恰都能满足这些要求. Replica Set角色 Replica Set 的成员是一堆有着同样的数据内容 mongod 的实例集合,包含以下三类角色: 主节点

MongoDB复制集技术

第1章 MongoDB复制集简介: 一组MongoDB复制集,就是一组MongoDB进程,这些进程维护同一个数据集合,复制集提供了数据冗余和高等级的可靠性,这是生产部署的基础 1.1 复制集的目的: 保证数据在生产部署是的冗余和可靠性,通过在不同的机器上保存副本来保证数据的不会因为单间损坏而丢失,能够随时应对数据丢失或者机器损坏带来的风险 还可以提高用户读写数据的性能,提高整个系统的负载 1.2 简单介绍: 1.      一组复制集就是一组MongoDB实例掌管同一个数据集,实例可以在不同的机

配置MongoDB复制集

什么是复制集? 复制集是额外的数据副本,是跨多个服务器同步数据的过程,复制集提供了冗余并增加了数据可用性,通过复制集可以对硬件故障和中断的服务进行恢复.复制集的优势如下: 让数据更安全 高数据可用性(24*7) 灾难恢复 无停机维护(如备份.索引重建.故障转移) 读缩放(额外的副本读取) 副本集对应用程序是透明的 复制集工作原理 MongoDB的复制集至少需要两个节点.其中一个是主节点(Primary),负责处理客户端的请求,其余的都是从节点(Secondary),负责复制主节点上的数据.Mon

MongoDB复制集(实现选举复制、故障切换、升级oplog大小、认证复制)

什么是复制集? 复制集(replica sets)是额外的数据副本,是跨多个服务器同步数据的过程,复制集提供了冗余并增加了数据可用性,通过复制集可以对硬件故障和中断服务进行恢复. 复制集的优势 让数据更安全. 高数据可用性. 灾难恢复. 无停机维护(如备份.索引重建.故障转移) 读缩放(额外的副本读取) 副本集对应用程序是透明的. 复制集概述 MongoDB复制集是额外的数据副本,复制集提供了冗余和增加数据可用性. MongoDB的复制集至少需要两个节点,其中主节点负责处理客户端请求,从节点负责