ITPub博客

首页 > 数据库 > 数据库开发技术 > ext3的日志模式对数据库的影响

ext3的日志模式对数据库的影响

原创 数据库开发技术 作者:logzgh 时间:2008-08-02 23:30:25 0 删除 编辑

ext3ext2最大的区别就是ext3有日志,相信大家也知道ext3的日志模式有三种

[@more@]

◆data=journal日志模式

日志中记录包括所有改变文件系统的数据和元数据。它是三种ext3日志模式中最慢的,也是最安全的一种。每个变化需要写磁盘2次、日志写1次。所有新数据首先被写入日志,然后才被定位。意外发生过后,日志可以被重放,将数据与元数据带回一致状态。

◆data=ordered日志模式

仅记录改变文件系统的元数据,且溢出文件数据要补充到磁盘中。这是缺省的ext3日志模式。文件数据的变化情况并不被记录在日志中,但它们必须做,而且由ext3的daemon程序在与之相关的文件系统元数据变化前执行,即在记录元数据前要修改文件系统数据,这将稍微降低系统的性能(速度),然而可确保文件系统中的文件数据与相应文件系统的元数据同步。

◆data=writeback日志模式

仅记录改变文件系统的元数据,但根据标准文件系统,写程序仍要将文件数据的变化记录在磁盘上,以保持文件系统一致性。这是速度最快的ext3日志模式。因为它只记录元数据的变化,而不需等待与文件数据相关的更新如文件大小、目录信息等情况,对文件数据的更新与记录元数据变化可以不同步,即ext3是支持异步的日志。缺陷是当系统关闭时,更新的数据因不能被写入磁盘而出现矛盾,这一点目前尚不能很好解决。

ext3文件系统还涉及到如何cache中的数据刷到硬盘上。它是通过kupdate进程来实现定期刷的,默认是5秒检查一次,将超过30秒的脏数据刷到硬盘。在as 3.0中可以通过修改/proc/sys/vm/bdflush来达到目的。

而在as 4.0中可以通过修改/proc/sys/vm/dirty_writeback_centisecs和/proc/sys/vm/dirty_expire_centisecs来达到目的。

由于默认是ordered模式,在这种模式下面,如果一个IO先写数据文件,然后再写日志文件。假如说在写完数据文件之后,写日志文件之前时,系统发生crashed,则这部分数据将会丢失,这在数据库是绝对不允许的,不管是Oracle还是MySQL。所以对数据库的写来说,每一次写操作都会先写到pagecache中,然后通知kernelthread 将这个buffers刷到硬盘,然后再写将元数据写日志,最后才返回写成功的操作。这样对数据库来说写操作是明显不如写祼设备快。

所以说在采用Ext3跑数据库的情况下,将日志模式设为journal模式,性能反而应该会有所提升(没有测试过,理论上分析应该是这样) 因为在journal模式下数据库一个写操作,先是直接将数据和文件系统的变化写到日志中(绕开cache直接写,性能较好),然后将数据写到cache中,接着由kupdate进程将数据刷新到硬盘上。 相比之下,对DB来讲,它的性能应该比前面一种要快。

另外这里还提一下MySQL中的sync_binlog这个参数。如果将这个参数设为1,也就是说每次写binlog文件将同时刷到硬盘上面去,就像Oracle的写IO一样。如果将这个参数关闭,则它交给OS来管理,也就是每5秒检查一次,发现有30秒以前的老数据则刷到硬盘上。innodb_flush_log_at_trx_commit参数来也涉及到刷硬盘的问题。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/100091/viewspace-1008372/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
  • 博文量
    97
  • 访问量
    976788