MySQL-replicatie is gestopt of loopt achter
Replicatie die stilstaat, is meestal geen ramp maar wel urgent: je back-up-pad of je leesnode is weg en het gat wordt elk uur groter. In de meeste gevallen is het te repareren zonder de hele slave opnieuw op te bouwen.
Loop je hier nu tegenaan?
Bel en leg het voor. Vaak is in tien minuten duidelijk waar het aan ligt. Bellen mag direct. Mail beantwoord ik meestal dezelfde werkdag.
Herken je dit?
- Replicatie is gestopt met een foutmelding en start niet meer.
- Seconds_Behind_Master loopt op en komt niet meer bij.
- Er staat een duplicate key- of een not found-fout in de replicatie.
- Na een herstart van de master is de positie kwijt.
- De slave is in productie en je durft geen rebuild te doen.
Waar het meestal aan ligt
In verreweg de meeste gevallen is het één van deze. Loop ze in deze volgorde na.
Duplicate key of rij die niet bestaat
Data die op de slave direct is gewijzigd, of een eerdere inconsistentie. De replicatie stopt dan bij één statement. Overslaan kan, maar alleen als je weet wat je overslaat.
Verkeerde binlog-positie
Na een herstart of een handmatige ingreep wijst de slave naar een positie die niet meer bestaat, bijvoorbeeld omdat de binlogs op de master zijn opgeruimd. Met GTID's speelt dit veel minder.
Binlogs op de master verlopen
Staat binlog_expire_logs_seconds korter dan de tijd dat de slave stil stond, dan zijn de benodigde logs weg en is bijwerken onmogelijk. Dan resteert een nieuwe basis.
Achterlopen door single-threaded toepassing
Eén trage query of een grote transactie houdt de hele replicatiestroom op. Met parallelle workers en row-based logging is daar veel aan te doen.
Volle schijf of relay logs die volstromen
Een slave die niet bijkomt, stapelt relay logs op tot de schijf vol is. Dan stopt alles, inclusief de dienst zelf.
Verschillen in versie of configuratie
Een master en slave met verschillende versies, sql_mode of tekensets geven statements die op de slave anders of niet uitvoeren. Vooral na een halve upgrade.
Wat ik als eerste check
Doe deze stappen zelf, of bel en dan lopen we ze samen door.
- 1
Lees de volledige status
SHOW REPLICA STATUS\G(ofSHOW SLAVE STATUS\G) en leesLast_Errorvolledig. Daar staat het exacte statement en de reden; dat is de basis van elke verdere stap. - 2
Kijk of de binlogs nog bestaan
Op de master:
SHOW BINARY LOGS. Staat het bestand waar de slave op wacht er niet meer, dan is bijwerken niet mogelijk en moet je een nieuwe basis maken. - 3
Sla nooit blind een fout over
sql_slave_skip_counteris verleidelijk, maar je slaat dan mogelijk een wijziging over die je nodig hebt. Kijk eerst welk statement het is en of de data aan beide kanten verschilt. - 4
Vergelijk de data voordat je conclusies trekt
Met
pt-table-checksum(of een gerichte vergelijking van de betrokken tabel) weet je of de inconsistentie beperkt is tot één rij of breder zit. Dat bepaalt of repareren zin heeft. - 5
Controleer schijfruimte en relay logs
df -hen de grootte van de relay logs. Een volle schijf is vaak het gevolg van stilstand, en geeft een tweede storing bovenop de eerste. - 6
Overweeg GTID's voor de toekomst
Met GTID-gebaseerde replicatie zijn posities niet meer handmatig bij te houden en is failover eenvoudiger. Overstappen is een gepland klusje en voorkomt een hele categorie problemen.
Eerst begrijpen, dan ingrijpen
Replicatieproblemen zijn een van de weinige gebieden waar haastig handelen echt duur is. sql_slave_skip_counter in een lus uitvoeren tot de replicatie weer loopt, geeft een slave die draait en stilletjes niet meer met de master overeenkomt. Als je daar later een back-up van terugzet, ontdek je het pas wanneer het te laat is.
De nette route is: lezen wat de fout is, vaststellen of de data verschilt, en dan gericht repareren. Dat kost vaak minder tijd dan de snelle weg, want je hoeft het maar één keer te doen.
Meekijken bij een stilstaande replicatie
Stuur me de volledige SHOW REPLICA STATUS en ik zeg je of dit te repareren is of dat je een nieuwe basis nodig hebt — en of er haast bij is vanwege verlopende binlogs.
Veelgestelde vragen
- Moet ik de slave opnieuw opbouwen?
- Meestal niet. Als de binlogs op de master nog bestaan en de inconsistentie beperkt is, is de replicatie te repareren zonder rebuild. Een rebuild is nodig als de benodigde logs zijn opgeruimd of als de data structureel uiteen is gelopen.
- Kan ik de fout niet gewoon overslaan?
- Dat kan technisch, maar dan negeer je één wijziging die daarna voor altijd mist. Bij een DELETE die al was uitgevoerd is dat onschuldig; bij een INSERT verlies je data. Daarom eerst kijken wat het statement doet, en dan beslissen.
- Mijn slave loopt structureel achter. Wat helpt?
- Parallelle replicatieworkers, row-based logging, grote transacties opsplitsen en trage queries op de master aanpakken. Vaak blijkt één nachtelijke batch de dader. Dat is meetbaar te maken en daarna op te lossen.
- Durf je dit op een productiedatabase te doen?
- Ja, met de voorwaarde dat er een bruikbare back-up of snapshot is voordat we iets aanraken. Dat is niet onderhandelbaar — juist bij databases wil je een weg terug voordat je een stap vooruit zet.
Verwante problemen
Server start niet meer op
Een server die na een update of herstart niet meer boot: kernel, fstab, volle schijf of bootloader. Zo kom je via rescue mode weer binnen.
[Docker]Docker-container start niet of crasht direct
Container die direct stopt, exit code 137 of 125, volumes die leeg zijn na een herstart en containers die elkaar niet vinden. Dit check ik als eerste.
[502 Bad Gateway]502 Bad Gateway bij nginx oplossen
502 Bad Gateway betekent dat nginx je applicatie niet kan bereiken of geen geldig antwoord krijgt. Dit zijn de oorzaken en de eerste checks.
Zelf geen tijd of geen zin om te blijven zoeken?
Ik kijk mee, zeg eerlijk wat er aan de hand is en los het op. Bellen mag direct. Mail beantwoord ik meestal dezelfde werkdag.
Terug naar Linux serverbeheer en troubleshooting