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() 。可以看到具体的副本集的信息。可以看到副本集节点的状态信息。

副本集数据恢复

1. 副本集的主从同步是通过从节点去主节点查询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/...