我在mongoDB分片的同一卷上都有日志和数据，因此不需要在使用fsyncLock锁定后拍摄快照的一致性问题。对于单个分片，EBS快照将是一致的时间点。
我想知道在mongodb群集中进行备份的首选方法是什么。我已经探索了两个选择：
现在，我想知道它是如何在生产中完成的。我已经阅读了有关副本集的二级节点的使用情况，但不清楚它是如何给出时间点一致的备份。除非所有辅助节点都具有一致的时间点数据，否则EBS快照不能是时间点。例如，如果对于NodeA的辅助节点，数据与主节点同步，但NodeB的辅助节点的某些数据不同。我在这里错过了什么吗？
此外，如果有的话，方法1会导致不一致的MongoDB集群（恢复时），这样会崩溃还是东西？
答案 0 :(得分：1)
任何分片群集备份过程的第一步应该是：
停止平衡器（包括等待正在进行的任何迁移完成）。通常这是通过sh.stopBalancer() shell帮助程序完成的。
备份配置服务器（通常使用与分片服务器相同的方法，因此EBS或文件系统快照）
我会将分片群集的一致备份定义为分片群集元数据（即存储在配置服务器上的数据）与各个分片的备份相对应的备份，并且每个分片都已正确备份。停止平衡器可确保在备份过程中不会发生数据迁移。
假设您的MongoDB数据和日志文件位于单个卷上，您可以采用一致的EBS snapshot或filesystem snapshot，而无需停止对要备份的节点的写入。快照以异步方式发生。创建初始快照后，连续快照是增量的（仅需要更新自上一个快照以来已更改的块）。
使用活动分片群集，您只能通过停止对群集的所有写入并备份每个分片的原色来轻松捕获已写入的数据的真实时间点备份。否则，正如您所推测的那样，如果从辅助节点备份，则分片之间可能存在不同的复制延迟。从辅助节点备份更常见，因为在写快照时会有一些I / O开销。
如果您没有为分片使用复制（或者更喜欢从原色进行备份），则复制滞后警告不适用，但由于需要同时启动快照，因此时间仍然是活动系统的近似值跨越所有碎片。
假设所有分片都由副本集支持，则可以使用大致的时间点一致性备份，使用{将恢复编排到更具体的时间点。 {3}}用于每个分片（加上配置服务器）。这基本上是MongoDB Cloud Manager（néeMMS）等备份解决方案所采用的方法：请参阅replica set oplog。 MongoDB Cloud Manager利用每个分片上的备份代理，使用复制oplog进行连续备份，并定期根据计划创建完整快照。可以通过从完整数据快照开始，然后将相关的oplog重放到请求的时间点来构建时间点恢复。
停机时间通常不是生产系统的理想备份策略，因此通常的方法是使用快照在大致时间点对正在运行的分片集群进行一致备份。跨分片群集协调备份可能具有挑战性，因此备份工具/服务也值得考虑。如果您的部署不允许快照（例如，如果您的数据和/或日志目录分布在多个卷上以最大化可用IOPS），则备份服务也可能更合适。
注意：除非这是一个非必要的群集或者可以接受停机时间，否则您应该真的考虑将复制用于生产部署。副本集有助于最大限度地延长正常运行时间。如果没有数据冗余，部署和某些维护任务（包括备份）的可用性将会更加有效。
答案 1 :(得分：0)
您的备份将分为多个阶段：
mongos sh.stopBalancer()上的平衡器
config数据库。无论您是使用EBS快照还是mongodump --oplog mongodump --oplog备份每个节点。您不需要停止写入，因为您将oplog与数据库导出一起快照。此备份允许一致的还原。还原时，您可以使用--oplogReplay和--oplogLimit选项指定时间戳（假设您的oplog大小适当且在备份期间没有翻转）。您可以并行地对所有分片执行转储，并通过oplog同步还原。mongos sh.startBalancer()上的平衡器
由于您不使用副本集，因此您没有使用滞后的辅助节点的麻烦/整个群集中不会复制写入。我最喜欢的选择是使用mongodump / mongorestore，它可以为恢复提供很多控制。
<强>更新
最后，您必须决定要支付哪些费用以获得某些好处：