MongoDB复制集部署和基本管理

MongoDB复制集部署和基本管理

MongoDB复制集概述

复制集(Replica Sets)是额外的数据副本,是跨多个服务器同步数据的过程,复制集提供了冗余并增加了数据的可用性,通过复制集可以对硬件故障和中断服务进行恢复。

复制集由下列优点:

  • 让数据更安全
  • 高数据可用性(7*24)
  • 灾难恢复
  • 无停机维护(如备份、索引重建、故障转移)
  • 读缩放(额外的副本读取)
  • 副本集对应用程序是透明的

    复制集工作原理

    MongoDB的复制集至少需要两个节点。其中一个节点是主节点(Primary),负责处理客户端的请求,其余的都是从节点(Serondary),负责复制主节点上的数据。

MongoDB各个节点常见的搭配方式为:一主一从或者一主多从。主节点记录所有打操作到oplog中,从节点定期轮询主节点获取这些操作,然后对自己的数据副本执行这些操作。从而保证从节点的数据与主节点一致。如下图所示:

客户端在主节点写入数据,在主节点写入数据,主节点与从节点进行数据交互保证数据的一致性。如果其中一个节点出现故障,其他节点马上会将业务接过来,无需停机操作。

MongoDB复制集部署

配置多个实例

在上一篇的博客中已经讲解了MongoDB开启多实例的方法,这里就不多赘述,我们用相同的方法创建了四个MongoDB实例。在启动四个实例前,先要修改每个实例的配置文件,配置replSet参数值都为同一个值,这个值作为复制集的名称,具体操作如下:

[[email protected] ~]# vim /usr/local/mongodb/bin/mongodb1.conf
port=27017
dbpath=/data/mongodb1
logpath=/data/logs/mongodb/mongodb1.log
logappend=true
fork=true
maxConns=5000
replSet=kgcrs                     #配置复制集的名称

在其他的三个实例的配置文件中最后一行,加上相同的一句代码就行。开启四个实例进程。

[[email protected] ~]# export PATH=$PATH:/usr/local/mongodb/bin/
#由于之前重启过,重新设置环境变量
[[email protected] ~]# mongod -f /usr/local/mongodb/bin/mongodb1.conf
#开启端口号为27017的实例进程
2018-07-17T10:33:29.835+0800 I CONTROL  [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols ‘none‘
about to fork child process, waiting until server is ready for connections.
forked process: 3751
child process started successfully, parent exiting

初始化配置并启动复制集

启动完4个MongoDB实例后,下面介绍如何配置并启动MongoDB复制集。这里先配置包含3个节点的复制集(后面会再进行添加最后一个实例),Primary代表主节点。Secondary代表从节点

[[email protected] bin]# mongod -f /usr/local/mongodb/bin/mongodb2.conf --smallfiles
about to fork child process, waiting until server is ready for connections.
forked process: 20207
child process started successfully, parent exiting
[[email protected] bin]# mongod -f /usr/local/mongodb/bin/mongodb3.conf --smallfiles
about to fork child process, waiting until server is ready for connections.
forked process: 20230
child process started successfully, parent exiting
[[email protected] bin]# mongod -f /usr/local/mongodb/bin/mongodb4.conf --smallfiles
about to fork child process, waiting until server is ready for connections.
forked process: 20253
child process started successfully, parent exiting

可以看到四个实例都已经启动成功,对应的端口号都已经打开。然后进入到端口号为27017端口号的实例中。

[[email protected] bin]# mongo   #默认就是端口号为27017的实例
> cfg={"_id":"kgcrs","members":[{"_id":0,"host":"192.168.100.201:27017"},{"_id":1,"host":"192.168.100.201:27018"},{"_id":2,"host":"192.168.100.201:27019"}]}
#这句代码的意思就是向kgcrs的复制集中添加三个成员
> rs.initiate(cfg)
{ "ok" : 1 }
#对复制集进行初始化启动复制集,启动复制集后,可以通过rs.status()查看复制集的完整信息。




增加和删除节点

配置启动复制集后,还可以通过rs.add()和rs.remove()命令方便地添加和删除节点。

kgcrs:PRIMARY> rs.add("192.168.100.201:27020")
{ "ok" : 1 }
#可以看到27020端口的实例添加成功
kgcrs:PRIMARY> rs.remove("192.168.100.201:27019")
{ "ok" : 1 }
#可以看到27019端口的实例被删除了

MongoDB复制集切换

1、模拟故障自动切换

通过kill命令可以停止复制集的当前节点,然后查看主节点会自动切换到其他节点上,可以看到当前端口为27017的实例为主节点。

[[email protected] bin]# netstat -ntap| grep mongo
tcp        0      0 0.0.0.0:27019           0.0.0.0:*               LISTEN      20230/mongod
tcp        0      0 0.0.0.0:27020           0.0.0.0:*               LISTEN      20253/mongod
tcp        0      0 0.0.0.0:27017           0.0.0.0:*               LISTEN      20055/mongod
tcp        0      0 0.0.0.0:27018           0.0.0.0:*               LISTEN      20207/mongod
[[email protected] bin]# kill -9 20055 #kill掉27017端口的进程
kgcrs:SECONDARY> rs.status()
#可以看到现在的主节点是端口为27019的实例


2、手动进行主从切换

首先要先进入到主节点的实例中,只有主节点才有权限进行主从节点切换。

[[email protected] bin]# mongo --port 27019
kgcrs:PRIMARY> rs.freeze(30)   #暂停30s不参加选举
{ "ok" : 1 }
kgcrs:PRIMARY> rs.stepDown(60,30)  #告诉主节点交出主节点位置,然后维持从节点状态不少于60s,同时等待30s以使主节点和从节点日志同步,再次查看状态,发现主节点已经切换到另外一个实例中。
2018-07-18T15:52:53.254+0800 I NETWORK  [thread1] trying reconnect to 127.0.0.1:27019 (127.0.0.1) failed
2018-07-18T15:52:53.256+0800 I NETWORK  [thread1] reconnect 127.0.0.1:27019 (127.0.0.1) ok
kgcrs:SECONDARY> rs.status()

复制集的选举原理

复制的原理

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

选举的原理

节点类型分为标准(host)节点,被动(passive)节点和仲裁(abriter)节点。

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

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

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

配置复制集的优先级

重新配置4个节点的MongoDB复制集,设置两个标准节点,哟个被动节点和一个仲裁节点。这个设置要在主节点上配置。

kgcrs:PRIMARY> > cfg={"_id":"kgcrs","members":[{"_id":0,"host":"192.168.58.131:27017","priority":100},{"_id":1,"host":"192.168.58.131:27018","priority":100},{"_id":2,"host":"192.168.58.131:27019","priority":0},{"_id":3,"host":"192.168.58.131:27020","arbiterOnly":true}]}
#这句代码分别设置了四个实例的属性,优先级
kgcrs:PRIMARY> rs.reconfig(cfg)
{ "ok":1 }

可以看到现在端口27018的实例,现在是主节点。

模拟主节点故障

如果主节点出现故障,另外一个标准节点将会被选举为新的主节点。

[[email protected] ~]# mongod -f /usr/local/mongodb/bin/mongodb2.conf --shutdown
2018-07-22T09:20:02.706+0800 I CONTROL  [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols ‘none‘
killing process with pid: 9639
kgcrs:PRIMARY> rs.isMaster()


可以看到27017端口的实例已经成为主节点。

模拟所有标准节点都出现故障

如果所有标准节点出现故障,被动节点和仲裁节点都不能成为主节点。

[[email protected] ~]# mongod -f /usr/local/mongodb/bin/mongodb1.conf --shutdown
2018-07-22T09:24:08.290+0800 I CONTROL  [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols ‘none‘
killing process with pid: 9740
kgcrs:SECONDARY> rs.isMaster()

原文地址:http://blog.51cto.com/10693404/2148203

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

MongoDB复制集部署和基本管理的相关文章

mongodb复制集部署文档

一.安装环境:版本:MongoDB server version: 3.4.4安装源码包:mongodb-linux-x86_64-enterprise-rhel62-3.4.4.tgz系统环境:CentOS release 6.6 (Final)节点ip1: 172.16.88.195节点ip2: 172.16.88.196节点ip3: 172.16.88.190二.节点配置在三个节点分别操作:1.进安装目录 /usr/local/ 解压源码包: tar –zxvf mongodb-linux

MongoDB复制集及管理

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

部署MongoDB复制集(主从复制、读写分离、高可用)

MongoDB 复制集 复制集(Replica Sets)是额外的数据副本,是跨多个服务器同步数据的过程,复制集提供了冗余备份并提高了数据的可用性,通过复制集可以对硬件故障和中断的服务进行恢复. MongoDB 复制集工作原理 mongodb的复制集至少需要两个节点.其中一个是主节点(Primary),负责处理客户端请求,其余的都是从节点(Secondary),负责复制主节点上的数据. mongodb各个节点常见的搭配方式为:一主一从.一主多从.主节点记录其上的所有操作到 oplog 中,从节点

配置MongoDB复制集

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

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

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

每天一篇,深入学习MongoDB复制集

复制集概念: 复制集是额外的数据副本,是跨多个服务器同步数据的过程,提供了冗余并增加了数据的可用性,通过它可以对硬件故障和中断的服务进行数据恢复 复制集工作原理: MongoDB复制集最少需要两个节点. 主节点:负责处理客户端的请求, 从节点:负责复制主节点上的数据 搭配方式:一主一从或一主多从 注:客户端在主节点写入数据,在从节点读取数据,主从进行数据交互,保证数据的一致性 MongoDB复制集部署 (1)配置复制集 [[email protected] ~]# mkdir -p /data/

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

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

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