MySQL5.6 RC innodb_log_compressed_pages 测试 及实现简述

MySQL5.6 RC增加了一个参数innodb_log_compressed_pages，以判定在压缩page时，是否在redo中存储压缩页数据。

最近把该特性在5.5.18上做了实现，从测试的效果来看，大大减少了redo log的写入量（降低到1/3~1/5），这会降低checkpoint的概率，并稍微增加了tps

以下数据，包括tps及每秒的log平均写入量（采集自status值Innodb_os_log_written）

后续还需要做一些相关的crash恢复测试

////////////////////////////////////////////////////////////////

其他：innodb_log_compressed_pages主要修改细节

原本innodb记录每个压缩Page到redo中，目的是为了防止在崩溃恢复时，压缩的算法发生改变，尤其在引入了可调整的压缩级别(innodb_compression_level)后，如果重启后，使用不同的level，就可能无法恢复出一致的压缩页

mlog的背景知识可以参考这个：

http://www.mysqlops.com/2012/04/06/innodb-log2.html

目前对mini-transaction、redo以及崩溃恢复机制还不是特别了解，以下只是简述，并未深入。

1.btr_page_reorganize_low

@增加参数 compression_level

@在做page reorgnize之前，需要先写入一条mlog

之前是写入一条MLOG_COMP_PAGE_REORGANIZE或者MLOG_PAGE_REORGANIZE类型的mlog(mlog_open_and_write_index)

新的实现，增加了针对压缩表mlog类型MLOG_ZIP_PAGE_REORGANIZE，会写入压缩级别值。（在崩溃恢复时，也会调用到该函数，但mtr->log_mode为MTR_LOG_NONE，这时候不记录mlog）

例如，insert产生的调用栈为：

row_ins_index_entry->row_ins_index_entry_low->btr_cur_optimistic_insert->btr_page_reorganize->btr_page_reorganize_low

2.btr_cur_update_alloc_zip

这个函数用于检查压缩页中的mlog是否有足够的位置，如果没有，则需要重压缩，我们将page_zip_compress的mtr参数设置为NULL，就可以避免压缩页被写到redo中。

但我们需要写入一条redo log。记录压缩级别，因此引入了新的函数page_zip_compress_write_log_no_data以实现此功能，该函数会写入一条MLOG_ZIP_PAGE_COMPRESS_NO_DATA类型的redo log.

3.page_cur_insert_rec_zip_reorg

如果调用page_zip_compress压缩成功，并且关闭选项，则记录一条插入的redo log（page_cur_insert_rec_write_log，还没理清楚….），并调用page_zip_compress_write_log_no_data写入compress level.

4.为了实现崩溃恢复，recv_parse_or_apply_log_rec_body函数用于解析redo log中的记录并进行应用，有一大串的switch case，用以针对不同的mlog类型调用相应的函数

case MLOG_ZIP_PAGE_REORGANIZE:

–>和MLOG_PAGE_REORGANIZE以及MLOG_COMP_PAGE_REORGANIZE一样调用的是btr_parse_page_reorganize，btr_parse_page_reorganize会先从mlog中读取compress level，然后再调用btr_page_reorganize_low来重组织page

case MLOG_ZIP_PAGE_COMPRESS_NO_DATA:

–>增加新函数page_zip_parse_compress_no_data

读取redo log中记录的压缩级别，然后调用page_zip_compress做page压缩，这样可以保证崩溃前后压缩的数据是一样的。