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的官方文章（https://mariadb.com/kb/en/mariadb/parallel-replication/），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，就不会出现内存上涨的问题。
在原版的基础上做了一下修正评论没有提交正文的问题特价商品的调用连接问题去掉了一个后门补了SQL注入补了一个过滤漏洞浮动价不能删除的问题不能够搜索问题收藏时放入购物车时出错点放入购物车弹出2个窗口修正主题添加问题商家注册页导航连接问题销售排行不能显示更多问题热点商品不能显示更多问题增加了服务器探测 增加了空间使用查看 增加了在线文件编辑增加了后台管理里两处全选功能更新说明：后台的部分功能已经改过前台
发现上面的现象以后，就开始代码上的调试，用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插件、图数据库插件等等，这些都给我们给业务的服务增加了想象力。
【相关推荐】
2. MySQL最新手册教程
3. 数据库设计那些事
