MySQL新版本选型

公司早期主要用mysql5.5这个版本，今年我们把数据库配置中心搭建起来，主要推的是mysql5.6这个版本，性能和功能上都有了一定的提升，mysql5.6也能支持gtid，但是无法在线在gtid模式与普通模式之间切换，同时5.6的同步性能还是无法让人满意，只能做到在多个db的情况启动并行复制，业务上很难有这样的保证，所以一旦写操作密集的业务，同步慢就会是个严重的问题；

所以，最近一直在考虑升级MySQL，升级MySQL首先面临的一个问题就是选一个合适的版本，首先我们考虑是的采用mysql5.7，5.7今年已经连续发了多个正式版本了，目前使用范围也比较广，可以考虑在正式环境使用了。于是我们进行了线上对比测试，发现mysql5.7与我们线上的mysql5.6版本的性能有较大的差距（也许还是有些参数没有调好的原因，5.7确实要复杂很多）。

与此同时，最近公司频繁出现一些日志性存储，大多数都是采用innodb引擎，容量非常浪费，另一方面由于我们公司的标准mysql服务器容量是1.3T左右，对于一些大容量需求的业务来说，容量上也存在瓶颈，如果要保留长时间的数据就难以满足需求了。所以借此机会我们打算把这块一起考虑进去，目前Percona和Mariadb都支持Tokudb，Mariadb 10.2还是10.3也准备支持Myrocks了。

于是决定对比试一下，选择了Percona 5.7.14、Mariadb 10.1.18与我们线上的MySQL 5.6进行了对比测试，经过压测。

首先是都使用Innodb引擎的情况：

Mariadb与MySQL5.6测试结果接近

Percona 5.7.14与官方MySQL5.7的性能结果差不多，比起MySQL5.6有一定的差距（去掉performance_schema好一点，但是也有差距）。

采用Tokudb引擎测试的结果与官方声称的有差距，使用snappy压缩的情况下，insert比innodb约慢1/4，update只有innodb的一半左右。Percona性能更差，就不考虑了。

最终选型Mariadb 10.1.18，并且在线上部署了一个业务，通过这个业务慢慢试用以后，逐步推广开来。

使用Mariadb踩到的一些坑

在使用Mariadb的过程中，碰到了不少问题，这里主要提一下我碰到的两个较大的问题，供大家参考：

1、同步性能问题：

我们上的这个业务高峰期达到了9000多写操作/秒，首先面临的第一个问题就是同步性能跟不上，slave同步线程数加到了16个线程，勉强能追上，但是一旦数据库从库停一会，就有可能面临永远最不上的可能。当快绝望的时候，看了一下mariadb的官方文章（mariadb.com/kb/en/maria…），Mariadb的并行复制支持好几种模式，其中有in-order和out-of-order两种，不过我们这个业务支持in-order，所以没考虑out-of-order，在in-order模式下，又支持两种：Conservative 和 Optimistic，缺省情况下Conservative ，这种并行模式会严格保证事物的顺序性，估计和5.7的group commit原理差不多；而Optimistic模式下，复制的时候会尽量启动更多的会话，直到发现冲突时才会去处理冲突。果断试了一下Optimistic，非常强劲，最高同步速度达到了14000次/秒。

2、”内存泄露”

系统部署结构为：两个Mariadb做成主主复制，在前面部署了一个自己开发的分布式数据库，业务方连接到分布式数据库进程。系统上线了几天，发现主库会莫名其妙的挂掉，好在有分布式数据库，并且会自动切换，Mariadb主库挂了，会自动切到另外一个主库上，业务方没有感知。查看内核日志，发现是OOM了，内核把MySQL杀掉了。

于是开始了各种尝试，去掉Tokudb引擎配置，换Mariadb 10.1.19 ，都尝试过，最终都会发生主库挂掉的事情。一次偶然的机会，我把主库上的slave停掉了，发现主库的内存突然下降好多，并且内存不再增加了，但是一旦把主库上的slave启动就会发现，内存又逐渐身高。这种现象很像mysql线程内的内存分配机制造成的（基于mem_root的内存分配，线程停掉会全部释放），所以初步怀疑是这个原因造成的。发现作为双主中的另外一个Mariadb，就不会出现内存上涨的问题。

发现上面的现象以后，就开始代码上的调试，用gdb启动一个mariadb，另外一个用普通命令启动，这两个库做成双主：

第一种情况：测试作为从库的时候，接收到的binlog事件情况

在普通命令启动的mariadb上插入一行数据，gdb查看接收到的事件的顺序如下：

### i ) Gtid_log_event

### ii) Table_map_log_event

### iii) Write_rows_log_event

### iv) Xid_log_event

第二种情况：测试作为主库的时候，接收到的binlog事件

在gdb启动的mariadb上插入一行记录，然后gdb观察接收到的事件为：

### 1）Rotate_log_event

### 2）Gtid_list_log_event

### 3）Rotate_log_event

Rotate_log_event事件是虚拟出来的，用于让主库跟上从库的同步位置，这基本上是一个空事件，没有做任何处理，所以初步怀疑是在处理Gtid_list_log_event事件的时候，出现了问题。

反复查看Gtid_list_log_event::do_appy_event函数中的调用情况，发现确实有些方法会调用thd->alloc来分配内存，但是没有回收，所以造成内存不断的增大，我考虑了一下，因为是主库对于同步性能要求也不高，所以在Gtid_list_log_event::do_apply_event函数的最后加了一行代码：free_root(thd->mem_root, MYF(MY_KEEP_PREALLOC));  重新编译后，跑了一天，内存终于稳定了。

由于目前发现只有主库有该事件，主库同步处理性能要求不高，所以暂时先这样用着了。不知道mariadb官方版本什么时候会优化一下。

总体来看，Mariadb还是比较适合我们公司的，它有最新的功能、特性能够给我们提供很多解决方案。Tokudb可以解决日志型存储的问题；连接池可以解决大量连接情况下性能地下的问题；审计插件提供安全方面的审核；slave并发模式能够提供高性能的复制能力。除了这些常见功能以外，Mariadb还提供了Cassandra插件、图数据库插件等等，这些都给我们给业务的服务增加了想象力。