关于mongodb: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/…