5个常见的MongoDB故障排除场景及快速修复方法

MongoDB故障排除通常从应用变慢、写入失败或副本集落后开始。本指南将介绍五个在生产环境中常见的场景，并指出首先应该检查的地方。

在进行重大更改之前，先使用这些检查作为第一步。它们可以帮助你将查询问题与基础设施、复制或分片问题区分开来。

1. 慢查询性能

慢查询可能是生产环境中报告的最常见的性能问题。一个需要几秒而不是几毫秒的查询会严重降低应用的响应速度。

诊断：使用 explain()

诊断慢查询的第一步是了解它为什么慢。MongoDB的explain()方法是进行此分析的基本工具。它显示执行计划，详细说明使用了哪些索引（或未使用哪些索引）。

命令示例：

db.collection.find({ field: 'value' }).explain('executionStats')

分析输出，特别关注：

• winningPlan.stage：如果阶段是COLLSCAN，则MongoDB正在读取每个文档。这通常意味着缺少或无法使用的索引。
• executionStats.nReturned与executionStats.totalKeysExamined和executionStats.totalDocsExamined的比较。

快速修复

1. 创建正确的索引： 如果查询计划显示集合扫描，请添加与过滤和排序模式匹配的索引。例如，如果你的应用经常按user_id和最新的timestamp搜索订单，请创建一个复合索引：

db.orders.createIndex({ user_id: 1, timestamp: -1 }) ``` 2. 优化查询： 检查是否获取了太多数据。使用投影只返回页面或作业实际需要的字段。 3. 审查慢查询日志： 使用适合你工作负载阈值的分析器或慢查询日志。将任何确切的阈值视为操作选择，而不是通用规则。

提示： 索引提高读取速度，但会稍微减慢写入速度。仅索引在查询谓词（find()）、排序操作（sort()）或范围查询中频繁使用的字段。

2. 副本集中的复制延迟

当副本集的次要成员在应用操作日志中的操作时明显落后于主要成员时，就会发生复制延迟。

诊断：检查 replSetGetStatus

在副本集的任何成员上使用replSetGetStatus命令来检查所有成员的健康状况和同步状态。

命令示例：

rs.printReplicationInfo()
// 或者直接查询状态：
rs.status()

查看主要成员和次要成员的optimeDate。主要成员的操作时间与次要成员的操作时间之间的差异表示延迟，通常在每个成员的secsBehind字段中显示。

快速修复

1. 检查网络延迟： 成员之间的高延迟可能会减慢操作日志的传输。
2. 检查延迟的次要成员： 高CPU、慢速磁盘I/O或嘈杂的邻居工作负载可能会阻止次要成员足够快地应用写入。
3. 审查操作日志覆盖范围： 如果延迟严重，次要成员可能不再拥有所需的操作日志条目。在这种情况下，你可能需要重新同步或重建该成员。

3. 连接错误和身份验证失败

由于配置错误、防火墙问题或凭据不正确，应用服务经常无法连接到MongoDB。

诊断：检查日志和网络

首先，验证MongoDB服务器是否在预期的IP地址和端口上监听。检查MongoDB服务器日志以获取特定错误。

常见日志错误：

• Address already in use：另一个进程正在使用该端口。
• Connection refused：服务器进程已关闭、被阻止或在其他地方监听。
• Authentication failed：用户名、密码、身份验证数据库或角色分配错误。

快速修复

1. 检查防火墙规则： 确保MongoDB端口（通常为27017）可从应用主机访问。
2. 验证 bindIp： 如果mongod.conf仅绑定到127.0.0.1，则远程客户端无法连接。尽可能绑定到特定的私有接口。除非已实施网络控制和身份验证，否则避免使用0.0.0.0。
3. 检查 authSource： 如果用户在admin中创建，则连接字符串可能需要?authSource=admin。

4. 磁盘空间不足

作为文档数据库，MongoDB将数据直接存储在磁盘上。意外的数据增长或不当的数据库清理会迅速导致磁盘空间耗尽，从而停止所有写入操作。

诊断：监控和 db.stats()

使用操作系统监控工具（Linux上的df -h）检查整体磁盘使用情况。在MongoDB内部，使用db.stats()命令查看各个数据库消耗了多少空间。

命令示例：

db.stats()

特别关注storageSize和dataSize字段。

快速修复

1. 如果写入失败，争取时间： 停止非必要作业，删除不相关的临时文件，或者如果你的平台支持，扩展卷。
2. 删除未使用的数据： 只有在确认不再需要并且存在备份后，才删除旧的集合或数据库。
3. 谨慎压缩： 对于包含许多删除或更新的集合，compact可能会释放保留的空间，但可能会造成中断。针对你的MongoDB版本和存储引擎测试影响：

db.myCollection.runCommand({ compact: 'myCollection' }) ``` 4. 增加存储容量： 长期的解决方案通常是更大的磁盘、更好的保留规则或单独的日志和备份存储。

警告： 如果磁盘完全填满，MongoDB将停止写入以防止数据损坏。在尝试恢复正常操作之前，你必须解决空间问题。

5. 分片集群错误（陈旧的路由器/配置服务器）

在分片环境中，配置服务器（config servers）或查询路由器（mongos实例）内的连接或状态问题可能会使整个系统停止。

诊断：检查集群健康

针对mongos实例运行的sh.status()命令是分片健康的主要诊断工具。

可操作命令示例：

sh.status()

输出中需要检查的关键区域包括：

• 配置服务器： 确认配置服务器副本集具有健康的多数。
• 分片： 验证列出的每个分片都已连接并正确报告。
• 陈旧状态： 查找路由器或分片具有陈旧元数据的警告。

快速修复

1. 在适当时重启 mongos： 如果一个路由器陈旧或无响应，重启它可以强制与配置服务器建立新的连接。
2. 首先修复配置服务器健康： 如果配置服务器副本集缺乏健康的多数，分片元数据操作可能会失败。
3. 解决分片级别的问题： 如果分片由于磁盘压力或复制延迟而宕机，请在追踪路由器症状之前修复根本原因。

何时寻求专业帮助

当可能出现数据丢失、副本集需要重新同步、配置服务器不健康或磁盘空间已经影响写入时，请咨询MongoDB管理员或平台工程师。在生产环境中运行压缩或成员重建等破坏性命令之前，请寻求帮助。

总结

从最接近用户影响的症状开始MongoDB故障排除：页面缓慢、连接失败、写入停滞、次要成员延迟或分片集群错误。然后使用explain()、rs.status()、db.stats()和sh.status()来确认原因，然后再更改索引、重启路由器或重建成员。