Mongodb–journal探究

Mongodb在1.8版本之后开始支持journal，就是我们常说的redo log，用于故障恢复和持久化。

一、启动

启动journal功能使用mongod –journal选项，也可以关闭–nojournal，在2.0之后的版本，journal都是默认打开的，以确保数据安全。在version < 2.0 或者32位的系统上都是默认关闭的 。因为打开journal会使用更多的内存（下面会详细介绍），而32位系统支持的内存太小，所以关闭了。
由于Mongodb会事先初始化journal空间，而且在初始化完成之前是不会打开监听端口的，所以启动后可能会有一段时间连不上，不用紧张，查看日志，待journal初始化完成之后再连接。这里也建议，尽量使用ext4或者xfs等文件系统，诸如ext3这样的文件系统，初始化磁盘会非常慢，你会看到启动mongod之后，很长一段时间都停留在打印日志的状态，而用ext4会瞬间完成。而且Mongodb在运行时对db的空间也采用预分配的机制，所以使用更高级的文件系统是很有帮助的，防止磁盘引起的高并发下拥堵问题。

二、文件、恢复和备份

journal存放在数据文件的/journal/文件夹下，运行时的文件一般是这样的

其中j.32,j.33是使用中的journal文件，当单个文件达到1GB的时候，就会创建一个新的文件，旧文件不会循环使用，自动删除。lsn保存最后使用的journal序列号，是个2进制文件，跟mysql-bin.index作用差不多。prealloc.2是还未使用的初始化的journal文件。使用db.shutdownServer()和kill -2关闭的系统，也就是clean shutdown，journal文件夹下除prealloc.*文件 都会被删除。       如果系统掉电或者运行时死机，再启动时，mongo就会使用journal进行恢复，不用运行repair。
我们可以将journal，oplog，data做快照备份，在数据丢失的时候，可以恢复到最近的状态，保证安全。盛大的云计算系统就是这样做的，同时使用go语言做异步备份，有机会可以跟他们交流。

三、批量提交

journal除了故障恢复的作用之外，还可以提高写入的性能，批量提交（batch-commit），journal一般默认100ms刷新一次，在这个过程中，所有的写入都可以一次提交，是单事务的，全部成功或者全部失败。关于刷新时间，它是可以更改，上一篇博客有介绍，范围是2-300ms，但是这并不是绝对的。mongodb提供了journal延迟测试的函数，

db.runCommand(“journalLatencyTest”)：

在实际运行中，刷新时间是–journalCommitInterval设置和延迟测试中较大的一个。         不得不吐槽一下，有的服务器磁盘有cache却没有电池，情何以堪，在不走cache的情况下，延迟相当大，图中就是不走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：写journal的准备时间，时间越短，说明journal的性能越好 。 dur.timeMS.writeToJournal：真正的写入到journal的时间，比较抽象，因为写入到journal要经历很多步骤，之后会讲解。

dur.timeMS.writeToDataFiles：刷新journal到磁盘的时间，文件系统和磁盘会影响写入性能。
dur.timeMS.remapPrivateView：重新映射数据到PrivateView的时间，数据越小，性能越好。这个之后会介绍，这也是为什么journal会使用更多内存的原因，因为journal会另外使用一个叫PrivateView的内存区域。

因为journal会另外使用一个叫PrivateView的内存区域


journal的工作原理：
    首先要知道在这个原理中，存在着两个file，两个view。

两个file是 data file 和 journal file，两个view是 shared view 和 private view。两个file是对磁盘而言的，而两个view是对内存而言的
工作原理
data file---系统启动时----->shared view---开启了journal----->private view ---100ms----->journal file---应用到----->shared file---60s/每----->data file


启动服务后，MongoDB请求操作系统将Data file映射到Shared view，此时操作系统只管映射这个动作，并不将数据加载到Shared view中，而是由MongoDB在需要时再将数据进行加载到Shared view。在不开启journal的系统中，数据直接写入shared view，然后返回，
系统每60s刷新这块内存到磁盘。如果系统开启了journal功能，MongoDB再请求操作系统将Shared view映射到Private view，之后MongDB对数据的读写操作都是直接操作的Private view，
mongodb默认每100ms刷新privateView到journal，这个过程称为“group commit”.接下来，Journal file中记录的写操作会应用在Shared view上：默认每隔60秒，MongoDB请求操作系统将Shared view刷新输出到Data file：数据就被写入到数据文件了。
这时MongoDB还会将Journal file中已输出到Data file的写操作删除掉（由于MongoDB在将Journal file中写操作放到Shared view时，是通过了一个前指针和一个后指针来操作的，所以MongoDB知道哪些写操作是被放到Shared view了的，哪些没有）。
最后，MongoDB还会例行地如一开始一样，将Shared view映射到Private view，以保持一致性（也是防止Private view变得太过于脏了）。
Mongodb的隔离级别是read_uncommitted，不管使用不使用journal，都是以内存中的数据为准，只不过，不开启journal，数据从shared view读取，开启journal，数据从private view读取。


Journal file中记录的是原生的操作（raw operation），这些原生的操作可以使MongoDB完成以下操作：
    对文档的插入/更新（document insertion/updates）
    对索引的修改（index modifications）
    对命名空间文件的修改（changes to the namespace files）
这些原生操作告诉了Journal file数据变化发生在Data file的什么位置。至此，MongoDB上发生的写事件可以被认为是安全的了，因为这些写操作已经被记录在了Journal file上，即使服务器掉电了，在下次启动MongoDB时，Journal file上的写操作将会被重演。


开启journal的系统中，写操作从请求到写入磁盘共经历5个步骤，在serverStatus()中已经列出各个步骤消耗的时间。
①、Write to privateView
②、prepLogBuffer
③、WritetoJournal
④、WritetoDataFile
⑤、RemaptoPrivateView



1、preplogbuffer：
Private view(PV) 中的数据并不是直接刷新到journal文件，而是通过一个中间内存块（journalbuffer，或者alogned buffer）一部分一部分的刷新到journal，这样可以提高并发。preplogbuffer即是将PV中的数据写入到aligned buffer中的过程。这个过程有两部分，basic write 操作和非 basic write操作（e.g.create file）。一次preplogbuffer是以一个commitJob为一个单位，可能会有很多个commitJob写入到aligned buffer，然后提交。一个commitJob中包含多个basic write 和非basic write 操作，basic write是存在Writeintent结构体中的，Writeintent记录了写操作的地址信息。非basic write 操作存在一个vector中


Aligned buffer 有自己的结构，这也是写入到journalfile中的结构。包含Jheader，JsectHeader lsn，Durop，JSectFooter：


每个JsectHeader之间的Durop是属于一个事务范围，一起提交，一起成功，一起失败，即all-or-nothing.上篇文章中介绍的lsn文件，就是记录这个lsn号。
2、WritetoJournal：
writetoJournal操作是将alignedbuffer刷新到JournalFile的过程。默认100ms刷新一次，由--journalCommitInterval 参数控制。writetoJournal会做一些checksum验证，将alignedbuffer进行压缩，然后将压缩过后的alignedbuffer写入到磁盘。写入磁盘后将删除已经满的Journal文件，更新lsn号到lsn文件。写操作到这一步就是安全的了，因为数据已经在磁盘上，如果使用getlasterror（j=true），这一步即可返回。
3、WritetoDataFile：
WritetoDataFile是将未压缩的aligned buffer写入到shared view的过程，然后由操作系统刷新到磁盘文件中。WritetoDataFile首先会对aligned buffer进行严格的验证，确保没有改变过，然后解析aligned buffer，通过memcpy函数拷贝到shareview
4、RemaptoprivateView：
RemaptoprivateView会将持久化的数据重新映射到PV，以减小PV的大小，防止它不断扩大，按照源码上说，RemaptoprivateView会两秒钟重新映射一次，大约有1000个view，不是一次全做完，而是一部分一部分的做。由于读操作是读取PV，所以在映射完成之后会有短暂的时间读取磁盘。
经过这四步，一个写操作就完成了，journal提高了数据的安全性，并不像想象中的会丢数据，重要的是如何使用和维护。

总结：

mongodb在使用journal之后，备份，容灾得到保障，批量提交也使得写入更加快速（不持久化的不算）。我们也需要选用较高级的文件系统和磁盘还有更多的内存来保障journal的良好运行。下一篇博客会着重介绍journal的数据结构和工作原理。

################################################################

journal 日志也就是常说的redo log，用于故障恢复和持久化。默认是打开的。

Mongodb会事先初始化journal空间，而且在初始化完成之前是不会打开监控端口的。Mongodb在运行时对db的空间也是采用预分配的机制。

journal 存放在数据文件的/journal文件夹下。  journal文件是以“j._”开头命名的
j_xx 这样的文件代表正在使用的中的journal文件。单个文件达到1G的时候，会创建一个新的文件，旧文件不会删除也不会循环使用。
lsn文件保存最后使用的journal序列号，是个二进制文件，它实际保存的是系统启动后到现在的一个时间戳。

prealloc.x代表还未使用的初始化的journal文件。