Mongodump确实影响应用程序性能

我们有一个很大的mongo实例（150 GB），没有分片，而我们的常规备份（mongodump）对应用程序性能有非常重要的影响。更糟糕的是，由于该应用大量使用mongo，备份持续了10多个小时。

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

我可以做些什么来改善此情况，例如限制mongodump每秒的查询数量或其他任何操作？

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

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

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

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

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

以下是从最推荐到最不推荐的几种建议方法：

方法1：使用云备份服务

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

通用方法是：

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

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

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

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

通用方法是：

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

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

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

注意事项

• 方法1和方法2都涉及启用复制以简化备份。复制将在您的主服务器上添加一些其他本地I / O，因为所有写入操作均在称为oplog（操作日志）的特殊带帽集合中记录。

• 您已经提到了将来可能需要分片，但是在这样做之前，我会将您的MongoDB工作负载与共享同一服务器的其他进程隔离开来。如果您可以将备份策略更改为比更有效率的方法mongodump，则可以消除资源争用并捕获一些基准指标历史记录以供查看...您可能会发现尚不需要分片。

我参加聚会很晚，但是直到最近才在具有相对少量RAM（4 GB RAM，50 GB HD，5 GB数据）的VM上遇到了相同的问题。我们的解决方法是使用mongodump的选项--forceTableScan，如果应该使用第二选项，还添加--readPreference secondary。这使我们的转储速度加快了10到30倍。