I en MySQL-hosting-replikeringsopsætning bruges parameteren Seconds_Behind_Master (SBM), som vist ved SHOW SLAVE STATUS-kommandoen, almindeligvis som en indikation af den aktuelle replikeringsforsinkelse for slaven . I dette blogindlæg undersøger vi, hvordan man forstår og fortolker denne værdi i forskellige situationer.
Mulige værdier af sekunder bag master
Værdien af SBM, som forklaret i MySQL-dokumentationen, afhænger af MySQL-slavens tilstand generelt og tilstandene for MySQL-slaven SQL_THREAD og IO_THREAD i særdeleshed. Mens IO_THREAD forbinder med masteren og læser opdateringerne, anvender SQL_THREAD disse opdateringer på slaven. Lad os undersøge de mulige værdier af SBM under forskellige tilstande af MySQL-slaven.
Når SBM-værdien er nul
- SBM er altid NULL, hvis din slave er stoppet, eller din SQL-tråd er stoppet (eller ikke kører).
- SBM vil også være NULL, hvis IO-tråden er stoppet, forudsat at SQL-tråden allerede har behandlet alle hændelser fra relæloggen. Et eksempeloutput af VIS SLAVESTATUS (trimmet til kun at vise værdier af interesse) viser dette:
Slave_IO_State:
Master_Host:172.19.0.13
Slave_IO_Running:Nej
Slave_SQL_Running:Ja
Seconds_Behind_Master:NULL
Master_UUID:23b326b1-a452-11e8-91ca-000d3a065e8e
Slave_SQL_Running_State:Slave har læst al relælog; venter på flere opdateringer
Retrieved_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:818-389213
Executed_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:1-389213
Når SBM-værdien er nul eller positiv
- SBM vil afspejle en gyldig værdi (>=0) når SQL-tråden aktivt behandler hændelser. Dette er sandt uanset IO-trådstilstanden. For eksempel:
Slave_IO_State:
Master_Host:172.19.0.13
Slave_IO_Running:Nej
Slave_SQL_Running:Ja
Seconds_Behind_Master:3399
Master_UUID:23b326b1-a452-11e8-91ca-000d3a065e8e
Slave_SQL_Running_State:Venter på, at slavearbejdere behandler deres køer
Retrieved_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:818-389213
Executed_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:1-118774
I ovenstående eksempel kan vi se, at slaven er bag masteren ved at sammenligne Retrieved_GTID_Set og Executed_GTID_Set. I sådanne tilfælde vil Seconds_Behind_Master repræsentere forskellen mellem tidsstemplet for den seneste transaktion behandlet af SQL-tråden og tidsstemplet for den samme transaktion, da den blev behandlet på masteren. Dette transaktionstidsstempel for masteren bevares gennem replikering, og derfor vil slaven være i stand til at beregne SBM'en lokalt.
Også, når slaven fuldt ud indhenter alle relælogfilerne (dvs. det udførte GTID bliver 23b326b1-a452-11e8-91ca-000d3a065e8e:1-389213/), hind_Master will drej til '0', hvis IO-tråden kører, eller til 'NULL', hvis IO-tråden ikke kører.
#MySQL Tutorial – Forstå sekunderne bag Master Value Klik for at tweete
Forstå eksekveringshastigheden for MySQL-slaven
Forudsat at SQL-tråden og IO-tråden på slaven er i kørende tilstande, er det muligt at forstå de relative udførelseshastigheder for masteren og slaven ved at overvåge SBM-værdien. En konsistent '0'-værdi eller en konstant værdi indikerer, at slaven kører med samme hastighed som masteren. På den anden side indikerer en opadgående hældning for Seconds_Behind_Master, at slaven udfører langsommere end masteren.
ScaleGrids overvågningskonsol til MySQL på Azure plotter værdierne af SBM over tid for slaveknuderne.
Nul eller konstant værdi af SBM
I ovenstående eksempel blev slaven startet ca. 40 timer efter, at masteren havde aktive skrivninger. Når den først var startet, begyndte slaven at replikere disse data, og vi kan se, at SBM'en var ret flad, hvilket indikerer, at slaven blev udført med samme hastighed som masteren. Bemærk også, at faldet af SBM til "0" er stejlt, hvilket virkelig betyder, at selvom den sidste transaktion, som slaven kørte, blev udført omkring 40 timer før på masteren, er der en "0"-forsinkelse, når vi har indhentet det.
Øgende værdier af SBM
I grafen nedenfor kan vi se, at SBM konstant stiger, hvilket betyder, at slavens eksekveringshastighed er mindre sammenlignet med masterens. Dette er faktisk et tilfælde, hvor vi kører 20 tråde, der laver kontinuerlige skrivninger på masteren, og en enkelt-trådet slave er ikke i stand til at holde trit med det.
Til sidst er det vigtigt at bemærke, at vi i vores diskussioner indtil videre ikke har antaget nogen netværksflaskehalse. I tilfælde af langsomme netværk vil selve slave IO-tråden halte bagefter masteren, og hvis SQL-tråden er hurtig nok, vil SBM'en svinge mellem '0' og et positivt tal. I sådanne tilfælde vil SBM ikke være en nyttig parameter til at forstå den reelle forsinkelse med masteren.
Hvis du kunne lide dette blogindlæg, så tjek vores andre populære MySQL-databasestyringsøvelser for at lære mere om optimering af dine implementeringer:
- Beregning af InnoDB-bufferpoolstørrelse for din MySQL-server
- MySQL Tutorial – Konfiguration og administration af SSL på din MySQL-server
- MySQL High Availability Framework Forklaret – Del I:Introduktion
