March 11, 2014

[MySQL 5.6] Percona Server 5.6.16的主要改进

Percona刚刚放出了其最新的基于MySQL5.6.16的分支,在该版本中,Percona增加了几个比较有趣的特性,这里只列出我比较关心的,其他的自行参考官方Release Note (例如Percona对tokudb的支持应该是很多人关注的) Backup Locks 首先要提的是新特性 Backup Locks ,看起来是用来代替备份时臭名昭著的flush table with read lock 。主要增加了三个新的语法: LOCK TABLES FOR BACKUP //使用一种新的MDL锁来阻塞对非事务表的DML以及对所有表的DDL,但不阻塞SELECT查询 LOCK BINLOG FOR BACKUP //阻止对binlog位点的更新,也就是说对于DML/DDL操作会一直进行直到需要写入binlog的阶段被阻塞 UNLOCK BINLOG  // 解除LOCK BINLOG FOR BACKUP Percona的博客上专门写了篇博客来介绍关于备份加锁的历史发展以及对该特性的介绍,有兴趣的可以看看,另外也提到了Mariadb对备份的改进(将被include到下一个版本的Percona Server中) 另外Facebook很早就写了个补丁来绕过ftwrl,具体做法就是增加了新的语法,能够开启一个read view的同时返回当前与read view一致的binlog位点,但只适用于所有的表都是Innodb引擎; 具体的更改可以参考文档 及代码 LRU manager thread 使用新的独立后台线程来刷buffer pool的LRU链表,将这部分工作负担从page cleaner线程剥离。实际上就是直接转移刷LRU的代码到独立线程了, 实际从之前Percona的版本来看,都是在不断的强化后台线程,让用户线程少参与到刷脏/checkpoint这类耗时操作中 具体阅读Percona blueprint 及代码 page cleaner线程对server acitve的判断 在bug#71988中,描述了一种场景,即使每秒有activity,也会去做furous flush; Percona做的修改是,只有1秒钟内innodb没有任何active,才认为实例处于inactive状态,会去做100% IO Capacticy的刷脏操作(furious flush) 题外话:当前官方版本的Innodb,定义实例是否avtive的逻辑非常简单,做一个简单的DML,都会认为实例处于活跃状态,曾经观察到负载停止,而innodb 刷脏页的数据流量呈现出非常巨大的波动状态,结果发现是监控程序每秒做一次DML导致的(具体可以看我之前report的bug#69174) 修复5.6.16的一个性能退化bug […]