mongodb持久化(1)

Mongodb在1.8版本之后开始支持journal，就是我们常说的redo log，用于故障恢复和持久化。持久化为了保证数据永久保存不丢失。MongoDB具有高度可配置的持久化设置，从完全没有任何保证到完全持久化。下面介绍一下内容：1. MongoDB是如何保证持久化的2. 如何配

Mongodb在1.8版本之后开始支持journal，就是我们常说的redo log，用于故障恢复和持久化。 持久化为了保证数据永久保存不丢失。MongoDB具有高度可配置的持久化设置，从完全没有任何保证到完全持久化。下面介绍一下内容： 1. MongoDB是如何保证持久化的 2. 如何配置应用程序和服务器持久化等级来满足你的需求 3. 没有启用journal的影响 4. 什么是MongoDB保证不了的 MongoDB可以保证当服务器崩溃或服务器硬关机或硬盘故障时的数据完整性。在关系型数据库中通常是使用事务来保证数据的持久性。MongoDB是不支持事务的，那么是如何来保证的呢？

1. Journaling是干什么的

MongoDB journaling 工作原理 当执行写操作时，MongoDB创建一个journal来包含确切磁盘位置和改变的字节。因此，如果服务器突然崩溃，启动时，journal会重放崩溃前并没有刷新到磁盘上的任何写操作。 数据文件每隔60s刷新到磁盘上，默认情况下，因此journal只需要持有60s内的写入数据。journal预分配了几个空文件用于此目的，位于/data/db/journal，命名为_j.0,j.1等等。 MongoDB运行很长时间情况下，在journal目录下，你会看到类似于_j.6217,_j.6218和_j.6219文件。这些文件是当前的journal文件，如果MongoDB一直运行，这些数字会持续增加。当正常关闭MongoDB时，这些文件将被清除，因为正常关机不在需要这些日志的。 如果服务器崩溃或kill -9, mongodb再次启动时，会重放journal文件，会输出冗长难懂的检验行，这表明在正常的恢复。 1.1 有规划的批提交 默认情况下，MongoDB每隔100ms写入一次journal日志，几兆字节的数据被写入。这意味着mongodb批量提交更改，每个写不立即刷新到磁盘，但是默认设置，你不可能失去写入超过100ms的数据，在每个崩溃事件中。 然而，这种保证对某些应用不是足够强，所以有几种方法可以得到更强的持久化保证。你可以通过把j选项传递给getLastError来确保写入已经写入持久化。getLastError会等待上一次的写操作写入到journal和journaling只会等待30ms而不是100ms，journal下一批写。 > db.foo.insert({"x" : 1}) > db.runCommand({"getLastError" : 1, "j" : true}) > // The {"x" : 1} document is now safely on disk 请注意：如果每次写使用 "j" : true，意味着写的速度将基本控制在 33 writes/sec。(1 write/30ms) × (1000ms/second) = 33.3 writes/second 这一般并不需要太长的时间来刷新写入到磁盘，因此你会发觉写性能提高了，如果你允许mongodb批量大多数写，而不是一个一个的提交。该选项用在重要的写入操作。 提交之前已经提交过的写也是一样的，因此，如果有50个重要的写操作，可以使用“normal” getLastError 不带j选项，然后在最后的一个写操作用j选项，如果成功的，说明50个写操作被安全的刷新到磁盘了。 如果连接了多个写连接，可以使用j选项来并行写入，提高吐吞量，即使延迟高。 1.2 设置提交间隔 为了journaling侵入程度降低的另一种选择是，缩短或延长两者之间的journal提交。执行setParameter 命令来设置journalCommitInterval 值为2ms到500ms之间的值。下面设置journal每隔10ms提交： > db.adminCommand({"setParameter" : 1, "journalCommitInterval" : 10}) 该选项也可以在启动时设置 --journalCommitInterval。 不管间隔设置，调用getLastError "j" : true 时间将减少到三分之一。 如果客户端尝试写入速度比journal刷新快，mongodb将被阻塞，直到journal完成写入磁盘。 关闭journaling以及其他内容参见下节内容。

原文地址：mongodb 持久化(1), 感谢原作者分享。