Mongodump 对应用程序性能的影响非常糟糕

Question

我们有一个相当大的 mongo 实例 (150 GB)，没有分片，我们的常规备份 ( mongodump) 对应用程序性能有非常显着的影响。更糟糕的是，由于应用程序大量使用 mongo，备份持续时间超过 10 个小时。

我知道我们需要分片，而且我们计划迁移到 ElasticSearch，所以我正在寻找一些短期解决方案。

有什么我可以做的来改善这一点，比如限制 mongodump 的每秒查询次数或其他什么？

我们在 32 核 190 GB RAM 服务器上有一个独立的 mongo，它与 nginx、rabbitmq 和一些小东西共享它。不是有史以来最干净的设置，我知道:)

Answer 1

所有通过转储的数据mongodump都必须由 MongoDB 服务器读入内存。还值得注意的是mongodump备份数据和索引定义；与其他方法相比，恢复时间也可能要长得多，因为mongorestore在加载数据后需要重新创建任何二级索引。

如MongoDB 文档中所述，mongodump对于备份和恢复小型部署很有用，但对于捕获大型系统的完整备份并不理想：

当连接到 MongoDB 实例时，mongodump 会对 mongod 性能产生不利影响。如果您的数据大于系统内存，查询会将工作集推出内存，从而导致页面错误。

如果您还希望在备份时保持部署可用，则独立服务器会限制您的备份选项。

以下是一些建议的方法，按推荐程度从高到低排列：

方法#1：使用云备份服务

对于最简单的短期解决方案，我会考虑使用像MongoDB Cloud Manager这样的商业云备份服务。MongoDB Cloud Manager 提供带有计划快照和保留策略的连续备份（有关更多信息，请参阅备份准备）。云服务还避免了您必须部署任何额外的服务器/基础设施，因此即使您计划将来这样做，这也是一个有用的短期解决方案。

一般方法是：

• 将您的独立服务器转换为单节点副本集（即使用replSet参数重新启动并运行rs.initiate()）。
• 注册MongoDB 云管理器。
• 下载并安装 Cloud Manager 备份代理。

作为一个额外的好处，Cloud Manager 还包括一个监控代理，它可以从您的部署中捕获指标历史记录并允许您配置警报。

方法#2：将您的部署转换为副本集并从隐藏的辅助节点进行备份

这种方法需要配置一些额外的基础设施，但可以减轻主服务器备份的影响。通常，副本集配备至少三个成员以实现高可用性和自动故障转移，但如果您的唯一目标是备份，则可以使用不太理想的两台服务器配置。

一般方法是：

• 提供将用于备份的第二台服务器
• 将您的独立服务器转换为副本集。
• 将您的备份服务器添加为优先级为 0（它永远不会成为主服务器）和 0 票的隐藏辅助服务器。
• 使用一种受支持的备份方法在隐藏的辅助设备上进行备份。备份方法按推荐的一般顺序列出：文件系统快照（如果您的配置支持）或文件复制（假设您停止mongod）优于mongodump.
• （理想情况下）如果您想要副本集配置的高可用性和故障转移优势，请添加另一个承载数据的辅助节点。

方法#3：使用文件系统快照（如果可用且适当）

假设您有一个支持快照的文件系统（并且您的所有数据和日志文件都在单个卷上，因此您可以获得运行中的一致快照），那么mongodump使用文件系统快照比您当前影响更小的备份策略是使用文件系统快照mongod。文件系统快照的好处是不必将所有数据读入内存mongod，但是快照仍然会产生影响（特别是在繁忙的系统上创建初始快照时）。连续快照效率更高且影响更小，但仍然不是完整的备份解决方案，因为快照位于您的服务器本地（并且您目前只有一个独立的）。

注意事项

• 方法#1 和#2 都涉及启用复制以促进备份。复制将在您的主服务器上添加一些额外的本地 I/O，因为所有写操作都记录在一个称为oplog（操作日志）的特殊上限集合中。

• 您已经提到将来可能需要进行分片，但在此之前，我会将您的 MongoDB 工作负载与共享同一服务器的其他进程隔离开来。如果您可以将备份策略更改为比 更有效的策略mongodump，消除资源争用，并捕获一些基线指标历史记录以供审核……您可能会发现还不需要分片。