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)

innodb_log_compressed_pages
=0
innodb_log_compressed_pages
=1
Prepare data
 8333 rows/s   
 2.37MB/s
8130 rows/s
6.79MB/s
update_non_index.lua
1880.32 per sec 
3.26MB/s
1780.51 per sec
16.56MB/s
update_index.lua
1896.34 per sec
3.19MB/s
1824.21 per sec
16.93MB/s
oltp.lua
576.85 per sec
1.62MB/s
559.52 per sec
14.27MB/s

后续还需要做一些相关的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压缩,这样可以保证崩溃前后压缩的数据是一样的。

 

原创文章,转载请注明: 转载自Simple Life

本文链接地址: MySQL5.6 RC innodb_log_compressed_pages 测试 及实现简述

Post Footer automatically generated by wp-posturl plugin for wordpress.


Comments

  • a thought by 鸟菜

    不好意思,真没看懂。这章说的什么。
    以判定在压缩page时,是否在redo中存储压缩页数据。
    redo(重做日志),记录是事务与重做需要的数据,不会有page的数据。
    在压缩page的时候,只会在redo记录这个页面的压缩级别(这个是大师在上面说的)。不会记录page的数据啊。
    没想通,这个参数是如何提高性能的。 8130 rows/s
    2.37MB/s
    最近把该特性在5.5.18上做了实现,从测试的效果来看,大大减少了redo log的写入量(降低到1/3~1/5),这会降低checkpoint的概率,并稍微增加了tps
    数据上,展示没看明白。
    准备数据的时候,
    innodb_log_compressed_pages 0 1

    8333 rows/s 8130 rows/s
    2.37MB/s 6.79MB/s
    tps增加了。这个写入,是指的每秒写入,还是因为准备数据的时候,增加了4.42的数据写入了?

    checkpoint 是每次把脏page写入到磁盘,给redo做一次标记。减少checkpoint ,也不太可能啊。因为主线程为在每秒或十秒,都会把脏page写入磁盘。都会做一次checkpoint。没理解,怎么会减少checkpoint

    大师,是否可以讲解下了。

    Reply

    • a thought by zhaiwx1987

      hi, innodb_log_compressed_pages开启或关闭,带来的影响是是否在压缩时记录全page,当关闭该选项时,可以减少redo的写入量。 日志模块的开销减小,可以带来tps的提升。

      checkpoint有同步checkpoint和异步checkpoint,后台线程(master thread)都是做的异步checkpoint。 当redo推进的非常快时,就会很快达到同步checkpoint点(innodb的redo是循环使用的,因此有个临界点,防止redo覆盖)。 这里表述可能不太清楚,应该说是减少了同步checkpoint的数量

      Reply

      • a thought by 鸟菜

        这下相同了。多谢。

        Reply

Leave a Reply

Your email address will not be published. Name and email are required


Current month ye@r day *