MySQL中怎么實(shí)現(xiàn)主從同步機(jī)制，相信很多沒有經(jīng)驗(yàn)的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個(gè)問題。

為陽明等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計(jì)制作服務(wù)，及陽明網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為成都網(wǎng)站建設(shè)、網(wǎng)站建設(shè)、陽明網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會(huì)得到認(rèn)可，從而選擇與我們長期合作。這樣，我們也可以走得更遠(yuǎn)！

最直觀的表現(xiàn)為：

mysql> show slave status\G;
 // 狀態(tài)一
 Seconds_Behind_Master: NULL
 // 狀態(tài)二
 Seconds_Behind_Master: 0
 // 狀態(tài)三
 Seconds_Behind_Master: 79

連續(xù)查詢，大部分時(shí)間該屬性值=0，偶發(fā)性出現(xiàn)Null或者79等延時(shí)值。導(dǎo)致觀察主從同步延時(shí)的監(jiān)控持續(xù)報(bào)警。

故障原因及解決方案

多臺(tái)備機(jī)的server-id一致，導(dǎo)致主機(jī)無法長時(shí)間同某一臺(tái)備機(jī)連接，進(jìn)而無法正常同步。

修改server-id后，重啟數(shù)據(jù)庫恢復(fù)。

主從同步機(jī)制

MySQL的主從同步，又稱為復(fù)制（replication），是一種內(nèi)置的高可用高性能集群解決方案，主要功能有：

• 數(shù)據(jù)分布：同步不需要很大帶寬，可以實(shí)現(xiàn)多數(shù)據(jù)中心復(fù)制數(shù)據(jù)。

• 讀取的負(fù)載均衡：通過服務(wù)器集群，可以通過DNS輪詢、Linux LVS等GSLB（全局負(fù)載均衡）方式，降低主服務(wù)器的讀壓力。

• 數(shù)據(jù)庫備份：復(fù)制是備份的一部分，但并不能代替?zhèn)浞?。還需要與快照相結(jié)合。

• 高可用性和故障轉(zhuǎn)移：從服務(wù)器可以快速切換為主服務(wù)器，減少故障的停機(jī)時(shí)間和恢復(fù)時(shí)間。

主從同步分為3步：

1. 主服務(wù)器（master）把數(shù)據(jù)更改記錄到二進(jìn)制日志（binlog）中。

2. 從服務(wù)器（slave）把主服務(wù)器的二進(jìn)制日志復(fù)制到自己的中繼日志（relay log）中。

3. 從服務(wù)器重做中繼日志中的日志，把更改應(yīng)用到自己的數(shù)據(jù)庫上，達(dá)到數(shù)據(jù)的一致性。

主從同步是一個(gè)異步實(shí)時(shí)的同步，會(huì)實(shí)時(shí)的傳輸，但存在執(zhí)行上的延時(shí)，如果主服務(wù)器壓力很大，延時(shí)也會(huì)相應(yīng)擴(kuò)大。

通過上面的圖，可以看到一共需要3個(gè)線程：

1. 主服務(wù)器的日志傳送線程：負(fù)責(zé)將二進(jìn)制日志增量傳送到備機(jī)

2. 從服務(wù)器的I/O線程：負(fù)責(zé)讀取主服務(wù)器的二進(jìn)制日志，并保存為中繼日志

3. 從服務(wù)器的SQL線程，負(fù)責(zé)執(zhí)行中繼日志

查看MySQL線程

我們可以使用show full processlist;命令來查看MySQL的狀態(tài)：

主機(jī)的狀態(tài)：

備機(jī)的狀態(tài)：

可以看到，我的集群架構(gòu)為1臺(tái)主機(jī)、4臺(tái)備機(jī)，所以在主機(jī)中有4個(gè)同步線程（已經(jīng)發(fā)送所有的binlog數(shù)據(jù)到備機(jī)，等待binlog日志更新），1個(gè)查看命令線程（show full processlist）。在備機(jī)中有1個(gè)查看命令線程，1個(gè)I/O線程（等待主機(jī)發(fā)送同步數(shù)據(jù)事件），1個(gè)SQL線程（已經(jīng)讀取了所有中繼日志，等待I/O線程來更新它）。

查看同步狀態(tài)

因?yàn)橹鲝耐绞钱惒綄?shí)時(shí)的，也就是會(huì)存在延時(shí)的情況，我們可以通過show slave status;來查看備機(jī)上的同步延時(shí)：

在主從同步中我們需要關(guān)注的一些屬性，已經(jīng)給大家標(biāo)紅了：

• Slave_IO_State: 當(dāng)前I/O線程的狀態(tài)

• Master_Log_File: 當(dāng)前同步的主服務(wù)器的二進(jìn)制文件

• Read_Master_Log_Pos: 當(dāng)前同步的主服務(wù)器的二進(jìn)制文件的偏移量，單位為字節(jié)，如圖中為已經(jīng)同步了12.9M(13630580/1024/1024)的內(nèi)容

• Relay_Master_Log_File: 當(dāng)前中繼日志同步的二進(jìn)制文件

• Slave_IO_Running: 從服務(wù)器中I/O線程的運(yùn)行狀態(tài)，YES為運(yùn)行正常

• Slave_SQL_Running: 從服務(wù)器中SQL線程的運(yùn)行狀態(tài)，YES為運(yùn)行正常

• Exec_Master_Log_Pos: 表示同步完成的主服務(wù)器的二進(jìn)制日志偏移量

• Seconds_Behind_Master: 表示從服務(wù)器數(shù)據(jù)比主服務(wù)器落后的持續(xù)時(shí)長

同樣可以通過show master status;命令來查看主服務(wù)器的運(yùn)行狀態(tài)：

正常運(yùn)行的主從同步狀態(tài)：

Slave_IO_Running: YES
Slave_SQL_Running: YES
Seconds_Behind_Master: 0

問題排查

在理解了主從同步的機(jī)制后，再來看今天遇到的問題，通過查看備機(jī)狀態(tài)，我們觀察在三種狀態(tài)下的幾個(gè)關(guān)鍵屬性值：

mysql> show slave status\G;
#狀態(tài)一：
 Slave_IO_State: Reconnecting after a failed master event read
 Slave_IO_Running: No
 Slave_SQL_Running: Yes
 Seconds_Behind_Master: NULL
#狀態(tài)二：
 Slave_IO_State: Waiting for master to send event
 Slave_IO_Running: Yes
 Slave_SQL_Running: Yes
 Seconds_Behind_Master: 0
#狀態(tài)三：
 Slave_IO_State: Queueing master event to the relay log
 Slave_IO_Running: Yes
 Slave_SQL_Running: Yes
 Seconds_Behind_Master: 636

通過MySQL主從復(fù)制線程狀態(tài)轉(zhuǎn)變，我們可以看到三種狀態(tài)的不同含義：

# 狀態(tài)一
# 線程正嘗試重新連接主服務(wù)器，當(dāng)連接重新建立后，狀態(tài)變?yōu)閃aiting for master to send event。
Reconnecting after a failed master event read
# 狀態(tài)二
# 線程已經(jīng)連接上主服務(wù)器，正等待二進(jìn)制日志事件到達(dá)。如果主服務(wù)器正空閑，會(huì)持續(xù)較長的時(shí)間。如果等待持續(xù)slave_read_timeout秒，則發(fā)生超時(shí)。此時(shí)，線程認(rèn)為連接被中斷并企圖重新連接。
Waiting for master to send event

# 狀態(tài)三
# 線程已經(jīng)讀取一個(gè)事件，正將它復(fù)制到中繼日志供SQL線程來處理。
Queueing master event to the relay log

在這里，我們可以猜測，由于某些原因，從服務(wù)器不斷的和主服務(wù)器進(jìn)行斷開并嘗試重連，重連成功后又再次斷開。

我們再看看主機(jī)的運(yùn)行情況：

發(fā)現(xiàn)問題出在10.144.63.*和10.144.68.*兩臺(tái)機(jī)器上，我們查看其中一臺(tái)的錯(cuò)誤日志：

190214 11:33:20 [Note] Slave: received end packet from server, apparent master shutdown:
190214 11:33:20 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log 'mysql-bin.005682' at postion 13628070

拿到關(guān)鍵字Slave: received end packet from server, apparent master shutdown: Google搜索一下，在文章Confusing MySQL Replication Error Message中可以看到原因?yàn)閮膳_(tái)備機(jī)的server-id重復(fù)。

One day it happen to me, and took me almost an hour to find that out.
Moving foward I always use a base my.cnf to I copy to any other server and the first thing is to increase the server-id.
Could MySQL just use the servername intead of a numeric value?

問題修復(fù)

定位了問題，我們確認(rèn)下是否重復(fù)，發(fā)現(xiàn)兩臺(tái)備機(jī)的該字段確實(shí)相同：

vim my.cnf

#replication
log-bin=mysql-bin
# 這個(gè)隨機(jī)數(shù)字相同導(dǎo)致的
server-id=177230069
sync_binlog=1

看完上述內(nèi)容，你們掌握MySQL中怎么實(shí)現(xiàn)主從同步機(jī)制的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)成都網(wǎng)站設(shè)計(jì)公司行業(yè)資訊頻道，感謝各位的閱讀！

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

文章名稱：MySQL中怎么實(shí)現(xiàn)主從同步機(jī)制-創(chuàng)新互聯(lián)
分享鏈接：http://weahome.cn/article/cojehd.html