mongodb 持久化(3)
- WBOYOriginal
- 2016-06-07 16:36:011116browse
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" : 15728640,
"firstRecord" : "1:155e0b0",
"lastRecord" : "1:1bbe4f0"
},
{
"loc" : "1:24ee000",
"xnext" : "1:392e000",
"xprev" : "1:155e000",
"nsdiag" : "ttlsa_com.posts",
"size" : 21233664,
"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')})
如果损坏并不局限于该文档，这种技术可能无法工作，你仍然需要进行修复。
3. 复制的持久性
复制集一个写可被回滚，直到它被写入到一个大多数的集合中。 > db.runCommand({"getLastError" : 1, "j" : true, "w" : "majority"}) 只能保证primary写入已经持久化，secondary未必持久化。原文地址：mongodb 持久化(3), 感谢原作者分享。
Statement：
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn
Previous article：Redis configuration rewritingNext article：Twemproxy, a Redis proxy from Twitter