I en MySQL-värdreplikeringskonfiguration används parametern Seconds_Behind_Master (SBM), som visas av kommandot SHOW SLAVE STATUS, vanligtvis som en indikation på den aktuella replikeringsfördröjningen för slaven . I det här blogginlägget undersöker vi hur man förstår och tolkar detta värde i olika situationer.
Möjliga värden för sekunderna bakom Master
Värdet på SBM, som förklaras i MySQL-dokumentationen, beror på MySQL-slavens tillstånd i allmänhet och tillstånden för MySQL-slaven SQL_THREAD och IO_THREAD i synnerhet. Medan IO_THREAD ansluter till mastern och läser uppdateringarna, tillämpar SQL_THREAD dessa uppdateringar på slaven. Låt oss undersöka de möjliga värdena för SBM under olika tillstånd av MySQL-slaven.
När SBM-värdet är noll
- SBM är alltid NULL om din slav är stoppad eller din SQL-tråd stoppas (eller inte körs).
- SBM kommer också att vara NULL om IO-tråden stoppas, förutsatt att SQL-tråden redan har bearbetat alla händelser från reläloggen. Ett exempel på VISA SLAVSTATUS (trimmat för att endast visa värden av intresse) visar detta:
Slav_IO_State:
Master_Host:172.19.0.13
Slave_IO_Kör:Nej
Slave_SQL_Running:Ja
Seconds_Behind_Master:NULL
Master_UUID:23b326b1-a452-11e8-91ca-000d3a065e8e
Slave_SQL_Running_State:Slaven har läst all relälogg; väntar på fler uppdateringar
Retrieved_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:818-389213
Executed_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:1-389213
När SBM-värdet är noll eller positivt
- SBM kommer att återspegla ett giltigt värde (>=0) när SQL-tråden aktivt bearbetar händelser. Detta är sant oavsett IO-trådens tillstånd. Till exempel:
Slav_IO_State:
Master_Host:172.19.0.13
Slave_IO_Kör:Nej
Slave_SQL_Running:Ja
Seconds_Behind_Master:3399
Master_UUID:23b326b1-a452-11e8-91ca-000d3a065e8e
Slave_SQL_Running_State:Väntar på att slavarbetare ska bearbeta sina köer
Retrieved_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:818-389213
Executed_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:1-118774
I exemplet ovan kan vi se att slaven ligger bakom mastern genom att jämföra Retrieved_GTID_Set och Executed_GTID_Set. I sådana fall kommer Seconds_Behind_Master att representera skillnaden mellan tidsstämpeln för den senaste transaktionen som bearbetades av SQL-tråden och tidsstämpeln för samma transaktion när den bearbetades på mastern. Denna transaktionstidstämpel för mastern bevaras genom replikering och därför kommer slaven att kunna beräkna SBM lokalt.
Dessutom, när slaven kommer ikapp alla reläloggar (dvs. exekverat GTID blir 23b326b1-a452-11e8-91ca-000d3a065e8e:1-389213/), hind_Master_Be. vrid till '0' om IO-tråden körs, eller till 'NULL' om IO-tråden inte körs.
#MySQL Tutorial – Förstå sekunderna bakom Master ValueClick To Tweet
Förstå exekveringshastigheten för MySQL-slaven
Förutsatt att SQL-tråden och IO-tråden på slaven är i körtillstånd, är det möjligt att förstå de relativa exekveringshastigheterna för mastern och slaven genom att övervaka SBM-värdet. Ett konsekvent '0'-värde eller ett konstant värde indikerar att slaven körs med samma hastighet som mastern. Å andra sidan indikerar en uppåtgående lutning för Seconds_Behind_Master att slaven presterar långsammare än mastern.
ScaleGrids övervakningskonsol för MySQL på Azure plottar värdena för SBM över tid för slavnoderna.
Noll eller konstant värde för SBM
I exemplet ovan startades slaven cirka 40 timmar efter att mastern hade aktiva skrivningar. När den väl startade började slaven replikera dessa data, och vi ser att SBM:n var ganska platt, vilket indikerar att slaven exekveras i samma hastighet som mastern. Observera också att fallet för SBM till "0" är brant, vilket verkligen betyder att även om den sista transaktionen som slaven körde utfördes cirka 40 timmar innan på mastern, så finns det en "0" fördröjning när vi har kommit ikapp.
Ökande värden på SBM
I grafen nedan kan vi se att SBM ständigt ökar, vilket innebär att slavens exekveringshastighet är lägre jämfört med masterns. Det här är faktiskt ett fall där vi kör 20 trådar som gör kontinuerliga skrivningar på mastern och en enkeltrådad slav kan inte hålla jämna steg med det.
Sistligen är det viktigt att notera att vi i våra diskussioner hittills inte har antagit några nätverksflaskhalsar. I händelse av långsamma nätverk kommer själva slav-IO-tråden att släpa efter mastern, och om SQL-tråden är tillräckligt snabb kommer SBM:n att pendla mellan '0' och ett positivt tal. I sådana fall kommer SBM inte att vara en användbar parameter för att förstå den verkliga eftersläpningen med mastern.
Om du gillade det här blogginlägget, kolla in våra andra populära självstudier för MySQL-databashantering för att lära dig mer om hur du optimerar dina distributioner:
- Beräkna storleken på InnoDB-buffertpoolen för din MySQL-server
- MySQL Tutorial – Konfigurera och hantera SSL på din MySQL-server
- MySQL High Availability Framework Explained – Del I:Introduktion
