MariaDB Galera Cluster應(yīng)用實(shí)踐

數(shù)據(jù)是互聯(lián)網(wǎng)公司的核心資產(chǎn)，所以好多公司在架構(gòu)設(shè)計(jì)上不僅要保證業(yè)務(wù)系統(tǒng)的高可用，同時(shí)還要考慮數(shù)據(jù)存儲(chǔ)的高可用以及安全性。在職公司是一家創(chuàng)業(yè)型公司，之前的應(yīng)用系統(tǒng)是由.Net 和SQLserver組合的架構(gòu)，由于存在業(yè)務(wù)量的增長(zhǎng)，技術(shù)部門采用Java重構(gòu)整個(gè)應(yīng)用系統(tǒng)。數(shù)據(jù)庫(kù)選擇開源數(shù)據(jù)庫(kù)MYSQL，從剛開始都現(xiàn)在踩了相當(dāng)多的坑，在此給大家分享一下。

環(huán)境介紹：

服務(wù)器：阿里云主機(jī)

磁盤類型：SSD

操作系統(tǒng)：CentOS6.5 64位

軟件版本：5.5.50-MariaDB-wsrep

1、數(shù)據(jù)庫(kù)高可用方案選型

目前針對(duì)mysql的高可用方案還是比較多，例如主從、MMM或者M(jìn)HA等 ，我們初期考慮使用Keepalived+Mysql（雙主熱備）方案，但是由于阿里云不能很好的支持虛擬IP，所以想著使用其他方案，最好有集群解決方案，最后選用MariaDBGalera Cluster。3個(gè)節(jié)點(diǎn)組成一個(gè)集群，前端使用阿里云SLB實(shí)現(xiàn)負(fù)載均衡，減輕數(shù)據(jù)庫(kù)壓力。

MariaDB Galera Cluster主要功能

• 同步復(fù)制

• 真正的multi-master，即所有節(jié)點(diǎn)可以同時(shí)讀寫數(shù)據(jù)庫(kù)

• 自動(dòng)的節(jié)點(diǎn)成員控制，失效節(jié)點(diǎn)自動(dòng)被清除

• 新節(jié)點(diǎn)加入數(shù)據(jù)自動(dòng)復(fù)制

• 真正的并行復(fù)制，行級(jí)

• 用戶可以直接連接集群，使用感受上與MySQL完全一致

優(yōu)勢(shì):

• 因?yàn)槭嵌嘀鳎圆淮嬖赟lavelag(延遲)

• 不存在丟失事務(wù)的情況

• 同時(shí)具有讀和寫的擴(kuò)展能力

• 更小的客戶端延遲

• 節(jié)點(diǎn)間數(shù)據(jù)是同步的,而Master/Slave模式是異步的,不同slave上的binlog可能是不同的

線上環(huán)境數(shù)據(jù)庫(kù)架構(gòu)圖

1、cluster1與cluster2由SLB調(diào)度，實(shí)現(xiàn)數(shù)據(jù)庫(kù)負(fù)載均衡，應(yīng)用程序可以連接cluster1和cluster2寫入和讀取。Slave3主要實(shí)現(xiàn)數(shù)據(jù)校驗(yàn)和備份。

踩過(guò)的坑：

1、數(shù)據(jù)容量規(guī)劃嚴(yán)重不合理

   由于是創(chuàng)業(yè)公司，研發(fā)人員和運(yùn)維人員經(jīng)驗(yàn)不足，在整個(gè)系統(tǒng)設(shè)計(jì)服務(wù)器采購(gòu)時(shí)磁盤容量規(guī)劃不合理，數(shù)據(jù)增長(zhǎng)迅速，容量不足，最后采取添加硬盤，由于服務(wù)器是使用的阿里云主機(jī)，所以想著磁盤擴(kuò)容比較簡(jiǎn)單，從阿里云控制臺(tái)購(gòu)買磁盤容量后，重啟主機(jī)（遠(yuǎn)程連接reboot重啟），用fdisk等命令檢查磁盤，發(fā)現(xiàn)擴(kuò)容的部分沒(méi)有生效，折騰好久，最后給阿里云售后打電話解決，更改硬件配置需要在阿里云控制臺(tái)重啟。

2、mysql獨(dú)立表空間和共享表空間

這個(gè)坑也是在上面容量使用上發(fā)現(xiàn)的，因?yàn)椴糠?/span>mysql默認(rèn)使用獨(dú)立表空間，而5.5.50-MariaDB-wsrep是默認(rèn)使用共享表空間，由于前期經(jīng)驗(yàn)不足，沒(méi)有更改這些，每天業(yè)務(wù)量比較大，所以數(shù)據(jù)量增長(zhǎng)比較快，有一天發(fā)現(xiàn)mysql目錄下. Ibdata文件已經(jīng)是80多G，查找相關(guān)資料是獨(dú)立表空間以及共享表空間問(wèn)題，里面包含redo log以及每個(gè)表的數(shù)據(jù)和索引等。由于我們的數(shù)據(jù)存在時(shí)效性，所以超過(guò)一個(gè)月的就轉(zhuǎn)移到歷史庫(kù)，然后將主庫(kù)相關(guān)表刪除，而共享表空間對(duì)這種大量刪除的支持不是很好，所以我們將整個(gè)數(shù)據(jù)庫(kù)的表空間進(jìn)行轉(zhuǎn)換。下面簡(jiǎn)單介紹一下獨(dú)立表空間和共享表空間，

共享表空間: 某一個(gè)數(shù)據(jù)庫(kù)的所有的表數(shù)據(jù)，索引文件全部放在一個(gè)文件中，默認(rèn)這個(gè)共享表空間的文件路徑在data目錄下。默認(rèn)的文件名為:ibdata1 初始化為10M。
獨(dú)立表空間: 每一個(gè)表都將會(huì)生成以獨(dú)立的文件方式來(lái)進(jìn)行存儲(chǔ)，每一個(gè)表都有一個(gè).frm表描述文件，還有一個(gè).ibd文件。其中這個(gè)文件包括了單獨(dú)一個(gè)表的數(shù)據(jù)內(nèi)容以及索引內(nèi)容，默認(rèn)情況下它的存儲(chǔ)位置也是在表的位置之中。
兩者之間的優(yōu)缺點(diǎn)
共享表空間：
優(yōu)點(diǎn)：
可以放表空間分成多個(gè)文件存放到各個(gè)磁盤上（表空間文件大小不受表大小的限制，如一個(gè)表可以分布在不同步的文件上）。數(shù)據(jù)和文件放在一起方便管理。
缺點(diǎn)：
 所有的數(shù)據(jù)和索引存放到一個(gè)文件中以為著將有一個(gè)很常大的文件，雖然可以把一個(gè)大文件分成多個(gè)小文件，但是多個(gè)表及索引在表空間中混合存儲(chǔ)，這樣對(duì)于一個(gè)表做了大量刪除操作后表空間中將會(huì)有大量的空隙，特別是對(duì)于統(tǒng)計(jì)分析，日值系統(tǒng)這類應(yīng)用最不適合用共享表空間。

獨(dú)立表空間：在配置文件（my.cnf）中設(shè)置：innodb_file_per_table

innodb_file_per_table=1  為使用獨(dú)占表空間
innodb_file_per_table=0   為使用共享表空間

獨(dú)立表空間優(yōu)點(diǎn)：
1．每個(gè)表都有自已獨(dú)立的表空間。
2．每個(gè)表的數(shù)據(jù)和索引都會(huì)存在自已的表空間中。
3．可以實(shí)現(xiàn)單表在不同的數(shù)據(jù)庫(kù)中移動(dòng)。
4．空間可以回收（除drop table操作處，表空不能自已回收）
a) Drop table操作自動(dòng)回收表空間，如果對(duì)于統(tǒng)計(jì)分析或是日值表，刪除大量數(shù)據(jù)后可以通過(guò):alter table TableNameengine=innodb;回縮不用的空間。
b) 對(duì)于使innodb-plugin的Innodb使用turncate table也會(huì)使空間收縮。
c) 對(duì)于使用獨(dú)立表空間的表，不管怎么刪除，表空間的碎片不會(huì)太嚴(yán)重的影響性能，而且還有機(jī)會(huì)處理。
缺點(diǎn)：
單表增加過(guò)大，如超過(guò)100個(gè)G。

3、  共享表空間向獨(dú)立表空間的轉(zhuǎn)換

由于我們的數(shù)據(jù)有時(shí)效性，所以需要數(shù)據(jù)轉(zhuǎn)移和對(duì)原來(lái)庫(kù)的表刪除，需要將

默認(rèn)的共享表空間轉(zhuǎn)換成獨(dú)立表空間。

轉(zhuǎn)換方案：

1、將數(shù)據(jù)mysqldump邏輯備份，更改配置文件，重啟數(shù)據(jù)庫(kù)，將之前的數(shù)據(jù)庫(kù)drop掉，導(dǎo)入新的數(shù)據(jù)。

2、  直接更改配置文件重啟數(shù)據(jù)庫(kù)。

兩者的區(qū)別

方案1是比較徹底的做法，但是數(shù)據(jù)量比較大是整個(gè)過(guò)程就會(huì)很慢，因?yàn)?/span>mysqldump的邏輯備份是備份成SQL整個(gè)過(guò)程比較費(fèi)時(shí)間。而方案2 是比較折中的解決方案，這樣做對(duì)已經(jīng)創(chuàng)建的數(shù)據(jù)表結(jié)構(gòu)不會(huì)有影響，后期創(chuàng)建的表結(jié)構(gòu)才會(huì)使用獨(dú)立表空間。

         對(duì)我們來(lái)說(shuō)方案1更徹底，數(shù)據(jù)量有200多G，由于我們的多數(shù)記錄表是按月分表，部分?jǐn)?shù)據(jù)可以成為冷數(shù)據(jù)（一般情況下不會(huì)更改）。所以我們將這些冷數(shù)據(jù)先備份出來(lái)，導(dǎo)入到其他庫(kù)檢驗(yàn)完整性，然后將部分業(yè)務(wù)停掉處理那些業(yè)務(wù)邏輯等數(shù)據(jù)。

4、  mysqldump數(shù)據(jù)分庫(kù)備份

有經(jīng)驗(yàn)的運(yùn)維或者DBA肯定不會(huì)用mysqldump備份大量的數(shù)據(jù)因?yàn)楹苈?，但是我們由于?jīng)驗(yàn)不足在此又踩了一個(gè)坑。用腳本和定時(shí)任務(wù)的方式實(shí)現(xiàn)數(shù)據(jù)備份，每周6晚上2點(diǎn)備份，前期數(shù)據(jù)量比較小整個(gè)業(yè)務(wù)系統(tǒng)正常，后面當(dāng)數(shù)據(jù)突破100多G后，就出現(xiàn)一個(gè)比較奇怪的事情，每周六早上應(yīng)用系統(tǒng)總是異常，研發(fā)人員都很郁悶，感覺(jué)跟見(jiàn)鬼一樣，經(jīng)過(guò)多次出現(xiàn)該問(wèn)題后就考慮數(shù)據(jù)備份，研究任務(wù)執(zhí)行情況，發(fā)現(xiàn)確實(shí)是數(shù)據(jù)備份問(wèn)題，后面就采取xtrabackup備份。

腳本：

#/bin/bash
MYUSER=mysqlback
MYPASS=databack***
#SOCKET=/data/3306/mysql.sock
MYLOGIN="mysql -u$MYUSER -p$MYPASS "
MYDUMP="mysqldump -u$MYUSER -p$MYPASS  -B"
DATABASE="$($MYLOGIN -e "show databases;"|egrep -vi"Data|_schema|mysql")"
for dbname in $DATABASE
  do
   MYDIR=/data/backup/$dbname
   [ ! -d $MYDIR ] &&mkdir -p $MYDIR
 $MYDUMP $dbname|gzip>$MYDIR/${dbname}_$(date +%F).sql.gz
done

5、共享表空間轉(zhuǎn)換獨(dú)立表空間更改數(shù)據(jù)庫(kù)配置報(bào)錯(cuò)

配置文件：

[server]

# this is only for the mysqld standalone daemon
[mysqld]
skip-name-resolve
character-set-server=utf8
datadir=/data/mysql
wait_timeout=1800
interactive_timeout = 288000
max_allowed_packet = 1000M
#max_connections=3000
max_connections=3000
character-set-server=utf8
#innodb_buffer_pool_size = 1000M
innodb_additional_mem_pool_size = 200M
innodb_flush_log_at_trx_commit=2
innodb_autoextend_increment=800M
#innodb_log_buffer_size = 200M
innodb_log_file_size = 100M
key_buffer_size=800M
read_buffer_size=600M
thread_cache_size=64
innodb_file_per_table=1 #獨(dú)立表空間
#innodb_flush_log_at_trx_commit=2
#innodb_log_file_size=1G   #（日志文件）
innodb_buffer_pool_size=6G

為了適當(dāng)?shù)膬?yōu)化數(shù)據(jù)庫(kù)性能，所以將參數(shù)做了適當(dāng)?shù)恼{(diào)整，這時(shí)比較坑的問(wèn)題就出現(xiàn)了，數(shù)據(jù)庫(kù)集群只能啟動(dòng)其中的一臺(tái)，另外的兩臺(tái)都是報(bào)錯(cuò)，這時(shí)肯定是查看日志解決問(wèn)題，看下面日志是配置文件參數(shù)設(shè)置問(wèn)題導(dǎo)致，將更改配置文件逐個(gè)檢查，最后發(fā)現(xiàn)是有3個(gè)innodb_buffer_pool_size參數(shù)不一致（3臺(tái)服務(wù)器集群 基本配置差不多，區(qū)別就是一臺(tái)上面還有其他應(yīng)用程序在運(yùn)行，所以就將其設(shè)置的小一點(diǎn)，導(dǎo)致整個(gè)系統(tǒng)啟動(dòng)異常）

部分日志：
InnoDB: Error: log file ./ib_logfile0 is of different size 0 104857600 bytes
InnoDB: than specified in the .cnf file 0 1073741824 bytes!
InnoDB: Possible causes for this error:
 (a) Incorrect log file is used or log file size is changed
 (b) In case default size is used this log file is from 10.0
 (c) Log file is corrupted or there was not enough disk space
 In case (b) you need to set innodb_log_file_size = 48M
170412 23:53:26 [ERROR] Plugin 'InnoDB' init function returned error.
170412 23:53:26 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
170412 23:53:26 [Note] Plugin 'FEEDBACK' is disabled.
170412 23:53:26 [ERROR] Unknown/unsupported storage engine: innodb
170412 23:53:26 [ERROR] Aborting

170412 23:53:28 [Note] WSREP: Closing send monitor...
170412 23:53:28 [Note] WSREP: Closed send monitor.
170412 23:53:28 [Note] WSREP: gcomm: terminating thread
170412 23:53:28 [Note] WSREP: gcomm: joining thread
170412 23:53:28 [Note] WSREP: gcomm: closing backend
170412 23:53:29 [Note] WSREP: view(view_id(NON_PRIM,1d5436dc,2) memb {
        1d5436dc,0
} joined {
} left {
} partitioned {
        effca7a8,0