MySQL新版本選型

公司早期主要用mysql5.5這個版本，今年我們把數(shù)據(jù)庫配置中心搭建起來，主要推的是mysql5.6這個版本，性能和功能上都有了一定的提升，mysql5.6也能支持gtid，但是無法在線在gtid模式與普通模式之間切換，同時5.6的同步性能還是無法讓人滿意，只能做到在多個db的情況啟動并行復(fù)制，業(yè)務(wù)上很難有這樣的保證，所以一旦寫操作密集的業(yè)務(wù)，同步慢就會是個嚴(yán)重的問題；

所以，最近一直在考慮升級MySQL，升級MySQL首先面臨的一個問題就是選一個合適的版本，首先我們考慮是的采用mysql5.7，5.7今年已經(jīng)連續(xù)發(fā)了多個正式版本了，目前使用范圍也比較廣，可以考慮在正式環(huán)境使用了。于是我們進(jìn)行了線上對比測試，發(fā)現(xiàn)mysql5.7與我們線上的mysql5.6版本的性能有較大的差距（也許還是有些參數(shù)沒有調(diào)好的原因，5.7確實(shí)要復(fù)雜很多）。

與此同時，最近公司頻繁出現(xiàn)一些日志性存儲，大多數(shù)都是采用innodb引擎，容量非常浪費(fèi)，另一方面由于我們公司的標(biāo)準(zhǔn)mysql服務(wù)器容量是1.3T左右，對于一些大容量需求的業(yè)務(wù)來說，容量上也存在瓶頸，如果要保留長時間的數(shù)據(jù)就難以滿足需求了。所以借此機(jī)會我們打算把這塊一起考慮進(jìn)去，目前Percona和Mariadb都支持Tokudb，Mariadb 10.2還是10.3也準(zhǔn)備支持Myrocks了。

于是決定對比試一下，選擇了Percona 5.7.14、Mariadb 10.1.18與我們線上的MySQL 5.6進(jìn)行了對比測試，經(jīng)過壓測。

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

Mariadb與MySQL5.6測試結(jié)果接近

Percona 5.7.14與官方MySQL5.7的性能結(jié)果差不多，比起MySQL5.6有一定的差距（去掉performance_schema好一點(diǎn)，但是也有差距）。

采用Tokudb引擎測試的結(jié)果與官方聲稱的有差距，使用snappy壓縮的情況下，insert比innodb約慢1/4，update只有innodb的一半左右。Percona性能更差，就不考慮了。

最終選型Mariadb 10.1.18，并且在線上部署了一個業(yè)務(wù)，通過這個業(yè)務(wù)慢慢試用以后，逐步推廣開來。

使用Mariadb踩到的一些坑

在使用Mariadb的過程中，碰到了不少問題，這里主要提一下我碰到的兩個較大的問題，供大家參考：

1、同步性能問題：

我們上的這個業(yè)務(wù)高峰期達(dá)到了9000多寫操作/秒，首先面臨的第一個問題就是同步性能跟不上，slave同步線程數(shù)加到了16個線程，勉強(qiáng)能追上，但是一旦數(shù)據(jù)庫從庫停一會，就有可能面臨永遠(yuǎn)最不上的可能。當(dāng)快絕望的時候，看了一下mariadb的官方文章（https://mariadb.com/kb/en/mariadb/parallel-replication/），Mariadb的并行復(fù)制支持好幾種模式，其中有in-order和out-of-order兩種，不過我們這個業(yè)務(wù)支持in-order，所以沒考慮out-of-order，在in-order模式下，又支持兩種：Conservative 和 Optimistic，缺省情況下Conservative ，這種并行模式會嚴(yán)格保證事物的順序性，估計(jì)和5.7的group commit原理差不多；而Optimistic模式下，復(fù)制的時候會盡量啟動更多的會話，直到發(fā)現(xiàn)沖突時才會去處理沖突。果斷試了一下Optimistic，非常強(qiáng)勁，最高同步速度達(dá)到了14000次/秒。

2、"內(nèi)存泄露"

系統(tǒng)部署結(jié)構(gòu)為：兩個Mariadb做成主主復(fù)制，在前面部署了一個自己開發(fā)的分布式數(shù)據(jù)庫，業(yè)務(wù)方連接到分布式數(shù)據(jù)庫進(jìn)程。系統(tǒng)上線了幾天，發(fā)現(xiàn)主庫會莫名其妙的掛掉，好在有分布式數(shù)據(jù)庫，并且會自動切換，Mariadb主庫掛了，會自動切到另外一個主庫上，業(yè)務(wù)方?jīng)]有感知。查看內(nèi)核日志，發(fā)現(xiàn)是OOM了，內(nèi)核把MySQL殺掉了。

于是開始了各種嘗試，去掉Tokudb引擎配置，換Mariadb 10.1.19 ，都嘗試過，最終都會發(fā)生主庫掛掉的事情。一次偶然的機(jī)會，我把主庫上的slave停掉了，發(fā)現(xiàn)主庫的內(nèi)存突然下降好多，并且內(nèi)存不再增加了，但是一旦把主庫上的slave啟動就會發(fā)現(xiàn)，內(nèi)存又逐漸身高。這種現(xiàn)象很像mysql線程內(nèi)的內(nèi)存分配機(jī)制造成的（基于mem_root的內(nèi)存分配，線程停掉會全部釋放），所以初步懷疑是這個原因造成的。發(fā)現(xiàn)作為雙主中的另外一個Mariadb，就不會出現(xiàn)內(nèi)存上漲的問題。

發(fā)現(xiàn)上面的現(xiàn)象以后，就開始代碼上的調(diào)試，用gdb啟動一個mariadb，另外一個用普通命令啟動，這兩個庫做成雙主：

第一種情況：測試作為從庫的時候，接收到的binlog事件情況

在普通命令啟動的mariadb上插入一行數(shù)據(jù)，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事件的時候，出現(xiàn)了問題。

反復(fù)查看Gtid_list_log_event::do_appy_event函數(shù)中的調(diào)用情況，發(fā)現(xiàn)確實(shí)有些方法會調(diào)用thd->alloc來分配內(nèi)存，但是沒有回收，所以造成內(nèi)存不斷的增大，我考慮了一下，因?yàn)槭侵鲙鞂τ谕�步性能要求也不高，所以在Gtid_list_log_event::do_apply_event函數(shù)的最后加了一行代碼：free_root(thd->mem_root, MYF(MY_KEEP_PREALLOC)); 重新編譯后，跑了一天，內(nèi)存終于穩(wěn)定了。

由于目前發(fā)現(xiàn)只有主庫有該事件，主庫同步處理性能要求不高，所以暫時先這樣用著了。不知道m(xù)ariadb官方版本什么時候會優(yōu)化一下。

總體來看，Mariadb還是比較適合我們公司的，它有最新的功能、特性能夠給我們提供很多解決方案。Tokudb可以解決日志型存儲的問題；連接池可以解決大量連接情況下性能地下的問題；審計(jì)插件提供安全方面的審核；slave并發(fā)模式能夠提供高性能的復(fù)制能力。除了這些常見功能以外，Mariadb還提供了Cassandra插件、圖數(shù)據(jù)庫插件等等，這些都給我們給業(yè)務(wù)的服務(wù)增加了想象力。

【相關(guān)推薦】

1. 免費(fèi)mysql在線視頻教程

2. MySQL最新手冊教程

3. 數(shù)據(jù)庫設(shè)計(jì)那些事

以上就是分享使用Mariadb時碰到的兩個問題的詳細(xì)內(nèi)容，更多請關(guān)注php中文網(wǎng)其它相關(guān)文章！