mongo的数据恢复和迁移

结义 -
mongo的数据恢复和迁移
mongo的数据恢复和迁移mongo单实例部署

1.由一个mongo构成,对外提供服务。缺点:如果一个节点挂了,就没有办法对外提供服务。数据无备份,安全差。

mongo副本集部署

1.副本集部署。一般是有3个节点(为了投票,和超过半数。如果2个节点,挂了一个,另外一个不能对外。不能选举成主节点)。常规的有 primary - secondary - secondary (P - S - S) . 但是如果为了节约资源,可以将一个seconday改成仲裁节点Arbiter(只负责投票,不同步数据) ,变成了 P- S -A。挂了一个,另一个数据承载节点可以被选为主节点。

2.部署选择,最好选择P - S -S .这样挂了一个完全不会有问题。 但是如果选择 P - S -A 部署。挂一个数据节点。变成 P - A 。可以一段时间保存正常。但是几个小时后,慢慢的主节点变慢。flowControl机制限制主节点写入,还有其他的问题。

参考:https://www.mongodb.com/docs/...

mongo分片集群部署

mongos: 主要是做访问路由,

mongo_cs (config servers): 保存分配的元数据和分片的集群配置。从3.4版本后,改成了副本集的部署。

shard : 分片数据的承载节点。可以是副本集,也可以是单实例。一般为了安全都是副本集。

参考:https://www.mongodb.com/docs/...

分片集群的维护

分片集群的问题,基本都是由于shard分配的数据问题。归纳也就是某个分配的副本集的数据有问题。由于副本集的压力一般都大。导致oom等各种问题。

如果发现mongo有问题。可以先进入mongos,执行sh.status()。查看集群分片信息。

进入问题的分片的mongod中,执行rs.status() 。可以看到具体的副本集的信息。可以看到副本集节点的状态信息。

副本集数据恢复副本集的主从同步是通过从节点去主节点查询oplog.然后在自己这个重放,达到数据的一直性。但是由于oplog的大小是受限的rs.printReplicationInfo()

。所以如果一个节点down机太久。会导致主节点没有他需要的oplog.这是节点变成了stale状态。这种情况只能进行全量的数据同步。

方案一:先将故障节点安全关mongo,db.shutdownServer() ,直接将故障节点的数据目录备份。清空数据目录。然后重启。这样从节点会从主节点copy数据。可以在故障的节点查询日志。 INITSYNC 的关键字。可以看到执行的copy的信息。有点主节点可以继续服务。缺点:同时的时间长。

方案二:将主节点安全关mongo。将数据的目录全量拷贝到故障节点。将故障节点的数据备份。然后将copy来的数据放到数据目录。然后主节点mongo启动,从节点启动。数据就一致了。

参考: https://www.mongodb.com/docs/...

危险操作

有时候发现mongo长时间无法优雅关机,导致最后kill -9 . 这种情况会出现mongo的数据检查。然后mongo日志发现 REPL 的操作日志。查询操作日志的时间。如果操作日志距离当前时间比较近,最好等待。如果估计很长时间不能恢复。且着急恢复服务的可用。在关机mongo。删掉数据目录中的mongd.lock文件,清空journal目录。这种方法会导致数据的丢失。会回到上一个checkpoint的时间点的数据。不是没有办法。不要使用该方法。

数据迁移

方案一: 分片集群的数据迁移。通过mongodump将所有的数据导出,然后将数据倒入新的集群。优点:简单,缺点:时间长。

方案二:mongod , mongo_cs都是副本集的部署。可以将原始的集群的副本集将新的机器加入。然后本成了6节点的副本集。然后将老机器从副本集中剔除。

操作步骤: 老集群的副本集的数据copy到新集群的对应机器。然后将新机器加入集群。数据同步完成就剔除老机器。更加详细的迁移见官方文档。

参考: https://www.mongodb.com/docs/...

特别申明:本文内容来源网络,版权归原作者所有,如有侵权请立即与我们联系(cy198701067573@163.com),我们将及时处理。

Tags 标签

mongodb数据库

扩展阅读

加个好友,技术交流

1628738909466805.jpg