Mongodb在1.8版本之后开始支持journal，就是我们常说的redo log，用于故障恢复和持久化。1. 启动启动journal功能使用mongod –journal选项，也可以关闭–nojournal，在2.0之后的版本，journal都是默认打开的，以确保数据安全。在version 2.0 或者32位的系统
Mongodb在1.8版本之后开始支持journal，就是我们常说的redo log，用于故障恢复和持久化。1. 启动启动journal功能使用mongod –journal选项，也可以关闭–nojournal，在2.0之后的版本，journal都是默认打开的，以确保数据安全。在version db.runCommand(“journalLatencyTest”)在实际运行中，刷新时间是–journalCommitInterval设置和延迟测试中较大的一个。不得不吐槽一下，有的服务器磁盘有cache却没有电池，情何以堪，在不走cache的情况下，延迟相当本文来源[email protected]搞@^&代*@码)网5大，图中就是不走cache的情况。mongo也是支持ssd的，有条件可以使用。在比较繁忙的系统上，当journal和data放在一个volume上的时候，这个值也会比较大。查看journal运行情况:>?db.serverStatus():commits:在journalCommitInterval时间内提交的操作数。journaledMB：在journalCommitInterval时间内写到journal文件中的数据量 。writeToDataFilesMB：在journalCommitInterval时间内从journal刷新到磁盘的数据量 。compression：v>2.0，表示客户端提交写入到journal的数据的压缩比率，注意，写入到journal的数据并不是全部的数据。( journaled_size_of_data / uncompressed_size_of_data ) 。commitsInWriteLock:在有写锁的情况下提交的数量，这表示写的压力很大。earlyCommits：表示在journalCommitInterval之前的时间，mongod请求提交的次数。用这个参数确定journalCommitInterval是不是设置的过长。dur.timeMS.prepLogBuffer：从privateView映射到Logbuffer的时间。dur.timeMS.writeToJournal：从logbuffer刷新到journalfile 的时间。dur.timeMS.writeToDataFiles：从journalbuffer映射到MMF，然后从MMF刷新到磁盘的时间，文件系统和磁盘会影响写入性能。dur.timeMS.remapPrivateView：重新映射数据到PrivateView的时间，越小性能越好。这个之后会介绍，这也是为什么journal会使用更多内存的原因，因为journal会另外使用一个叫PrivateView的内存区域。4.?总结：mongodb在使用journal之后，备份，容灾得到保障，批量提交也使得写入更加快速（不持久化的不算）。我们也需要选用较高级的文件系统和磁盘还有更多的内存来保障journal的良好运行。参考：http://docs.mongodb.org/manual/reference/server-status/#durhttp://www.mongodb.org/display/DOCS/Journalinghttp://www.mongodb.org/display/DOCS/Journaling+Administration+Notes转自：http://blog.chinaunix.net/uid-15795819-id-3381684.html
原文地址：mongodb 持久化(4), 感谢原作者分享。
转载请注明原文链接：mongodb 持久化(4)
