【第22期】观点:IT 行业加班,到底有没有价值?

Mongodb持久化--journal探究

转载 2013年12月06日 10:16:00

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/文件夹下,运行时的文件一般是这样的

12321312

      其中j.32,j.33是使用中的journal文件,当单个文件达到1GB的时候,就会创建一个新的文件,旧文件不会循环使用,自动删除。lsn保存最后使用的journal序列号,是个2进制文件,它实际保存的是系统启动到现在的一个时间戳。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"): 

latency

       在实际运行中,刷新时间是--journalCommitInterval设置和延迟测试中较大的一个。  
       不得不吐槽一下,有的服务器磁盘有cache却没有电池,情何以堪,在不走cache的情况下,延迟相当大,图中就是不走cache的情况。mongo也是支持ssd的,有条件可以使用。在比较繁忙的系统上,当journal和data放在一个volume上的时候,这个值也会比较大。 
查看journal运行情况 
db.serverStatus(): 

2123

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的内存区域。
 

当系统启动时,mongodb会将数据文件映射到一块内存区域,称之为Shared view,在不开启journal的系统中,数据直接写入shared view,然后返回,系统每60s刷新这块内存到磁盘,这样,如果断电或down机,就会丢失很多内存中未持久化的数据。当系统开启了journal功能,系统会再映射一块内存区域供journal使用,称之为private view,mongodb默认每100ms刷新privateView到journal,也就是说,断电或宕机,有可能丢失这100ms数据,一般都是可以忍受的,如果不能忍受,那就用程序写log吧。这也是为什么开启journal后mongod使用的虚拟内存是之前的两倍。Mongodb的隔离级别是read_uncommitted,不管使用不使用journal,都是以内存中的数据为准,只不过,不开启journal,数据从shared view读取,开启journal,数据从private view读取。

在开启journal的系统中,写操作从请求到写入磁盘共经历5个步骤,在serverStatus()中已经列出各个步骤消耗的时间。

①、Write to privateView

②、prepLogBuffer

③、WritetoJournal

④、WritetoDataFile

⑤、RemaptoPrivateView

下面详细介绍每个步骤的过程:

流程图:

图片1

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中。

具体结构如下。

图片2

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

3

每个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提高了数据的安全性,并不像想象中的会丢数据,重要的是如何使用和维护。


journal文件在MongoDB中的作用相当于redo日志文件在oracle中的作用,它可以在即使服务器意外宕机的情况下,将数据库操作进行重演。

在64位的机器上,2.0以上版本默认是开启了journal的,但是在32位机器上,或者2.0以下的版本中,默认是不开启journal的。所以在我的安装了2.4.3版本的32位机器上,每次启动mongodb都提示“warning: 32-bit servers don't have journaling enabled by default. Please use --journal if you want durability.”,所以我须要在启动mongodb时带上 --journal 参数;而在默认启动journal的机器上如果不想启动journal,则可以带上 --nojournal 参数。

第一次启动带启用journal的服务前,通常磁盘上是没有journal file的,这时mongodb就会现在磁盘上为journal文件分配磁盘空间,这个过程会花比较长的时间(所以老师的视频演示中,第一次启动服务时花了很长的时间),在这段时间内服务是不可用的。如果想避免这个预分配动作也是可以的,就是从别的mongodb实例中拷贝一个已经预分配的文件,然后放到自己的journal路径中,这个预分配文件是不含数据的,因此是这种操作方式是安全的。另外,我在网上看到有人说如果采用ext4的文件系统,这个预分配的时间就会减小很多(据说ext4在ext3基础上性能的提高,比ext3在ext2基础上性能的提高要高不少),可惜我在尝试做这个实验时,尝试了几次把虚拟机CentOS上的ext3文件系统转为ext4都没有成功,所以最终放弃了这个实验,希望如果有人做了这个实验的话,将过程分享分享。

默认情况下mongodb每100毫秒往journal文件中flush一次数据,不过这是在数据文件和journal文件处于同一磁盘卷上的情况,而如果数据文件和journal文件不在同一磁盘卷上时,默认刷新输出时间是30毫秒。不过这个毫秒值是可以修改的,可修改范围是2~300,值越低,刷新输出频率越高,数据安全度也就越高,但磁盘性能上的开销也更高。

journal文件是以“j._”开头命名的,且是append only的,如果1个journal文件满了1G大小,mongodb就会新创建一个journal文件来使用,一旦某个journal文件所记载的写操作都被使用过了,mongodb就会把这个journal文件删除。通常在journal文件所在的文件夹下,只会存在2~3个journal文件,除非你使用mongodb每秒都写入大量的数据。而使用 smallfiles 这个运行时选项可以将journal文件大小减至128M大小。


Journal的工作原理:
    首先要知道在这个原理中,存在着两个file,两个view。两个file是 data file 和 journal file,两个view是 shared view 和 private view。两个file是对磁盘而言的,而两个view是对内存而言的,下面以图解的方式解释:

启动服务前:
1.PNG

启动服务后,MongoDB请求操作系统将Data file映射到Shared view,此时操作系统只管映射这个动作,并不将数据加载到Shared view中,而是由MongoDB在需要时再将数据进行加载到Shared view。
2.PNG

然后,MongoDB再请求操作系统将Shared view映射到Private view,之后MongDB对数据的读写操作都是直接操作的Private view:
3.PNG

如果发生了写操作:
4.PNG

Private view变脏以后,根据journalCommitInterval的设置,将在一定时间后将写操作往Journal file中复制,这个过程称为“group commit”:
5.PNG
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上的写操作将会被重演。

但是在journalCommitInterval这个时间内如果服务器掉电,还是会损失数据

接下来,Journal file中记录的写操作会应用在Shared view上:
6.PNG

默认每隔60秒,MongoDB请求操作系统将Shared view刷新输出到Data file:
7.PNG
数据就被写入到数据文件了。这时MongoDB还会将Journal file中已输出到Data file的写操作删除掉(由于MongoDB在将Journal file中写操作放到Shared view时,是通过了一个前指针和一个后指针来操作的,所以MongoDB知道哪些写操作是被放到Shared view了的,哪些没有)。

最后,MongoDB还会例行地如一开始一样,将Shared view映射到Private view,以保持一致性(也是防止Private view变得太过于脏了)。
8.PNG

 

举报

相关文章推荐

Java定时框架Quartz实例详解与定时任务的Mongodb、Mysql持久化实现(二)Quartz配置文件

Quartz核心配置文件quartz.properties常见配置详解(配置在classpath中或在web.xml中指定,示例附在最后) 一、调度器属性配置 1、instanceName属性,调度器...

spring集成quartz持久化简单应用

最近在做定时跑批任务的时候用开始接触quartz,写了一个简单的demo,由于经验不足,原理还没有深入理解,有什么不对之处还请各位博友加以指正 首先,quartz在与spring集成是是有版本匹配问题的:quartz-1.x与spring3.1之前的版本对应,而quartz2.x与spring3....

程序员升职加薪指南!还缺一个“证”!

CSDN出品,立即查看!

kestrel 源码分析之四 Journal消息持久化类

上文我们看到PersistentQueue类的实现,它就代表每个消息队列在服务其中的实现,另外我们会看到每个PersistentQueue类包含一个Journal对象,该对象主要是负责队列的持久化操作。对于文件的读写我们用Java NIO来实现。下面我们来看一看主要的几个方法 [code=&quo...

Mongodb持久化--journal探究(一

Mongodb持久化--journal探究(一) 2012-10-22 19:17:14 分类: Mysql/postgreSQL Mongodb在1.8版本之后开始支持journal...
  • sata1
  • sata1
  • 2013-07-24 16:21
  • 390

Redis学习笔记9--Redis持久化

redis是一个支持持久化的内存数据库,也就是说redis需要经常将内存中的数据同步到磁盘来保证持久化。redis支持四
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)