mongodb 持久化(3)

1. 载体崩溃

当出现硬件问题或文件系统出错，特别是硬盘损坏了，就没法保护数据安全了。另外，不同品牌的硬件和软件具有不同的持久保证的。

总而言之，如果硬件或文件系统破坏了数据，MongoDB是无法保护数据的，这已经属于底层存储的事情了。可以使用复制来避免这个问题，其实就是单点问题了。

2.  检查损坏

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

在上面输出底部，有个"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未必持久化。