MongoDB数据库迁移（复制集集群迁移）
数据库(复制集)迁移
@(MongoDB)[复制集|迁移|]
前言：
有时候由于业务或者其他因素的原因，我们需要将生产环境（复制集）中的数据库迁移到新服务器上，也有可能是异地机房，且宕机时间不允许太长；下面针对这个需求我们做一下测试。我认为5分钟即可完成迁移；
准备
- 3台新机器
- 10.26.231.107:37027
- 10.26.231.108:37027
- 10.26.231.109:37027
- mongo3.4安装包
架构图说明
- 添加新节点到原复制集
- 同步数据保证数据一致
- 集群中移除新节点
- 组建新集群
步骤：
1、部署新节点
1.1 创建相应路径
根据需要创建相应文件（数据文件，日志文件，进程目录，认证文件…),这里就不再赘述了，如果实在不明白可以看我的其他文章。
1.2 修改启动文件
从原复制集拷贝一份启动文件，按需修改即可（修改相应目录等）
1.3 复制数据文件
登录原复制集Secondary节点上，锁库
SECONDARY>db.fsyncLock()
- 1
开启另一个session，拷贝--dbpath下的所有文件到新节点
-
$cd /data/dbdata
-
$ scp -r ./* mongo@10.26.231.107:/data/dbdata/
- 1
- 2
解锁Secondary节点
SECONDARY>db.fsyncUnlock()
- 1
1.4 启动新节点
以拷贝来的数据文件启动新节点
/apps/mongodb/bin/mongod -f /etc/mongodbtestrs1.cnf
- 1
此时，若登录到节点上，执行rs.status()会提示报错，因为此节点没有加入到任何集群中，报错如下： 
2、加入集群中
连接到原集群的Primary节点上，执行如下命令将新节点加入副本集中
-
rs1:PRIMARY> rs.add("10.26.231.107:37027")
-
{ "ok" : 1 }
- 1
- 2
3、检查数据同步状态
此时查看集群状态，会发现新节点状态为STARTUP2，表示正在进行数据同步,待stateStr为如下状态时，即表示数据一致：
"stateStr" : "SECONDARY",
- 1
4、切断新节点
4.1 创建临时数据
通知应用端停止写入数据，此时通过生成一个临时集合来检查数据是否已同步完成
-
rs1:#PRIMARY> db.tmp.find()
-
rs1:PRIMARY> db.tmp.insert({task:"ForTest",cdate:new Date()})
-
WriteResult({ "nInserted" : 1 })
- 1
- 2
- 3
4.2 验证数据
登录新的从节点查看是否同步完成
-
rs1:SECONDARY> use Johnny
-
switched to db Johnny
-
rs1:SECONDARY> db
-
Johnny
-
rs1:SECONDARY> db.tmp.find()
-
Error: error: {
-
"ok" : 0,
-
"errmsg" : "not master and slaveOk=false",
-
"code" : 13435,
-
"codeName" : "NotMasterNoSlaveOk"
-
}
-
rs1:SECONDARY> rs.slaveOk() ---报上述错误，使用此命令解决，默认secondary不提供读
-
rs1:SECONDARY> db.tmp.find()
-
{ "_id" : ObjectId("5a53238a0a2b209188596c9a"), "task" : "ForTest", "cdate" : ISODate("2018-01-08T07:53:46.121Z") }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
4.3 移除新节点
此时我们可放心进行移除操作，先锁从库(10.26.231.107上执行)，防止又有新数据写入导致数据不一致，不过应该不会发生此种情况。
rs1:SECONDARY> db.fsyncLock()
- 1
将节点从原复制集架构中移除（Primary上执行）
-
rs1:PRIMARY> rs.remove("10.26.231.107:37027")
-
{ "ok" : 1 }
- 1
- 2
解锁从库
>db.fsyncUnlock() ---被移除后，此时新节点的mongo shell提示符会只有一个大于号
- 1
5、部署新复制集
5.1 启动其余节点
以如下方式启动其他两个新节点（108, 109)，这里就不再赘述如何配置如何启动了（与上述新节点一样配置即可）
$ /apps/mongodb/bin/mongod -f /etc/mongodbtestrs1.cnf
- 1
5.2 配置新复制集
重新连接此新节点（10.26.231.107） 注：一定要以root角色登录，否则再进行新副本集配置的时候将报错
$ mongo 10.26.231.107:37027admin -uroot -p
- 1
重新设定新复制集配置信息
-
>config={_id:"rs1",members:[
-
{_id:0,host:"10.26.231.107:37027",priority:99},
-
{_id:1,host:"10.26.231.108:37027",priority:1},
-
{_id:2,host:"10.26.231.109:37027",priority:0,hidden:true,slaveDelay:3600}
-
]}
-
>rs.reconfig(config,{force:true}) ---重置新配置，force:在没有Primary时强制生效配置
-
>rs.conf() ---查看配置信息
- 1
- 2
- 3
- 4
- 5
- 6
- 7
6、检查集群状态
rs1.PRIMARY>rs.status(),执行此命令以查看集群状态；生效后，mongo shell提示符将变更为PRIMARY>,且可通过此命令查看其他节点应该是STARTUP2状态，即同步数据中
总结：
至此，我们的复制集迁移就成功了，如果是异地机房迁移，在启动新节点时一定要提前把原复制集的数据文件拷贝过来再启动，这样可以省很多同步数据的时间；在使用rs.reconfig()命令重置架构配置时一定要把原节点IP都替换或者清楚掉，否则会把原复制集中的节点牵扯进来，从而导致原复制集崩溃（因为我遇到了）；
转载自：https://blog.csdn.net/jianlong727/article/details/79043928
文章来源: brucelong.blog.csdn.net，作者：Bruce小鬼，版权归原作者所有，如需转载，请联系作者。
原文链接：brucelong.blog.csdn.net/article/details/80221793
- 点赞
- 收藏
- 关注作者
评论（0）