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

成都創(chuàng)新互聯(lián)公司專業(yè)為企業(yè)提供東鄉(xiāng)族網(wǎng)站建設(shè)、東鄉(xiāng)族做網(wǎng)站、東鄉(xiāng)族網(wǎng)站設(shè)計、東鄉(xiāng)族網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計與制作、東鄉(xiāng)族企業(yè)網(wǎng)站模板建站服務(wù)，十余年東鄉(xiāng)族做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡(luò)服務(wù)。

環(huán)境介紹：

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

磁盤類型：SSD

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

軟件版本：5.5.50-MariaDB-wsrep

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

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

MariaDB Galera Cluster主要功能

• 同步復(fù)制

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

• 自動的節(jié)點成員控制，失效節(jié)點自動被清除

• 新節(jié)點加入數(shù)據(jù)自動復(fù)制

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

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

優(yōu)勢:

• 因為是多主，所以不存在Slavelag(延遲)

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

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

• 更小的客戶端延遲

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

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

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

踩過的坑：

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

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

2、mysql獨立表空間和共享表空間

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

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

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

innodb_file_per_table=1  為使用獨占表空間
innodb_file_per_table=0   為使用共享表空間

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

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

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

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

轉(zhuǎn)換方案：

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

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

兩者的區(qū)別

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

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

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

有經(jīng)驗的運維或者DBA肯定不會用mysqldump備份大量的數(shù)據(jù)因為很慢，但是我們由于經(jīng)驗不足在此又踩了一個坑。用腳本和定時任務(wù)的方式實現(xiàn)數(shù)據(jù)備份，每周6晚上2點備份，前期數(shù)據(jù)量比較小整個業(yè)務(wù)系統(tǒng)正常，后面當(dāng)數(shù)據(jù)突破100多G后，就出現(xiàn)一個比較奇怪的事情，每周六早上應(yīng)用系統(tǒng)總是異常，研發(fā)人員都很郁悶，感覺跟見鬼一樣，經(jīng)過多次出現(xiàn)該問題后就考慮數(shù)據(jù)備份，研究任務(wù)執(zhí)行情況，發(fā)現(xiàn)確實是數(shù)據(jù)備份問題，后面就采取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)換獨立表空間更改數(shù)據(jù)庫配置報錯

配置文件：

[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 #獨立表空間
#innodb_flush_log_at_trx_commit=2
#innodb_log_file_size=1G   #（日志文件）
innodb_buffer_pool_size=6G

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

網(wǎng)站標(biāo)題：MariaDBGaleraCluster應(yīng)用實踐
網(wǎng)站URL：http://www.chinadenli.net/article38/gisesp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供動態(tài)網(wǎng)站、軟件開發(fā)、做網(wǎng)站、網(wǎng)站制作、外貿(mào)網(wǎng)站建設(shè)、用戶體驗

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)