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未必持久化。