mongodb持久化(3)

来源：动视网责编：小采时间：2020-11-09 13:10:43

mongodb持久化(3)

mongodb持久化(3):1. 载体崩溃当出现硬件问题或文件系统出错，特别是硬盘损坏了，就没法保护数据安全了。另外，不同品牌的硬件和软件具有不同的持久保证的。总而言之，如果硬件或文件系统破坏了数据，MongoDB是无法保护数据的，这已经属于底层存储的事情了。可以使用复制来避

推荐度：

点击下载本文 文档为doc格式

导读mongodb持久化(3):1. 载体崩溃当出现硬件问题或文件系统出错，特别是硬盘损坏了，就没法保护数据安全了。另外，不同品牌的硬件和软件具有不同的持久保证的。总而言之，如果硬件或文件系统破坏了数据，MongoDB是无法保护数据的，这已经属于底层存储的事情了。可以使用复制来避

1. 载体崩溃当出现硬件问题或文件系统出错，特别是硬盘损坏了，就没法保护数据安全了。另外，不同品牌的硬件和软件具有不同的持久保证的。总而言之，如果硬件或文件系统破坏了数据，MongoDB是无法保护数据的，这已经属于底层存储的事情了。可以使用复制来避

1. 载体崩溃

当出现硬件问题或文件系统出错，特别是硬盘损坏了，就没法保护数据安全了。另外，不同品牌的硬件和软件具有不同的持久保证的。总而言之，如果硬件或文件系统破坏了数据，MongoDB是无法保护数据的，这已经属于底层存储的事情了。可以使用复制来避免这个问题，其实就是单点问题了。

2. ?检查损坏

validate命令用来检测一个集合的损坏，如：

> db.posts.validate({full:true})
{
 "ns" : "ttlsa_com.posts",
 "firstExtent" : "1:1036000 ns:ttlsa_com.posts",
 "lastExtent" : "4:2000 ns:ttlsa_com.posts",
 "extentCount" : 14,
 "extents" : [
 {
 "loc" : "1:1036000",
 "xnext" : "1:104e000",
 "xprev" : "null",
 "nsdiag" : "ttlsa_com.posts",
 "size" : 61440,
 "firstRecord" : "1:1037c30",
 "lastRecord" : "1:103e4f0"
 },
 {
 "loc" : "1:104e000",
 "xnext" : "1:108a000",
 "xprev" : "1:1036000",
 "nsdiag" : "ttlsa_com.posts",
 "size" : 245760,
 "firstRecord" : "1:104e0b0",
 "lastRecord" : "1:10556b0"
 },
 {
 "loc" : "1:108a000",
 "xnext" : "1:117a000",
 "xprev" : "1:104e000",
 "nsdiag" : "ttlsa_com.posts",
 "size" : 983040,
 "firstRecord" : "1:108a0b0",
 "lastRecord" : "1:109a9b0"
 },
 {
 "loc" : "1:117a000",
 "xnext" : "1:155e000",
 "xprev" : "1:108a000",
 "nsdiag" : "ttlsa_com.posts",
 "size" : 3932160,
 "firstRecord" : "1:117a0b0",
 "lastRecord" : "1:13739f0"
 },
 {
 "loc" : "1:155e000",
 "xnext" : "1:24ee000",
 "xprev" : "1:117a000",
 "nsdiag" : "ttlsa_com.posts",
 "size" : 157280,
 "firstRecord" : "1:155e0b0",
 "lastRecord" : "1:1bbe4f0"
 },
 {
 "loc" : "1:24ee000",
 "xnext" : "1:392e000",
 "xprev" : "1:155e000",
 "nsdiag" : "ttlsa_com.posts",
 "size" : 212336,
 "firstRecord" : "1:24ee8b0",
 "lastRecord" : "1:2b485b0"
 },
 {
 "loc" : "1:392e000",
 "xnext" : "1:56c5000",
 "xprev" : "1:24ee000",
 "nsdiag" : "ttlsa_com.posts",
 "size" : 28667904,
 "firstRecord" : "1:392e0b0",
 "lastRecord" : "1:450dd30"
 },
 {
 "loc" : "1:56c5000",
 "xnext" : "2:2000",
 "xprev" : "1:392e000",
 "nsdiag" : "ttlsa_com.posts",
 "size" : 38703104,
 "firstRecord" : "1:56c50b0",
 "lastRecord" : "1:617c0b0"
 },
 {
 "loc" : "2:2000",
 "xnext" : "2:3ad7000",
 "xprev" : "1:56c5000",
 "nsdiag" : "ttlsa_com.posts",
 "size" : 52252672,
 "firstRecord" : "2:20b0",
 "lastRecord" : "2:188ac30"
 },
 {
 "loc" : "2:3ad7000",
 "xnext" : "2:7e1d000",
 "xprev" : "2:2000",
 "nsdiag" : "ttlsa_com.posts",
 "size" : 70541312,
 "firstRecord" : "2:3ad7470",
 "lastRecord" : "2:66b8af0"
 },
 {
 "loc" : "2:7e1d000",
 "xnext" : "3:2000",
 "xprev" : "2:3ad7000",
 "nsdiag" : "ttlsa_com.posts",
 "size" : 95232000,
 "firstRecord" : "2:7e1d0b0",
 "lastRecord" : "2:be8a2b0"
 },
 {
 "loc" : "3:2000",
 "xnext" : "3:dd21000",
 "xprev" : "2:7e1d000",
 "nsdiag" : "ttlsa_com.posts",
 "size" : 128565248,
 "firstRecord" : "3:20b0",
 "lastRecord" : "3:63eb670"
 },
 {
 "loc" : "3:dd21000",
 "xnext" : "4:2000",
 "xprev" : "3:2000",
 "nsdiag" : "ttlsa_com.posts",
 "size" : 173563904,
 "firstRecord" : "3:dd210b0",
 "lastRecord" : "3:12fccc30"
 },
 {
 "loc" : "4:2000",
 "xnext" : "null",
 "xprev" : "3:dd21000",
 "nsdiag" : "ttlsa_com.posts",
 "size" : 234311680,
 "firstRecord" : "4:20b0",
 "lastRecord" : "4:7bec3b0"
 }
 ],
 "datasize" : 614217440,
 "nrecords" : 305603,
 "lastExtentSize" : 234311680,
 "padding" : 1.0000000000221079,
 "firstExtentDetails" : {
 "loc" : "1:1036000",
 "xnext" : "1:104e000",
 "xprev" : "null",
 "nsdiag" : "ttlsa_com.posts",
 "size" : 61440,
 "firstRecord" : "1:1037c30",
 "lastRecord" : "1:103e4f0"
 },
 "lastExtentDetails" : {
 "loc" : "4:2000",
 "xnext" : "null",
 "xprev" : "3:dd21000",
 "nsdiag" : "ttlsa_com.posts",
 "size" : 234311680,
 "firstRecord" : "4:20b0",
 "lastRecord" : "4:7bec3b0"
 },
 "objectsFound" : 305603,
 "invalidObjects" : 0,
 "bytesWithHeaders" : 619107088,
 "bytesWithoutHeaders" : 614217440,
 "deletedCount" : 125358,
 "deletedSize" : 244912976,
 "nIndexes" : 9,
 "keysPerIndex" : {
 "ttlsa_com.posts.$_id_" : 305603,
 "ttlsa_com.posts.$index_doctorSn" : 305603,
 "ttlsa_com.posts.$index_doctorUid" : 305603,
 "ttlsa_com.posts.$index_hosDeptId" : 305603,
 "ttlsa_com.posts.$index_hospitalId" : 305603,
 "ttlsa_com.posts.$doctorNumberList_1_doctorOrderId_-1" : 305924,
 "ttlsa_com.posts.$cityId_1_displayStatus_1" : 305603,
 "ttlsa_com.posts.$standardDeptId_1_displayStatus_1" : 305603,
 "ttlsa_com.posts.$doctorCode_1" : 305603
 },
 "valid" : true,
 "errors" : [ ],
 "ok" : 1
}

在上面输出底部，有个"valid" : true 说明没有损坏，如果不是，会找到一些损坏的细节。大部分输出是描述集合内部的结构，对于调试不是特别有用的。只能检测集合，不能检测索引。如果出现无效的BSONbj，通常就是损坏了。最糟糕的是出现pdfile，pdfile基本上是mongodb的数据存储核心，几乎可以判断数据文件已经损坏了。如果出现损坏，会看到下面的日志信息： Tue Dec 20 01:12:09 [initandlisten] Assertion: 10334: Invalid BSONObj size: 285213831 (0x87040011) first element: _id: ObjectId('4e5efa454b4ae20fa6000013') 如果第一个元素显示的是垃圾，不需要做什么。如果第一个元素是可见的，可以移除损坏的文档。如： > db.remove({_id: ObjectId('4e5efa454b4ae20fa6000013')}) 如果损坏并不局限于该文档，这种技术可能无法工作，你仍然需要进行修复。