InnoDB implements a checkpoint mechanism known as “fuzzy” checkpointing.
InnoDB flushes modified database pages from the buffer pool in small batches. --innodb会批量的把buffer pool中的脏页刷新到磁盘,称之为检查点. There is no need to flush the buffer
pool in one single batch, which would in practice stop processing of user SQL statements during the checkpointing process.--并不是在一次刷新中刷新所有的内容,因为这样会降低mysql的性能.甚至无法提供服务.
During crash recovery, InnoDB looks for a checkpoint label written to the log files. It knows that all modifications to the database before the label are present
in the disk image of the database. Then InnoDB scans the log files forward from the checkpoint, applying the logged modifications to the database--在恢复的过程中,innodb会向前扫描事务日志,把这些脏数据刷新到磁盘中.
InnoDB writes to its log files on a rotating basis. All committed modifications that make the database pages in the buffer pool different from the images on disk
must be available in the log files in case InnoDB has to do a recovery. This means that when
InnoDB starts to reuse a log file, it has to make sure that the database page images on disk contain the modifications logged in the log file that
InnoDB is going to reuse. In other words,
InnoDB must create a checkpoint and this often involves flushing of modified database pages to disk.--innodb循环的使用它的事务日志,所以旧的日志必然在未来某一时刻被覆盖,innodb必须保证,在旧日志被覆盖之前,与这些旧的日志条目相关的脏数据都被刷新到了磁盘.如果这一点不能保证,那么万一服务器crash,buffer
pool中的脏页就永远也无法恢复了.所以在切换日志的时候,innodb必然会做检查点,把所有的脏页都刷新到磁盘.
The preceding description explains why making your log files very large may reduce disk I/O in checkpointing. It often makes sense to set the total size of the log files as large as the buffer pool or even larger. The disadvantage
of using large log files is that crash recovery can take longer because there is more logged information to apply to the database--从这个意义上,innodb的事务日志越大,节省的磁盘IO越多,对系统性能越好.但是crash后恢复的时间肯定会变长.
innodb的检查点每隔几秒就会做一次.只是经过日志切换后,在日志被重用前,该日志的内容必须被全部刷新到磁盘.否则,系统就会被hung住.尝试用大一点的事务日志,可以减少检查点过程中写磁盘的次数--之所以可以减少,是因为IO的合并.