Mongodb5节点异地两中心故障转移恢复测试案例

架构方式:5节点,主中心(2数据1仲裁),备中心(1数据1仲裁)

1基本情况

操作系统:Red Hat Enterprise Linux Server release 6.3 (Santiago)

Mongodb版本:db version v3.6.3

Mongodb架构:

Ip,端口规划

"hosts" : [##数据节点

"*114:28001",#主中心

"*114:28002",#主中心

"*114:28004"#备份中心

],

"arbiters" : [##仲裁节点

"*114:28003",#主中心

"*114:28005"#备份中心

],

2 mongodb

配置文件,其他配置文件28001替换为28002~28007

注意相应的data,log等数据目录要存在,记住,所有的mongodb里面执行的命令,都要有返回ok为1才成功。

[root@mysqlt1 ~]# cat /data/mongodb/conf/28001.conf

port=28001

bind_ip=*

logpath=/data/mongodb/log/28001.log

dbpath=/data/mongodb/data/28001/

logappend=true

pidfilepath=/data/mongodb/28001.pid

fork=true

oplogSize=1024

replSet=MyMongo

[root@mysqlt1 conf]# ll /data/mongodb/conf/

total 32

-rw-r--r-- 1 root root 192 Oct 16 02:48 28001.conf

-rw-r--r-- 1 root root 225 Oct 16 07:21 28002.conf

-rw-r--r-- 1 root root 192 Oct 16 02:48 28003.conf

-rw-r--r-- 1 root root 192 Oct 11 03:37 28004.conf

-rw-r--r-- 1 root root 192 Oct 11 03:38 28005.conf

-rw-r--r-- 1 root root 192 Oct 16 07:18 28006.conf

-rw-r--r-- 1 root root 192 Oct 16 08:15 28007.conf

启动5个节点

[root@mysqlt1 data]# /usr/local/mongodb/bin/mongod -f /data/mongodb/conf/28001.conf

[root@mysqlt1 data]# /usr/local/mongodb/bin/mongod -f /data/mongodb/conf/28002.conf

[root@mysqlt1 data]# /usr/local/mongodb/bin/mongod -f /data/mongodb/conf/28003.conf

[root@mysqlt1 data]# /usr/local/mongodb/bin/mongod -f /data/mongodb/conf/28004.conf

[root@mysqlt1 data]# /usr/local/mongodb/bin/mongod -f /data/mongodb/conf/28005.conf

3 测试主中心全部宕机的情况

[root@mysqlt1 ~]# /usr/local/mongodb/bin/mongod  --shutdown -f /data/mongodb/conf/28001.conf

[root@mysqlt1 ~]# /usr/local/mongodb/bin/mongod  --shutdown -f /data/mongodb/conf/28002.conf

[root@mysqlt1 ~]# /usr/local/mongodb/bin/mongod  --shutdown -f /data/mongodb/conf/28003.conf

只剩备份中心的2个节点,这时候变为secondry,备份中心只能读取,不能写入

两种解决方案
1 把备份中心的secondry节点,作为单节点,去掉参数replSet重新启动,可以继续使用,但是由于单节点缺少oplog,后面主中心恢复,备份中心的数据不能恢复到整个副本集中,可以考虑备份方式(复杂,这里还有第二种方式)。

2 在备份中心,启动2个新的仲裁节点,强制加入副本集,使secondry节点变为primary节点,详细的操作方式

一:启动备份中心的2个新节点(28006,28007)

二:在备份中心的secondry节点,重新配置副本集,加入2个仲裁节点

MyMongo:SECONDARY> use admin

MyMongo:SECONDARY> config = {

"_id":"MyMongo",

members:[

{"_id":0,host:"*:28001"},

{"_id":1,host:"*:28002"},

{"_id":2,host:"*:28003", arbiterOnly: true},

{"_id":3,host:"*:28004"},

{"_id":4,host:"*:28005", arbiterOnly: true},

{"_id":5,host:"*:28006", arbiterOnly: true},

{"_id":6,host:"*:28007", arbiterOnly: true}]

}

MyMongo:SECONDARY> rs.reconfig(config,{force:true});

MyMongo:PRIMARY> rs.status() #查看副本集的状态,及各节点的状态

MyMongo:PRIMARY> db.isMaster()

在client端批量插入数据(简单的程序),这里可以配置集群方式连接,也可以指定主节点的方式进行插入,这里是直接指定主节点

#coding:utf-8
import time
from pymongo import MongoClient
#conn = MongoClient()
# keyword argument
conn = MongoClient('*', 28004)
# MongoDB URI
#conn = MongoClient('mongodb://localhost:27017/')
#from pymongo import ReplicaSetConnection
#conn = ReplicaSetConnection("*:28001,*:28002,*:28004", replicaSet="MyMongo", read_preference=2, safe=True) for i in xrange(100):
try:
conn.test.tt3.insert({"name":"test" + str(i)})
time.sleep(1)
print conn.primary
print conn.secondaries
except:
pass

主节点执行,100条

MyMongo:PRIMARY> db.tt3.find().count()

100

启动主中心的3个节点

[root@mysqlt1 conf]# /usr/local/mongodb/bin/mongod -f /data/mongodb/conf/28001.conf

[root@mysqlt1 conf]# /usr/local/mongodb/bin/mongod -f /data/mongodb/conf/28002.conf

[root@mysqlt1 conf]# /usr/local/mongodb/bin/mongod -f /data/mongodb/conf/28003.conf

[root@mysqlt1 ~]#  /usr/local/mongodb/bin/mongo *:28002/admin

MyMongo:SECONDARY> rs.slaveOk(true)

MyMongo:SECONDARY> use test;

switched to db test

MyMongo:SECONDARY> db.tt3.find().count() #数据同步成功

100

之前的5个节点,现在变成了7个节点,删除新加的2个仲裁节点

MyMongo:PRIMARY> rs.remove("*:28007");

MyMongo:PRIMARY> rs.remove("*:28006");

MyMongo:PRIMARY> db.isMaster() #变回之前的5个节点,1主,2secondry,2仲裁

{

"hosts" : [

"*:28001",

"*:28002",

"*:28004"

],

"arbiters" : [

"*:28003",

"*:28005"

MyMongo:PRIMARY> rs.status()

{

"set" : "MyMongo",

"date" : ISODate("2018-10-16T18:16:15.512Z"),

"myState" : 1,

"term" : NumberLong(7),

"heartbeatIntervalMillis" : NumberLong(2000),

"optimes" : {

"lastCommittedOpTime" : {

"ts" : Timestamp(1539713766, 1),

"t" : NumberLong(7)

},

"readConcernMajorityOpTime" : {

"ts" : Timestamp(1539713766, 1),

"t" : NumberLong(7)

},

"appliedOpTime" : {

"ts" : Timestamp(1539713766, 1),

"t" : NumberLong(7)

},

"durableOpTime" : {

"ts" : Timestamp(1539713766, 1),

"t" : NumberLong(7)

}

},

"members" : [

{

"_id" : 0,

"name" : "*:28001",

"health" : 1,

"state" : 2,

"stateStr" : "SECONDARY",

"uptime" : 237,

"optime" : {

"ts" : Timestamp(1539713766, 1),

"t" : NumberLong(7)

},

"optimeDurable" : {

"ts" : Timestamp(1539713766, 1),

"t" : NumberLong(7)

},

"optimeDate" : ISODate("2018-10-16T18:16:06Z"),

"optimeDurableDate" : ISODate("2018-10-16T18:16:06Z"),

"lastHeartbeat" : ISODate("2018-10-16T18:16:13.929Z"),

"lastHeartbeatRecv" : ISODate("2018-10-16T18:16:14.928Z"),

"pingMs" : NumberLong(0),

"syncingTo" : "*:28004",

"configVersion" : 102086

},

{

"_id" : 1,

"name" : "*:28002",

"health" : 1,

"state" : 2,

"stateStr" : "SECONDARY",

"uptime" : 269,

"optime" : {

"ts" : Timestamp(1539713766, 1),

"t" : NumberLong(7)

},

"optimeDurable" : {

"ts" : Timestamp(1539713766, 1),

"t" : NumberLong(7)

},

"optimeDate" : ISODate("2018-10-16T18:16:06Z"),

"optimeDurableDate" : ISODate("2018-10-16T18:16:06Z"),

"lastHeartbeat" : ISODate("2018-10-16T18:16:13.929Z"),

"lastHeartbeatRecv" : ISODate("2018-10-16T18:16:14.928Z"),

"pingMs" : NumberLong(0),

"syncingTo" : "*:28004",

"configVersion" : 102086

},

{

"_id" : 2,

"name" : "*:28003",

"health" : 1,

"state" : 7,

"stateStr" : "ARBITER",

"uptime" : 193,

"lastHeartbeat" : ISODate("2018-10-16T18:16:13.929Z"),

"lastHeartbeatRecv" : ISODate("2018-10-16T18:16:11.917Z"),

"pingMs" : NumberLong(0),

"configVersion" : 102086

},

{

"_id" : 3,

"name" : "*:28004",

"health" : 1,

"state" : 1,

"stateStr" : "PRIMARY",

"uptime" : 68054,

"optime" : {

"ts" : Timestamp(1539713766, 1),

"t" : NumberLong(7)

},

"optimeDate" : ISODate("2018-10-16T18:16:06Z"),

"electionTime" : Timestamp(1539712874, 1),

"electionDate" : ISODate("2018-10-16T18:01:14Z"),

"configVersion" : 102086,

"self" : true

},

{

"_id" : 4,

"name" : "*:28005",

"health" : 1,

"state" : 7,

"stateStr" : "ARBITER",

"uptime" : 66987,

"lastHeartbeat" : ISODate("2018-10-16T18:16:13.929Z"),

"lastHeartbeatRecv" : ISODate("2018-10-16T18:16:11.921Z"),

"pingMs" : NumberLong(0),

"configVersion" : 102086

}

],

"ok" : 1,

"operationTime" : Timestamp(1539713766, 1),

"$clusterTime" : {

"clusterTime" : Timestamp(1539713766, 1),

"signature" : {

"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),

"keyId" : NumberLong(0)

}

}

}

Mongodb 5节点异地两中心故障转移恢复测试案例的更多相关文章

  1. 3.16 使用Zookeeper对HDFS HA配置自动故障转移及测试

    一.说明 从上一节可看出,虽然搭建好了HA架构,但是只能手动进行active与standby的切换: 接下来看一下用zookeeper进行自动故障转移: # 在启动HA之后,两个NameNode都是s ...

  2. MHA高可用+VIP 集群故障转移(已测试成功)

       服务器部署说明192.168.158.201 mha管理,mysql主服192.168.158.202 mha节点,mysql从服192.168.158.203 mha节点,mysql从服Man ...

  3. MongoDB副本集配置系列十一:MongoDB 数据同步原理和自动故障转移的原理

    1:数据同步的原理: 当Primary节点完成数据操作后,Secondary会做出一系列的动作保证数据的同步: 1:检查自己local库的oplog.rs集合找出最近的时间戳. 2:检查Primary ...

  4. MongoDB副本集(一主两从)读写分离、故障转移功能环境部署记录

    Mongodb是一种非关系数据库(NoSQL),非关系型数据库的产生就是为了解决大数据量.高扩展性.高性能.灵活数据模型.高可用性.MongoDB官方已经不建议使用主从模式了,替代方案是采用副本集的模 ...

  5. mongoDB研究笔记:复制集故障转移机制

    上面的介绍的数据同步(http://www.cnblogs.com/guoyuanwei/p/3293668.html)相当于传统数据库中的备份策略,mongoDB在此基础还有自动故障转移的功能.在复 ...

  6. 一个线上问题的思考:Eureka注册中心集群如何实现客户端请求负载及故障转移?

    前言 先抛一个问题给我聪明的读者,如果你们使用微服务SpringCloud-Netflix进行业务开发,那么线上注册中心肯定也是用了集群部署,问题来了: 你了解Eureka注册中心集群如何实现客户端请 ...

  7. Hyper-V 2012 R2 故障转移群集

    和终端用户相比,企业用户对于业务的连续性和可靠性更为在意.相对而言,企业一般不会将追逐单一硬件的性能排在第一位. 如何衡量业务是否持续可用,一般使用"x 个 9"这种方式来定义.如 ...

  8. 第八章 Hyper-V 2012 R2 故障转移群集

    和终端用户相比,企业用户对于业务的连续性和可靠性更为在意.相对而言,企业一般不会将追逐单一硬件的性能排在第一位. 如何衡量业务是否持续可用,一般使用"x 个 9"这种方式来定义.如 ...

  9. 搭建iSCSI文件服务器故障转移群集

    故障转移群集(Failover Cluster)可以提供一个高可用性应用程序或服务的网络环境,本章将接受如何搭建iSCSI SAN文件服务器故障转移群集. 故障转移群集概述 我们可以将多台服务器组成一 ...

随机推荐

  1. POJ 3159 最短路 SPFA

    #include<iostream> using namespace std; const int nMax = 30005; const int mMax = 150005; const ...

  2. 数据结构习题 线段树&树状数组

    说明:这是去年写了一半的东西,一直存在草稿箱里,今天整理东西的时候才发现,还是把它发表出来吧.. 以下所有题目来自Lrj的<训练指南> LA 2191 单点修改,区间和  Fenwick直 ...

  3. HDU1565 方格取数(1)

    Problem Description 给你一个n*n的格子的棋盘,每个格子里面有一个非负数.从中取出若干个数,使得任意的两个数所在的格子没有公共边,就是说所取的数所在的2个格子不能相邻,并且取出的数 ...

  4. hdoj1002--A + B Problem II

    Problem Description I have a very simple problem for you. Given two integers A and B, your job is to ...

  5. JMeter接口测试报错,反馈和postman不一样(二)

    我总共现在有两个可以学习的接口,昨天测试一个接口发现问题解决后,今天测试另外一个发现又有问题了 这一次还是反馈显示不一样 要么 这种情况是直接从postman里面拿过来的数据,没做处理  报not j ...

  6. 彻底弄清python的切片

    lis = range(100) # [0, 1, 2, 3, ..., 99] # 取前10个 lis[:10] # [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] # 取后10个 l ...

  7. C++(十三)— map的排序

    在c++中有两个关联容器,第一种是map,内部是按照key排序的,第二种是unordered_map,容器内部是无序的,使用hash组织内容的. 1.对有序map中的key排序 如果在有序的map中, ...

  8. selenium webdriver如何添加cookie

    一. webdriver中常用的cookie方法 webdriver中提供了操作cookie的相关方法: get_cookies()                  获得cookie信息 add_c ...

  9. poj3189二分图多重匹配

    题意:有一些牛和牛棚(有容量),每头牛对牛棚有喜好程度,要求每头牛都有一个棚子的情况下,找最小的喜好程度之差 题解:题意是真的恶心,wa了好久才发现没读懂,一直以为输入 的是排名,其实是牛棚标号,从1 ...

  10. Oracle Index Clustering Factor(集群因子)

    一.本文说明: 今天在做测试的时候发现字段上有索引,但是执行计划就是不走索引,经过在网上查找才发现原来是索引的集群因子过高导致的.本文属于转载 二.官网说明 The index clustering ...