zoukankan      html  css  js  c++  java
  • MongoDB 3.2复制集单节点部署(四)

    MongoDB在单节点中也可以做复制集,但是仅限于测试实验,最大的好处就是部署方便快速,可以随便添加新节点,节省资源。在这里我使用的是MongoDB 3.2版本进行复制集实验(但MongoDB配置文件使用的是老版本格式),一共使用三个节点,一个是主节点(PRIMARY),一个是从节点(SECONDARY),一个是投票节点(ARBITER)。如下图:

    MongoDB 3.2复制集单节点部署(四)

    一、实验环境

    1)节点信息:192.168.60.10

    3)节点确保iptables和selinux已关闭

    二、安装MongoDB 3.2

    PS:需要的软件包可以去https://repo.mongodb.org/yum/redhat/下载,MongoDB的安装很简单,怎么安装都成。

    三、配置单点复制集(启动三个套接字)

    1)创建所需要的目录

    2)创建三个配置文件

    192.168.60.10:27017

    192.168.60.10:27018

    192.168.60.10:27019

    PS:更多具体参数详细含义请看《MongoDB命令行选项介绍》

    3)启动集群(所有节点)

    查看进程三个节点都启动

    4)选择一个节点做主节点(可以随意选择一个,这里我使用21017)

    5)初始化27017节点

    5.1.为复制集初始化建立配置文档

    5.2.更新配置文档参数,设置27019为arbiterOnly(投票节点)

    PS:上面是把复制集初始化配置文档赋值给config变量,这里是通过membes数组的索引来修改节点属性,数组索引从0开始。

    具体的配置文档说明请看《MongoDB复制集配置文档介绍》

    5.3.使用rs.initiate(cfg)初始化集群

    这里使用rs.initiate(config)初始化集群,config文件为我们上面定义的。这里的ok返回值为1表示命令执行成功,如果为0则表示没有执行成功。跟Linux中的状态值刚好相反。现在可以使用rs.conf()方法返回配置文件内容。

    在Mongodb3.2版本中,相比之前的版本rs.conf返回配置文件的信息更加详细了。把”arbiterOnly”、”buildIndexes”、”hidden”、”priority”、”tags”、”slaveDelay”、”votes”的默认值都给真是出来了,具体的含义看《MongoDB复制集配置文档介绍》。

    5.4.查看集群状态

    我们的集群中有三个节点,由状态返回值可以看出27017为PRIMARY节点,而27018为SECONDARY节点,而27019为我们设置的ARBITER节点。这里我们发现mongodb的角标已经变了,变成了复制集名称加上当前节点的状态。同样如果登陆27018和27019会发现都发生了变化。

    5.5.查看主节点local库

    这里我们看一下本地的local库,每一个mongod实例都有自己的local数据库,其中存储了复制进程所用的数据和其他实例单独的信息,local数据库对于复制时不可见的,local数据库将不会被复制。

    进入到local库可以看到一些集合和索引文件,其中startup_log 是一个固定集合,该集合主要是用来诊断的(每个mongod 实例向 startup_log 插入一条有关mongod实例自身和host信息的诊断信息);system.replset保存了复制集的配置文档信息(就是我们上面定义的config),跟rs.conf()返回的信息一样;oplog.rs是一个存储了oplog的固定集合,大小为我们在配置文件中设置的大小;replset.minvalid包含了复制集内部定位复制集状态信息;slaves包含了复制集每个节点和与其通讯的最后时间戳。如果该集合过时了,我们可以通过删除该节点来让复制集自动刷新生成。

    6)验证复制集

    192.168.60.10:27017插入数据

    然后我们来看一下主节点的数据目录(WiredTiger存储引擎为例)

    这里我们可以看到,由于使用了WiredTiger存储引擎,数据存储格式都跟MongoDB 2.6(使用MMAPV1存储引擎)不同了。

    192.168.60.10:27018同步数据

    我们看到数据已经同步过来了,但是如果我们不是通过驱动连接从节点的话,我们查看数据时会报错,说我们不是master节点,且slaveOK=false,所以查看不了。MongoDB在数据一致性上确实下了很大的功夫啊。那么也就是说如果从节点想查看数据就需要开启slaveOK,并且在从节点上是无法进行写入操作的。然后我们开启rs.slaveOk(1)立马就可以查看同步的数据了。

    192.168.60.10:27019投票节点

    连接到投票节点,我们可以看到PRIMARY上的数据没有同步到投票节点上来,没有ywnds这个库。但是这里需要说明的是,我们可以看到arbiter虽然不同步数据但是local库却有system.indexes和system.replset这两个文件。另外我们可以发现local数据的大小为0.078GB(80M),库物理文件的第一个文件默认大小为64M,而命名空间文件为16M。

    四、按照功能来区分复制集成员

    从上面的分析可以看出三个节点的不同之处,也可以这么说,上面我们是按照数据来区分不同的复制集节点,那么下面我们按照功能上来区分各个节点。先来简单说一下各个节点状态的不同所能提供的功能有哪些?

    主节点(PRIMARY):默认提供读写服务的节点。

    从节点(SECONDARY):提供读服务的节点,但可以提供多样性服务,如可以转为“隐藏节点”对程序不可见、转为“延时节点”延时复制节点、转为“投票节点”具有投票权但不是arbiter。

    投票节点(ARBITER):ARBITER节点,无数据,仅作选举和充当复制集节点、也称它为选举节点。

    五、复制集自动容灾

    Mongodb复制集最大的特点就是可以自动容灾,这个特性是从主从复制的架构上改变而来,简单来说就是当复制集(3节点)中如果PRIMARY发生故障,其他节点无法探测到它的心跳信息时,复制集就会产生从新投票选出一个新的PRIAMRY提供服务。下面我们来模拟一下MongoDB的自动故障转移功能。

    我们连接到27017主机上,此时的27017是PRIMARY

    我们连接到27018主机上,此时的27018是SECONDARY

    我们连接到27019主机上,此时的27019是ARBITER

    模拟主节点宕机,kill掉27017的进程。

    然后登录27018主机上,看看此时的SECONDARY已经转为PRIMARY了,但是这个过程会有短暂的断开。

    而27019主机上ARBITER还是ARBITER节点。

    有兴趣可以通过show log rs命令查看复制集的日志信息,看看这个过程是怎么进行的。这就是MongoDB三节点(一主一从一投票或一主二从)复制集的故障转移功能,是不是很强大。当然除了复制集内部自动选举之外,我们也可以进行人工干预,使用rs.stepdown()方法可以手动切换。

  • 相关阅读:
    Vue双向绑定的实现原理系列(一):Object.defineproperty
    TCP协议中的三次握手和四次挥手
    一切事物皆对象_进阶篇
    一切事物皆对象_基础篇
    自成一派的正则表达式
    超好用的模块
    软件目录开发规范
    迭代器与生成器
    不怎么好吃的语法糖
    你可造什么是函数
  • 原文地址:https://www.cnblogs.com/ExMan/p/9665098.html
Copyright © 2011-2022 走看看