線上mysql主從架構(gòu)恢復(fù)異常案例分析

本文主要給大家介紹線上mysql主從架構(gòu)恢復(fù)異常案例分析，文章內(nèi)容都是筆者用心摘選和編輯的，線上mysql主從架構(gòu)恢復(fù)異常案例分析具有一定的針對性，對大家的參考意義還是比較大的，下面跟筆者一起了解下主題內(nèi)容吧。

前提：之前一位同事負(fù)責(zé)的一位客戶，因后期轉(zhuǎn)到devops小組。所以將此用戶交接給我，在后期發(fā)現(xiàn)有一套數(shù)據(jù)庫主從環(huán)境，從庫已經(jīng)無法正常使用。查看slave 狀態(tài)為：

其中:
Master_Log_File：#此處顯示的bin-log已經(jīng)在master上找不見了
Read_Master_Log_Pos：#顯示的行數(shù)也就存在沒有意義了
Slave_IO_Running：NO  #salve io進(jìn)程顯示為no，無法從master同步數(shù)據(jù)
因此判定從庫已經(jīng)無法使用，需要及時修復(fù)。保證主從架構(gòu)正常使用。

以下是恢復(fù)的全部過程：
##########################################################

主要思路：
1、在不鎖表的情況下備份master數(shù)據(jù)庫的所有數(shù)據(jù)文件
2、將slave數(shù)據(jù)庫進(jìn)程停掉。并將備份文件從master傳輸?shù)絪lave端，解壓
3、重新執(zhí)行 change master設(shè)置bin-log文件名稱，和position

##########################################################

一、在數(shù)據(jù)庫的Master端使用percona-xtrabackup進(jìn)行文件級別的數(shù)據(jù)庫備份。

在master數(shù)據(jù)庫執(zhí)行下面命令：（需要根據(jù)實際情況修改）
innobackupex --defaults-file=/etc/my.cnf --user=root --password=51idc --no-lock --use-memory=4G --compress --compress-threads=8 --stream=xbstream --parallel=4 /backup > /backup/$(date +%Y-%m-%d_%H-%M-%S).xbstream

注意：其中
1、/backup這個目錄可以自定義，他代表備份文件存放的位置。
2、/etc/my.cnf這個文件是數(shù)據(jù)庫啟動時讀取的默認(rèn)配置文件，需要根據(jù)實際情況進(jìn)行修改；我這邊使用的是/etc/my.cnf
3、修改數(shù)據(jù)庫連接密碼
4、--no-lock代表不鎖表進(jìn)行備份，保證線上業(yè)務(wù)正常運行的同時進(jìn)行數(shù)據(jù)備份。

這個操作時間依據(jù)數(shù)據(jù)量的大小，我自己備份花費了30min左右（130G數(shù)據(jù)）。備份完成后出現(xiàn)一個文件：
2019-02-27_11-12-21.xbstream

二、在數(shù)據(jù)庫的slave端使用命令進(jìn)行恢復(fù)數(shù)據(jù)，因為在恢復(fù)之前需要保證主從數(shù)據(jù)庫的數(shù)據(jù)一致，但是之前因為從數(shù)據(jù)庫很久都沒有同步master的數(shù)據(jù)了，因此目前主從數(shù)據(jù)量差的較多。

a、需要先停掉數(shù)據(jù)庫
/etc/init.d/mysql stop   #停掉數(shù)據(jù)庫
b、刪除之前的數(shù)據(jù)文件，默認(rèn)在/var/lib/mysql下；刪除mysql目錄下的所有文件，因為接下來我們需要將備份數(shù)據(jù)解壓到此目錄下。
c、在slave數(shù)據(jù)庫的機(jī)器上執(zhí)行兩次解壓操作，將備份文件解壓到本地。

xbstream -x < /backup/2019-02-27_11-12-21.xbstream -C /backup/2019-02-27_11-12-21
innobackupex --decompress --parallel=4  /backup/2019-02-27_11-12-21
d、刪除所有以 .qp結(jié)尾的文件
find  /backup/2019-02-27_11-12-21  -name "*.qp" -delete  
e、創(chuàng)建完備份之后數(shù)據(jù)被沒有馬上可以被還原，需要回滾未提交事務(wù)前滾提交事務(wù)，讓數(shù)據(jù)庫文件保持一致性。
innobackupex使用—apply-log來做預(yù)備備份
--user-memory：指定預(yù)備階段可使用的內(nèi)存，內(nèi)存多則速度快，默認(rèn)為10MB

innobackupex  --apply-log   --use-memory=4G   /backup/2016-03-16_15-25-55

f、再將還原的數(shù)據(jù)文件拷貝到/var/lib/mysql目錄下，其中/var/lib/mysql目錄在/etc/my.cnf文件中指定的datadir

innobackupex  --defaults-file=/etc/my.cnf  --copy-back --use-memory=4G    /backup/2019-02-27_11-12-21
此過程需要的時間較長，我這邊還原大概是2H左右。還原完成后，在/var/lib/mysql目錄下有兩個文件，可以看到salve目前保存的最近的bin-log文件和position

若出現(xiàn)找不到qpress命令的報錯可以安裝repo.percona源后使用  yum -y install qpress 進(jìn)行安裝
repo.percona源安裝命令：
yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm

g、修改/var/lib/mysql的屬主屬組
chown -R mysql.mysql /var/lib/mysql

h、啟動數(shù)據(jù)庫；
/etc/init.d/mysql start

I、重做主從配置
mysql -uroot -p      #進(jìn)入到數(shù)據(jù)庫內(nèi)
change master to  master_host='主xxx.xxx.xxx.xx',master_port=3306,master_user='root',master_password='51idc',master_lo_file='master-bin.xxx',master_log_pos=xxx;

其中：master IP 、master_password根據(jù)實際情況確定。
bin-log日志文件名、master_log_pos的位置需要在這兩個文件中查看。

h、啟動slave
mysql> start slave;

j、查看slave狀態(tài)：
mysql> show slave status\G;

可以看到從數(shù)據(jù)庫slave的Slave_IO_Running: Yes、Slave_SQL_Running: Yes均是yes
并且有了新的bin-log文件和position位置了。后面就可以正常工作，進(jìn)行主從同步了。

看完以上關(guān)于線上mysql主從架構(gòu)恢復(fù)異常案例分析，很多讀者朋友肯定多少有一定的了解，如需獲取更多的行業(yè)知識信息 ，可以持續(xù)關(guān)注我們的行業(yè)資訊欄目的。