文档章节

MongoDB副本集配置和数据迁移实战

ExtremeTalk
 ExtremeTalk
发布于 06/30 16:48
字数 1776
阅读 942
收藏 27

MongoDB副本集配置和数据迁移实战

https://gitee.com/et/ops/blob/master/MongoDB副本集配置和数据迁移实战.md

环境:Ubuntu 16.04, MongoDB 3.6

基本概念

MongoDB 的副本集就是有自动故障恢复功能的 MongoDB 主从集群。由于 MongoDB 的主从复制功能不支持高可用,所以从 3.2 版本开始已经被废弃了,转而用副本集来代替。一个副本集总会有一个活跃节点(Primary)和若干个备份节点(Secondary),还有一个可选的一个仲裁者(Arbiter)节点来实现HA中的故障切换。

准备工作

配置副本集 Primary 和 Secondary 节点

  • 创建数据目录
$ mkdir -p /mnt/mongodb/replset
  • 启动名为“my-repl”的副本集,端口为27017,绑定到任意IP(也可以指定IP)
$ mongod --dbpath /mnt/mongodb/replset --port 27017 --replSet "my-repl" --bind_ip_all
  • 初始化副本集
    • 用mongo客户端连接 Primary 节点:
    $ mongo
    
    • 执行初始化脚本来创建副本集:
    > rs.initiate({
     _id:"my-repl",
      members:[
        {_id:0, host:"192.168.10.58:27017"},
        {_id:1, host:"192.168.10.59:27017"}
      ]
    });
    
    输出结果:
    {
    	"ok" : 1,
    	"operationTime" : Timestamp(1523237919, 1),
    	"$clusterTime" : {
    		"clusterTime" : Timestamp(1523237919, 1),
    		"signature" : {
    			"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
    			"keyId" : NumberLong(0)
    		}
    	}
    }
    
    • 查看配置结果
    > rs.conf();
    {
    	"_id" : "my-repl",
    	"version" : 1,
    	"protocolVersion" : NumberLong(1),
    	"members" : [
    		{
    			"_id" : 0,
    			"host" : "192.168.10.58:27017",
    			"arbiterOnly" : false,
    			"buildIndexes" : true,
    			"hidden" : false,
    			"priority" : 1,
    			"tags" : {
    
    			},
    			"slaveDelay" : NumberLong(0),
    			"votes" : 1
    		},
    		{
    			"_id" : 1,
    			"host" : "192.168.10.59:27017",
    			"arbiterOnly" : false,
    			"buildIndexes" : true,
    			"hidden" : false,
    			"priority" : 1,
    			"tags" : {
    
    			},
    			"slaveDelay" : NumberLong(0),
    			"votes" : 1
    		}
    	],
    	"settings" : {
    		"chainingAllowed" : true,
    		"heartbeatIntervalMillis" : 2000,
    		"heartbeatTimeoutSecs" : 10,
    		"electionTimeoutMillis" : 10000,
    		"catchUpTimeoutMillis" : -1,
    		"catchUpTakeoverDelayMillis" : 30000,
    		"getLastErrorModes" : {
    
    		},
    		"getLastErrorDefaults" : {
    			"w" : 1,
    			"wtimeout" : 0
    		},
    		"replicaSetId" : ObjectId("5acac41fded47067da446ddd")
    	}
    }
    
    配置过程非常简单,可以看到在副本集成员中有0和1两个节点,此时主从两个服务器已经可以工作了,服务器0(Primary)有任何数据的变化都会同步到服务器1(Secondary)上。但是,此时的副本集只是提供了数据备份的功能,并不能达到高可用。如果要达到这一点,那么需要配置一个仲裁者节点(Arbiter)

配置仲裁者(Arbiter)

仲裁者在 Primary 节点发生故障时,参与副本集的选举投票决定哪个副本成为 Primary 节点。仲裁节点不保存数据也不会成为 Primary 节点。

  • 仲裁者通常不部署在大磁盘空间的服务器上,因此为了最小化默认创建数据,修改配置:

    $ vim /etc/mongod.conf
    
    storage.journal.enabled=false
    storage.mmapv1.smallFiles = true.
    
  • 创建仲裁者目录并启动服务

    $ mkdir /mnt/mongodb/arbiter
    $ mongod --port 27017 --dbpath /mnt/mongodb/arbiter --replSet 'my-repl' --bind_ip_all
    
  • 把仲裁者添加到副本集中

    • 连接至 Primary 服务器

      $mongo --host 192.168.10.58
      
      my-repl:PRIMARY> rs.addArb("192.168.10.57:27017")
      {
      	"ok" : 1,
      	"operationTime" : Timestamp(1523326877, 1),
      	"$clusterTime" : {
      		"clusterTime" : Timestamp(1523326877, 1),
      		"signature" : {
      			"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
      			"keyId" : NumberLong(0)
      		}
      	}
      }
      
  • 查看副本集的效果:

    >rs.status();
    my-repl:PRIMARY> rs.status();
    {
    	"set" : "my-repl",
    	"date" : ISODate("2018-04-10T02:21:44.826Z"),
    	"myState" : 1,
    	"term" : NumberLong(2),
    	"heartbeatIntervalMillis" : NumberLong(2000),
    	"optimes" : {
    		"lastCommittedOpTime" : {
    			"ts" : Timestamp(1523326895, 1),
    			"t" : NumberLong(2)
    		},
    		"readConcernMajorityOpTime" : {
    			"ts" : Timestamp(1523326895, 1),
    			"t" : NumberLong(2)
    		},
    		"appliedOpTime" : {
    			"ts" : Timestamp(1523326895, 1),
    			"t" : NumberLong(2)
    		},
    		"durableOpTime" : {
    			"ts" : Timestamp(1523326895, 1),
    			"t" : NumberLong(2)
    		}
    	},
    	"members" : [
    		{
    			"_id" : 0,
    			"name" : "192.168.10.58:27017",
    			"health" : 1,
    			"state" : 1,
    			"stateStr" : "PRIMARY",
    			"uptime" : 2891,
    			"optime" : {
    				"ts" : Timestamp(1523326895, 1),
    				"t" : NumberLong(2)
    			},
    			"optimeDate" : ISODate("2018-04-10T02:21:35Z"),
    			"electionTime" : Timestamp(1523324284, 1),
    			"electionDate" : ISODate("2018-04-10T01:38:04Z"),
    			"configVersion" : 2,
    			"self" : true
    		},
    		{
    			"_id" : 1,
    			"name" : "192.168.10.59:27017",
    			"health" : 1,
    			"state" : 2,
    			"stateStr" : "SECONDARY",
    			"uptime" : 2624,
    			"optime" : {
    				"ts" : Timestamp(1523326895, 1),
    				"t" : NumberLong(2)
    			},
    			"optimeDurable" : {
    				"ts" : Timestamp(1523326895, 1),
    				"t" : NumberLong(2)
    			},
    			"optimeDate" : ISODate("2018-04-10T02:21:35Z"),
    			"optimeDurableDate" : ISODate("2018-04-10T02:21:35Z"),
    			"lastHeartbeat" : ISODate("2018-04-10T02:21:43.080Z"),
    			"lastHeartbeatRecv" : ISODate("2018-04-10T02:21:43.083Z"),
    			"pingMs" : NumberLong(0),
    			"syncingTo" : "192.168.10.58:27017",
    			"configVersion" : 2
    		},
    		{
    			"_id" : 2,
    			"name" : "192.168.10.57:27017",
    			"health" : 1,
    			"state" : 7,
    			"stateStr" : "ARBITER",
    			"uptime" : 27,
    			"lastHeartbeat" : ISODate("2018-04-10T02:21:43.079Z"),
    			"lastHeartbeatRecv" : ISODate("2018-04-10T02:21:42.088Z"),
    			"pingMs" : NumberLong(0),
    			"configVersion" : 2
    		}
    	],
    	"ok" : 1,
    	"operationTime" : Timestamp(1523326895, 1),
    	"$clusterTime" : {
    		"clusterTime" : Timestamp(1523326895, 1),
    		"signature" : {
    			"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
    			"keyId" : NumberLong(0)
    		}
    	}
    }
    

    可以看到状态显示:服务器0为 Primary, 服务器1为 Secondary, 服务器2为 Arbiter。
    此时带有高可用的副本集已经配置完成,Arbiter 会监控 Primary 节点的运行情况,如果服务器0发生了宕机,那么仲裁者 Arbiter 节点会发起选举,最终选取多个 Secondary 中的某一个来作为 Primary 节点。我们测试的架构中只有一个 Secondary 节点,那么此服务器1就会成为 Primary。而当服务器0恢复工作时,它会被当成 Secondary 来运行。

  • 副本优先级
    副本集会在 Primary 节点出现故障时把 Secondary 提升为 Primary,但是很多情况下 Secondary 只是作为备用节点,我们不希望它长期作为 Primary 节点运行。那么为了达到这个目的,我们修改副本的优先级。

    • 连接 Primary 节点,执行以下脚本:
    cfg = rs.conf()
    cfg.members[0].priority = 10
    cfg.members[1].priority = 5
    rs.reconfig(cfg)
    {
    	"ok" : 1,
    	"operationTime" : Timestamp(1523411797, 2),
    	"$clusterTime" : {
    		"clusterTime" : Timestamp(1523411797, 2),
    		"signature" : {
    			"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
    			"keyId" : NumberLong(0)
    		}
    	}
    }
    
    • 如果在非 Prmiary 上比如Arbiter上运行,会报下面的错误:
    {
      "ok" : 0,
      "errmsg" : "replSetReconfig should only be run on PRIMARY, but my state is ARBITER; use the \"force\" argument to override",
      "code" : 10107,
      "codeName" : "NotMaster"
    }
    
    • 以上操作让服务器0的优先级高于服务器1,那么当服务器0从故障中恢复时,它会重新成为 Primary 节点来提供服务。

数据迁移

在配置副本集之前,你可能已经存在了一个单独的 MongoDB 实例存储了一些数据,你需要把原来实例中的数据迁移到新的副本集中。(你也可以一开始就把原来的单个实例配置成副本集的 Primary 节点,然后新增副本来同步数据,此方法不在本文讨论范围之内)

  • 登录原实例所在的服务器,导出数据:

    $ mongoexport -h localhost -p 27017 -u xxx -p xxx -d MY_DB_NAME -c MY_COLLECTION_NAME -o MY_COLLECTION_NAME.dmp
    

    在阿里云上测试了一个导出数据大约为1.2G大小的集合,导出性能如下:

    • 时间:3分11秒
    • 导出1728423条记录,每秒读取记录数=1728423/191=9050条/秒
    • 导出1264441038字节,每秒处理字节数=1264441038/191=6.6M/秒
  • 将导出的数据文件 MY_COLLECTION_NAME.dmp 已任何方式(比如scp)同步到 Primary 节点所在的服务器0上

  • 导入数据至副本集 Primay 节点

    mongoimport -h my-repl/192.168.10.58:27017 -d MY_DB_NAME -c MY_COLLECTION_NAME --file MY_COLLECTION_NAME.dmp
    

    测试导入性能

    • 时间:82秒
    • 导入1728423条记录,每秒写入记录数=1728423/82=21078条/秒
    • 导入1264441038字节,每秒处理字节数=1264441038/82=14.7M/秒

    注意:由于不是相同的服务器,所以不能通过这个来比较导入和导出的性能差别,只能所谓一个参考:

  • 总结:

    • 在 Primary 节点导入数据后,登录 Secondary 节点查看,可以看到一百七十多万条数据全部复制过去了,主从复制成功。
    • 从性能分析结果来看,MongoDB的读取和写入性能是比较好的,特别是导入的同时还要和副本之间同步数据。

© 著作权归作者所有

共有 人打赏支持
ExtremeTalk

ExtremeTalk

粉丝 17
博文 1
码字总数 1776
作品 1
苏州
技术主管
私信 提问
MongoDB trouble shoot sharded clusters

MongoDB trouble shoot sharded clusters 前言 Part1:写在最前 在MongoDB sharding环境中,我们会遇到一些常见的错误,本文就MongoDB官网列出的错误进行翻译。 Part2:整体环境 MongoDB 3.4....

dbapower
07/04
0
0
mongodb(一)mongodb 副本集配置

---layout: blogistop: truetitle: "mongodb 副本集配置"date: 2018-08-29category: mongodbtags: mongodb --- 环境 下载解压 基本配置: 假定已经解压安装完成,现在所处的目录是 /usr/loc...

开心的哈士奇
10/17
0
0
MongoDB Upgrade a Replica Set to 3.4

MongoDB 副本集升级 前言 Part1:写在最前 本文讲解MongoDB副本集的升级方法,以及注意事项。本文的环境为MongoDB3.2升级MongoDB3.4,低版本升级3.4的话需要优先升级到3.2版本才可以。如果发现...

dbapower
07/04
0
0
MongoDB高可用方案原理解析

MongoDB 是当前比较流行的文档型数据库,其拥有易使用、易扩展、功能丰富、性能卓越等特性。MongoDB 本身就拥有高可用及分区的解决方案,分别为副本集(Replica Set)和分片(sharding),下面我...

arthur376
08/27
0
0
MongoDB集群部署 - 带访问控制的分片副本集

1. 前言   Ceilometer将meter、event等数据保存在MongoDB中,之前将MongoDB部署在控制节点上,使用三副本模式,时间长了发现meter数据爆炸式增长,区区2T的磁盘捉襟见肘,而想删除旧数据,...

Sai18
08/16
0
0

没有更多内容

加载失败,请刷新页面

加载更多

TiQuery:All Diagnosis in SQL | TiDB Hackathon 优秀项目分享

本文作者是来自 TiNiuB 队的黄梦龙同学,他们的项目 TiQuery 在本届 TiDB Hackathon 2018 中获得了三等奖。 TiQuery 可以搜集诊断集群问题所需要的信息,包括集群拓扑,Region 分布,配置,各...

TiDB
5分钟前
1
0
git 分支创建合并流程图

gentlelions
13分钟前
1
0
Kali Linux常用服务配置教程DHCP服务原理

Kali Linux常用服务配置教程DHCP服务原理 动态主机配置协议(Dynamic Host Configuration Protocol,简称DHCP)是一个局域网的网络协议,基于UDP协议工作。它主要有两个用途:第一,给内部网...

大学霸
14分钟前
0
0
控制台打印图片

function dev(){ if (window.console){ console.log("%c\n ", "font-size:100px;background:url('http://gmcyzs.com/resources/images/logo.png') no-repeat"); console.log('%c 深务平台,\......

羊皮卷
21分钟前
0
0
MyBaties的二级缓存

二级缓存介绍 在上文中提到的一级缓存中,其最大的共享范围就是一个SqlSession内部,那么如何让多个SqlSession之间也可以共享缓存呢,答案是二级缓存。 当开启二级缓存后,会使用CachingExec...

嘴角轻扬30
22分钟前
3
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部