« RAC Process Of LMON & LMD & LMSn | 文摘首页 | 商业周刊08年增长最快的美国科技公司 »
Linux Ext3日志模式对数据库的影响
ext3与ext2最大的区别就是ext3有日志，相信大家也知道ext3的日志模式有三种
◆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参数来也涉及到刷硬盘的问题。
原文出处：Logzgh
By eygle on 2008-09-18 17:27 | Comments (0) | Oracle摘 | 2032 |