MongoDB 在 Map/Reduce 上崩溃答案

【问题标题】：MongoDB crashes on Map/ReduceMongoDB 在 Map/Reduce 上崩溃
【发布时间】：2015-11-30 18:35:03
【问题描述】：

自去年以来，我一直使用 MongoDB 作为 1.5Tb+ 数据的主存储。一切都很好，但最近我决定对 14 000 000 个文档集合执行一些 map-reduce，我的生产实例出现故障。请看详情：

我的配置：

Ubuntu 12.04.5 LTS、MongoDB 2.6.4、LVM（2 个 HDD、1.5TB+ 免费，总共 3TB+）、24GB RAM（几乎全部免费）

Mongo 配置是默认的（除了 logpath 和 dbpath 参数）

蒙古日志：

2014-08-28T07:33:41.147+0400 [DataFileSync] 777 个文件的刷新 mmap 耗时 16177 毫秒 2014-08-28T07:33:44.004+0400 [conn13] M/R: (1/3) 发射进度: 9920300 2014-08-28T07:33:47.178+0400 [conn13] M/R: (1/3) 发射进度: 9928100 2014-08-28T07:33:50.004+0400 [conn13] M/R: (1/3) 发射进度: 9967800 2014-08-28T07:33:53.115+0400 [conn13] M/R: (1/3) 发射进度: 10007800 2014-08-28T07:33:56.009+0400 [conn13] M/R: (1/3) 发射进度: 10048800 2014-08-28T07:33:59.050+0400 [conn13] M/R: (1/3) 发射进度: 10091200 2014-08-28T07:34:02.530+0400 [conn13] M/R: (1/3) 发射进度: 10102300 2014-08-28T07:34:05.510+0400 [conn13] M/R: (1/3) 发射进度: 10102400 2014-08-28T07:34:08.932+0400 [conn13] 严重：地址无效访问：0x7cc8b2fe70b4 2014-08-28T07:34:08.983+0400 [conn13] 严重：收到信号：7（总线错误）。 Backtrace:0x11e6111 0x11e54ee 0x11e55df 0x7f5a7031ecb0 0xf29cad 0xf32f28 0xf32770 0x8b601f 0x8b693a 0x982885 0x988485 0x9966d8 0x9a3355 0xa2889a 0xa29ce2 0xa2bea6 0xd5dd6d 0xb9fe62 0xba1440 0x770aef mongod(_ZN5mongo15printStackTraceERSo+0x21) [0x11e6111] mongod() [0x11e54ee] mongod() [0x11e55df] /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0) [0x7f5a7031ecb0] mongod(_ZN5mongo16NamespaceDetails5allocEPNS_10CollectionERKNS_10StringDataEi+0x1bd) [0xf29cad] mongod(_ZN5mongo19SimpleRecordStoreV111allocRecordEii+0x68) [0xf32f28] mongod(_ZN5mongo17RecordStoreV1Base12insertRecordEPKcii+0x60) [0xf32770] mongod(_ZN5mongo10Collection15_insertDocumentERKNS_7BSONObjEbPKNS_16PregeneratedKeysE+0x7f) [0x8b601f] mongod(_ZN5mongo10Collection14insertDocumentERKNS_7BSONObjEbPKNS_16PregeneratedKeysE+0x22a) [0x8b693a] mongod(_ZN5mongo2mr5State12_insertToIncERNS_7BSONObjE+0x85) [0x982885] mongod(_ZN5mongo2mr5State14reduceInMemoryEv+0x175) [0x988485] mongod(_ZN5mongo2mr5State35reduceAndSpillInMemoryStateIfNeededEv+0x148) [0x9966d8] mongod(_ZN5mongo2mr16MapReduceCommand3runERKSsRNS_7BSONObjEiRSsRNS_14BSONObjBuilderEb+0xcc5) [0x9a3355] mongod(_ZN5mongo12_execCommandEPNS_7CommandERKSsRNS_7BSONObjEiRSsRNS_14BSONObjBuilderEb+0x3a) [0xa2889a] mongod(_ZN5mongo7Command11execCommandEPS0_RNS_6ClientEiPKcRNS_7BSONObjERNS_14BSONObjBuilderEb+0x1042) [0xa29ce2] mongod(_ZN5mongo12_runCommandsEPKcRNS_7BSONObjERNS_11_BufBuilderINS_16TrivialAllocatorEEERNS_14BSONObjBuilderEbi+0x6c6) [0xa2bea6] mongod(_ZN5mongo11newRunQueryERNS_7MessageERNS_12QueryMessageERNS_5CurOpES1_+0x22ed) [0xd5dd6d] mongod() [0xb9fe62] mongod(_ZN5mongo16assembleResponseERNS_7MessageERNS_10DbResponseERKNS_11HostAndPortE+0x580) [0xba1440] mongod(_ZN5mongo16MyMessageHandler7processERNS_7MessageEPNS_21AbstractMessagingPortEPNS_9LastErrorE+0x9f) [0x770aef]

在我第一次运行 map-reduce 后，我创建了 db.repairDatabase()，但在第二次尝试 map-reduce（修复后）后，同样的崩溃再次发生。现在，我不知道如何完成我的 m/r

各位，有什么想法吗？

【问题讨论】：

这听起来更像是硬件问题，或者至少是文件系统问题。您可能想查看 Jira 问题中的 SERVER-12849。或者用类似那里的更多细节提出自己的票。
感谢回复。完全同意，看起来像为 mongo 团队提出另一个 Jira 将成为一个案例
在提交 Jira 问题之前，我会寻找 I/O 或磁盘问题的迹象，正如 Neil 链接的服务器问题中所建议的那样。 Signal 7 (bus error) 表示硬件故障，因此可能不需要从 MongoDB 服务器端进行太多调查。如果您有 I/O 问题，您可能需要更换硬件（如果这影响了您的数据完整性，可能还需要从备份中恢复）。数据库修复将是最后的手段（即，如果您没有合适的备份并且数据文件已损坏）。
刚刚检查了 /var/log/syslog 和 dmesg。不过，那里没有可疑活动。还有其他地方应该仔细检查吗？
解决了吗？您找到导致它的硬件问题了吗？

标签： mongodb

【解决方案1】：

在调查了问题后，我最近想出了几件事：

按照 cmets 中的建议，我查看了 mongo jira ticket SERVER-12849 并仔细检查了我的日志。

/var/log/syslog 说：

内核：[1349503.760215] ata6.00：异常 Emask 0x0 SAct 0x3 SErr 0x0 操作 0x0 8 月 28 日 08:18:41 霸主内核：[1349503.760253] ata6.00: irq_stat 0x40000008 8 月 28 日 08:18:41 霸主内核：[1349503.760281] ata6.00：命令失败：READ FPDMA QUEUED 8 月 28 日 08:18:41 霸主内核：[1349503.760318] ata6.00: cmd 60/08:00:10:48:92/00:00:84:00:00/40 标签 0 ncq 4096 in 8 月 28 日 08:18:41 霸主内核：[1349503.760318] res 41/40:08:10:48:92/00:00:84:00:00/00 Emask 0x409（媒体错误） 8 月 28 日 08:18:41 霸主内核：[1349503.760411] ata6.00：状态：{ DRDY ERR } 8 月 28 日 08:18:41 霸主内核：[1349503.760437] ata6.00：错误：{ UNC } 8 月 28 日 08:18:41 霸主内核：[1349503.788325] ata6.00：为 UDMA/133 配置 8 月 28 日 08:18:41 霸主内核：[1349503.788340] sd 5:0:0:0: [sdb] 未处理的感知代码 8 月 28 日 08:18:41 霸主内核：[1349503.788343] sd 5:0:0:0: [sdb] 8 月 28 日 08:18:41 霸主内核：[1349503.788345] 结果：hostbyte=DID_OK driverbyte=DRIVER_SENSE 8 月 28 日 08:18:41 霸主内核：[1349503.788348] sd 5:0:0:0: [sdb] 8 月 28 日 08:18:41 霸主内核：[1349503.788350] Sense Key：Medium Error [current] [descriptor] 8 月 28 日 08:18:41 霸主内核：[1349503.788353] 带有感知描述符的描述符感知数据（十六进制）： 8 月 28 日 08:18:41 霸主内核：[1349503.788355] 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 8月28日08:18:41霸王内核：[1349503.788365]84 92 48 10 8 月 28 日 08:18:41 霸主内核：[1349503.788370] sd 5:0:0:0: [sdb] 8 月 28 日 08:18:41 霸王内核：[1349503.788373] 添加。感觉：未恢复的读取错误 - 自动重新分配失败 8 月 28 日 08:18:41 霸主内核：[1349503.788376] sd 5:0:0:0: [sdb] CDB： 8 月 28 日 08:18:41 霸主内核：[1349503.788377] 读取（10）：28 00 84 92 48 10 00 00 08 00 8 月 28 日 08:18:41 霸主内核：[1349503.788387] end_request：I/O 错误，dev sdb，扇区 2224179216 8 月 28 日 08:18:41 霸主内核：[1349503.788434] ata6：EH 完成

看起来 /dev/sdb 是罪魁祸首，让我们检查一下 SMART 状态（按照 jira 中的建议）

SMART 错误日志版本：1 ATA 错误计数：135（设备日志仅包含最近的五个错误） CR = 命令寄存器 [HEX] FR = 特征寄存器 [HEX] SC = 扇区计数寄存器 [HEX] SN = 扇区号寄存器 [HEX] CL = 气缸低位寄存器 [HEX] CH = 气缸高位寄存器 [HEX] DH = 设备/头寄存器 [HEX] DC = 设备命令寄存器 [HEX] ER = 错误寄存器 [HEX] ST = 状态寄存器 [HEX] Powered_Up_Time 从通电开始测量，并打印为 DDd+hh:mm:SS.sss 其中 DD=天，hh=小时，mm=分钟， SS = 秒，并且 sss = 毫秒。它在 49.710 天后“包裹”。磁盘开机寿命时出现错误 135：11930 小时（497 天 + 2 小时）发生导致错误的命令时，设备处于活动或空闲状态。命令完成后，寄存器为： ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 ff ff ff 0f 错误：LBA 处的 WP = 0x0fffffff = 268435455 导致导致错误的命令的命令是： CR FR SC SN CL CH DH DC Powered_Up_Time 命令/Feature_Name -- -- -- -- -- -- -- -- -- ------------------ -- 61 00 08 ff ff ff 4f 00 49d+12:01:35.512 写入 FPDMA 排队 60 00 08 ff ff ff 4f 00 49d+12:01:33.380 读取 FPDMA 排队 ea 00 00 00 00 00 a0 00 49d+12:01:33.294 刷新缓存 EXT 61 00 00 ff ff ff 4f 00 49d+12:01:33.292 写入 FPDMA 排队 ea 00 00 00 00 00 a0 00 49d+12:01:33.153 刷新缓存 EXT 磁盘开机寿命时出现错误 134：11930 小时（497 天 + 2 小时）发生导致错误的命令时，设备处于活动或空闲状态。命令完成后，寄存器为： ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 ff ff ff 0f 错误：LBA 处的 WP = 0x0fffffff = 268435455 导致导致错误的命令的命令是： CR FR SC SN CL CH DH DC Powered_Up_Time 命令/Feature_Name -- -- -- -- -- -- -- -- -- ------------------ -- 61 00 08 ff ff ff 4f 00 49d+11:17:00.189 写入 FPDMA 排队 61 00 10 ff ff ff 4f 00 49d+11:17:00.189 写入 FPDMA 排队 61 00 28 ff ff ff 4f 00 49d+11:17:00.188 写入 FPDMA 排队 61 00 08 ff ff ff 4f 00 49d+11:17:00.188 写入 FPDMA 排队 61 00 08 ff ff ff 4f 00 49d+11:17:00.188 写入 FPDMA 排队磁盘开机寿命时出现错误 133：11930 小时（497 天 + 2 小时）发生导致错误的命令时，设备处于活动或空闲状态。

所以，我们可以看到 /dev/sdb 上有错误，让我们做最后的检查 - 将整个数据复制到另一台主机并尝试在那里运行原始 map-reduce 脚本。

结果就是成功。

所以 mongo 没问题 在我的情况下。 mongo 日志中的（总线错误）日志条目似乎表明是时候检查您的硬件了。

【讨论】：