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