In een MySQL-hostingreplicatie-setup wordt de parameter Seconds_Behind_Master (SBM), zoals weergegeven door het SHOW SLAVE STATUS-commando, vaak gebruikt als een indicatie van de huidige replicatievertraging van de slave . In deze blogpost onderzoeken we hoe we deze waarde in verschillende situaties kunnen begrijpen en interpreteren.
Mogelijke waarden van seconden achter master
De waarde van SBM, zoals uitgelegd in de MySQL-documentatie, hangt af van de status van de MySQL-slave in het algemeen en de status van de MySQL-slave SQL_THREAD en IO_THREAD in het bijzonder. Terwijl IO_THREAD verbinding maakt met de master en de updates leest, past SQL_THREAD deze updates toe op de slave. Laten we eens kijken naar de mogelijke waarden van SBM tijdens verschillende toestanden van de MySQL-slave.
Als SBM-waarde Null is
- SBM is altijd NULL als uw slave is gestopt, of uw SQL-thread is gestopt (of niet actief is).
- SBM is ook NULL als de IO-thread wordt gestopt, op voorwaarde dat de SQL-thread alle gebeurtenissen uit het relaislogboek al heeft verwerkt. Een voorbeelduitvoer van SHOW SLAVE STATUS (bijgesneden om alleen interessante waarden weer te geven) toont dit aan:
Slave_IO_State:
Master_Host:172.19.0.13
Slave_IO_Running:Nee
Slave_SQL_Running:Ja
Seconds_Behind_Master:NULL
Master_UUID:23b326b1-a452-11e8-91ca-000d3a065e8e
Slave_SQL_Running_State:Slave heeft alle relaislogboeken gelezen; wachten op meer updates
Retrieved_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:818-389213
Executed_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:1-389213
Als SBM-waarde nul of positief is
- SBM geeft een geldige waarde weer (>=0) wanneer de SQL-thread actief gebeurtenissen verwerkt. Dit geldt ongeacht de IO Thread-status. Bijvoorbeeld:
Slave_IO_State:
Master_Host:172.19.0.13
Slave_IO_Running:Nee
Slave_SQL_Running:Ja
Seconds_Behind_Master:3399
Master_UUID:23b326b1-a452-11e8-91ca-000d3a065e8e
Slave_SQL_Running_State:wachten tot slavenarbeiders hun wachtrijen hebben verwerkt
Retrieved_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:818-389213
Executed_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:1-118774
In het bovenstaande voorbeeld kunnen we zien dat de slave achter de master staat door de Retrieved_GTID_Set en de Executed_GTID_Set te vergelijken. In dergelijke gevallen vertegenwoordigt Seconds_Behind_Master het verschil tussen de tijdstempel van de laatste transactie die is verwerkt door de SQL-thread en de tijdstempel van dezelfde transactie toen deze op de master werd verwerkt. Dit transactietijdstempel van de master wordt bewaard door replicatie en daarom kan de slave de SBM lokaal berekenen.
Als de slave alle relaislogboeken volledig heeft ingehaald (d.w.z. uitgevoerde GTID wordt 23b326b1-a452-11e8-91ca-000d3a065e8e:1-389213/), zal Seconds_Behind_Master draai naar '0' als de IO-thread actief is, of naar 'NULL' als IO-thread niet actief is.
#MySQL-zelfstudie – inzicht in de seconden achter Master ValueClick To Tweet
De uitvoeringssnelheid van de MySQL-slave begrijpen
Ervan uitgaande dat de SQL-thread en IO-thread op de slave actief zijn, is het mogelijk om de relatieve uitvoeringssnelheden van de master en de slave te begrijpen door de SBM-waarde te bewaken. Een consistente '0'-waarde of een constante waarde geeft aan dat de slave met dezelfde snelheid werkt als de master. Aan de andere kant geeft een opwaartse helling voor Seconds_Behind_Master aan dat de slave langzamer presteert dan de master.
ScaleGrid's Monitoring Console voor MySQL op Azure plot de waarden van SBM in de loop van de tijd voor de slave-knooppunten.
Nul of constante waarde van SBM
In het bovenstaande voorbeeld werd de slave gestart ongeveer 40 uur nadat de master actieve schrijfbewerkingen had. Eenmaal begonnen, begon de slaaf die gegevens te repliceren, en we zien dat de SBM vrij vlak was, wat aangeeft dat de slaaf met dezelfde snelheid werd uitgevoerd als de meester. Merk ook op dat de daling van SBM naar '0' steil is, wat in feite betekent dat hoewel de laatste transactie die de slave heeft uitgevoerd ongeveer 40 uur eerder op de master is uitgevoerd, er een '0' vertraging is als we eenmaal zijn ingehaald.
Waarden van SBM verhogen
In de onderstaande grafiek kunnen we zien dat SBM constant toeneemt, wat betekent dat de uitvoeringssnelheid van de slave lager is in vergelijking met die van de master. Dit is eigenlijk een geval waarin we 20 threads draaien die continu schrijven op de master en een single-threaded slave kan dit niet bijhouden.
Ten slotte is het belangrijk op te merken dat we in onze discussies tot nu toe geen netwerkknelpunten hebben aangenomen. In het geval van langzame netwerken zal de slave-IO-thread zelf achterblijven op de master, en als de SQL-thread snel genoeg is, schommelt de SBM tussen '0' en een positief getal. In dergelijke gevallen is SBM geen bruikbare parameter om de echte vertraging bij de master te begrijpen.
Als je deze blogpost leuk vond, bekijk dan onze andere populaire MySQL-handleidingen voor databasebeheer voor meer informatie over het optimaliseren van je implementaties:
- InnoDB-bufferpoolgrootte berekenen voor uw MySQL-server
- MySQL-zelfstudie - SSL configureren en beheren op uw MySQL-server
- MySQL High Availability Framework uitgelegd – Deel I:Inleiding
