MySQL中怎么實(shí)現(xiàn)主從同步機(jī)制,相信很多沒(méi)有經(jīng)驗(yàn)的人對(duì)此束手無(wú)策,為此本文總結(jié)了問(wèn)題出現(xiàn)的原因和解決方法,通過(guò)這篇文章希望你能解決這個(gè)問(wèn)題。
創(chuàng)新互聯(lián)堅(jiān)持“要么做到,要么別承諾”的工作理念,服務(wù)領(lǐng)域包括:網(wǎng)站建設(shè)、成都做網(wǎng)站、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù),滿足客戶于互聯(lián)網(wǎng)時(shí)代的太白網(wǎng)站設(shè)計(jì)、移動(dòng)媒體設(shè)計(jì)的需求,幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴!
最直觀的表現(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ī)無(wú)法長(zhǎng)時(shí)間同某一臺(tái)備機(jī)連接,進(jìn)而無(wú)法正常同步。
修改server-id后,重啟數(shù)據(jù)庫(kù)恢復(fù)。
主從同步機(jī)制
MySQL的主從同步,又稱為復(fù)制(replication),是一種內(nèi)置的高可用高性能集群解決方案,主要功能有:
數(shù)據(jù)分布:同步不需要很大帶寬,可以實(shí)現(xiàn)多數(shù)據(jù)中心復(fù)制數(shù)據(jù)。
讀取的負(fù)載均衡:通過(guò)服務(wù)器集群,可以通過(guò)DNS輪詢、Linux LVS等GSLB(全局負(fù)載均衡)方式,降低主服務(wù)器的讀壓力。
數(shù)據(jù)庫(kù)備份:復(fù)制是備份的一部分,但并不能代替?zhèn)浞?。還需要與快照相結(jié)合。
高可用性和故障轉(zhuǎn)移:從服務(wù)器可以快速切換為主服務(wù)器,減少故障的停機(jī)時(shí)間和恢復(fù)時(shí)間。
主從同步分為3步:
主服務(wù)器(master)把數(shù)據(jù)更改記錄到二進(jìn)制日志(binlog)中。
從服務(wù)器(slave)把主服務(wù)器的二進(jìn)制日志復(fù)制到自己的中繼日志(relay log)中。
從服務(wù)器重做中繼日志中的日志,把更改應(yīng)用到自己的數(shù)據(jù)庫(kù)上,達(dá)到數(shù)據(jù)的一致性。
主從同步是一個(gè)異步實(shí)時(shí)的同步,會(huì)實(shí)時(shí)的傳輸,但存在執(zhí)行上的延時(shí),如果主服務(wù)器壓力很大,延時(shí)也會(huì)相應(yīng)擴(kuò)大。
通過(guò)上面的圖,可以看到一共需要3個(gè)線程:
主服務(wù)器的日志傳送線程:負(fù)責(zé)將二進(jìn)制日志增量傳送到備機(jī)
從服務(wù)器的I/O線程:負(fù)責(zé)讀取主服務(wù)器的二進(jìn)制日志,并保存為中繼日志
從服務(wù)器的SQL線程,負(fù)責(zé)執(zhí)行中繼日志
查看MySQL線程
我們可以使用show full processlist;
命令來(lái)查看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線程來(lái)更新它)。
查看同步狀態(tài)
因?yàn)橹鲝耐绞钱惒綄?shí)時(shí)的,也就是會(huì)存在延時(shí)的情況,我們可以通過(guò)show slave status;來(lái)查看備機(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í)長(zhǎng)
同樣可以通過(guò)show master status;命令來(lái)查看主服務(wù)器的運(yùn)行狀態(tài):
正常運(yùn)行的主從同步狀態(tài):
Slave_IO_Running: YES
Slave_SQL_Running: YES
Seconds_Behind_Master: 0
問(wèn)題排查
在理解了主從同步的機(jī)制后,再來(lái)看今天遇到的問(wèn)題,通過(guò)查看備機(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
通過(guò)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ù)較長(zhǎng)的時(shí)間。如果等待持續(xù)slave_read_timeout秒,則發(fā)生超時(shí)。此時(shí),線程認(rèn)為連接被中斷并企圖重新連接。 Waiting for master to send event # 狀態(tài)三 # 線程已經(jīng)讀取一個(gè)事件,正將它復(fù)制到中繼日志供SQL線程來(lái)處理。 Queueing master event to the relay log
在這里,我們可以猜測(cè),由于某些原因,從服務(wù)器不斷的和主服務(wù)器進(jìn)行斷開(kāi)并嘗試重連,重連成功后又再次斷開(kāi)。
我們?cè)倏纯粗鳈C(jī)的運(yùn)行情況:
發(fā)現(xiàn)問(wè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?
問(wèn)題修復(fù)
定位了問(wèn)題,我們確認(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)行業(yè)資訊頻道,感謝各位的閱讀!
新聞名稱:MySQL中怎么實(shí)現(xiàn)主從同步機(jī)制
分享地址:http://bm7419.com/article8/ipdoop.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供響應(yīng)式網(wǎng)站、ChatGPT、網(wǎng)站營(yíng)銷、品牌網(wǎng)站設(shè)計(jì)、標(biāo)簽優(yōu)化、定制開(kāi)發(fā)
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來(lái)源: 創(chuàng)新互聯(lián)