为 mongoDB 集群中的多个 mongo 节点 EBS 卷拍摄 EBS 快照

Question

对于一个 mongoDB 分片，我在同一个卷上拥有日志和数据，因此不需要使用 fsyncLock 锁定后才拍摄快照的一致性问题。 EBS 快照将是单个分片的一致时间点。

我想知道在 mongodb 集群中进行备份的首选方式是什么。我探索了两种选择：

1. 通过大约在同一时间拍摄 EBS 快照的近似时间点一致备份。优点是不需要写锁。
2. 停止对系统的写入，然后拍摄快照。这将提供时间点一致的备份。

现在，我想知道它是如何在生产中实际完成的。我已经阅读过正在使用的副本集的辅助节点，但不清楚它如何提供时间点一致的备份。除非所有从节点都有一致的时间点数据，否则 EBS 快照不可能是时间点。例如，对于 NodeA 的辅助节点，如果数据与主节点同步，但 NodeB 的辅助节点的某些数据没有同步，该怎么办。我在这里遗漏了什么吗？

另外，如果发生这种情况，方法 1 是否会导致 MongoDB 集群不一致（恢复时），例如崩溃或问题？

Answer 1

一致的备份

任何分片集群备份过程的第一步应该是：

• 停止平衡器（包括等待任何正在进行的迁移完成）。通常这是使用sh.stopBalancer() shell 助手完成的。

• 备份配置服务器（通常使用与分片服务器相同的方法，例如 EBS 或文件系统快照）

我会将分片集群的一致备份定义为分片集群元数据（即存储在配置服务器上的数据）与各个分片的备份相对应的备份，并且每个分片都已正确备份.停止平衡器可确保在备份过程中不会发生数据迁移。

假设您的 MongoDB 数据和日志文件位于单个卷上，您可以采用一致的 EBS snapshot 或 filesystem snapshot 而无需停止对正在备份的节点的写入。快照异步发生。创建初始快照后，后续快照是增量的（只需要更新自上一个快照以来已更改的块）。

时间点备份

使用活动的分片集群，您只能通过停止对集群的所有写入并备份每个分片的主节点来轻松捕获已写入数据的真实时间点备份。否则，正如您所推测的，如果您从辅助节点备份，分片之间可能会有不同的复制延迟。从辅助节点备份更为常见，因为在写入快照时会有一些 I/O 开销。

如果您没有对分片使用复制（或者更喜欢从主分片备份），则复制滞后警告不适用，但对于活动系统来说，时间仍然是近似的，因为需要同时启动快照跨所有分片。

时间点恢复

假设您的所有分片都由副本集支持，则可以使用近似的时间点一致备份来编排 还原 到使用 @ 的更具体的时间点每个分片（加上一个配置服务器）的 987654324@。这本质上是 MongoDB Cloud Manager (née MMS) 等备份解决方案所采用的方法：请参阅 MongoDB Backup for Sharded Cluster。 MongoDB Cloud Manager 利用每个分片上的备份代理使用复制 oplog 进行连续备份，并按计划定期创建完整快照。可以通过从完整数据快照开始构建时间点恢复，然后将相关操作日志重播到请求的时间点。

常见的制作方法是什么？

停机通常不是生产系统理想的备份策略，因此常见的方法是使用快照在大致的时间点对正在运行的分片集群进行一致的备份。跨分片集群协调备份可能具有挑战性，因此备份工具/服务也值得考虑。如果您的部署不允许快照（例如，如果您的数据和/或日志目录分布在多个卷中以最大限度地提高可用 IOPS），备份服务也可能更适合。

注意：您真的应该考虑在生产部署中使用复制，除非这是一个非必要的集群或停机时间是可以接受的。副本集有助于最大限度地延长部署的正常运行时间和可用性，并且在没有数据冗余的情况下，一些维护任务（包括备份）将更有影响力。

Answer 2

您的备份将分为多个阶段：

1. 用sh.stopBalancer() 停止mongos 上的平衡器
2. 您现在可以备份配置服务器的config 数据库。不管你是使用 EBS 快照还是 mongodump --oplog
3. 现在分片，您可以决定采用哪种方式：
   1. 要么：您使用mongodump --oplog 备份每个节点。您不需要停止写入，因为您将操作日志与数据库导出一起拍摄快照。此备份允许一致的还原。还原时，您可以使用--oplogReplay 和--oplogLimit 选项来指定时间戳（假设您的 oplog 大小合适并且在备份期间没有翻转）。您可以在所有分片上并行执行转储，并且恢复由 oplog 同步。
   2. 或者您为每个分片 fsync 并锁定并创建 EBS 快照（描述为 http://docs.mongodb.org/ecosystem/tutorial/backup-and-restore-mongodb-on-amazon-ec2/）。 MongoDB 3.0 不能保证在使用 WiredTiger 时数据文件不会改变。这里的代价是，您必须停止所有读取和写入，因为您必须卸载设备。
4. 现在用sh.startBalancer() 启动mongos 上的平衡器

由于您不使用副本集，因此您无需担心滞后的辅助节点/写入不会在整个集群中复制。我最喜欢的选项是使用mongodump/mongorestore，它可以对还原进行大量控制。

更新：

最后，您必须决定要支付多少费用才能获得某些好处：

1. 快照：支付空间、写入锁定和一定程度的一致性，以获得快速备份、快速恢复时间，并且备份后不影响性能
2. 转储：花时间付费并在备份期间淘汰工作集以获得更小的备份，以实现一致且较慢的恢复，无写锁定