MySQL 选型以及使用 mariadb 踩过的几个坑

1,903 阅读6分钟
原文链接: www.jianshu.com

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插件、图数据库插件等等,这些都给我们给业务的服务增加了想象力。