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/...