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 of mail en leg het voor. Neem ik niet op, stuur dan even een mail.
Herken je dit?
- Replicatie is gestopt met een foutmelding en start niet meer.
- Seconds_Behind_Master (of Seconds_Behind_Source) 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 transactie. 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 grote transacties
Eén trage query of een grote transactie houdt de replicatie op. Een grote DELETE wordt met row-based logging miljoenen row events, en een tabel zonder primary key wordt dan per rij doorzocht. MariaDB past standaard alles nog op één thread toe.
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_SQL_ErrorenLast_IO_Errorvolledig. Bij row-based replicatie zie je daar het event en de binlog-positie, niet de query. Metmysqlbinlog --base64-output=decode-rows -vvop die positie zie je wat de wijziging was. - 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_counter(in MySQL 8sql_replica_skip_counter) is verleidelijk, maar je slaat dan de hele transactie over, niet één statement. Met GTID op MySQL werkt het niet eens: daar zet je een lege transactie in voor die GTID. Kijk eerst wat er in de transactie zit en of de data aan beide kanten verschilt. - 4
Vergelijk de data voordat je conclusies trekt
Vergelijk de betrokken rijen aan beide kanten. Dan weet je of de inconsistentie bij één rij blijft of breder zit, en of repareren zin heeft. Loopt de replicatie weer, dan kan
pt-table-checksumde hele database nalopen. - 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 sla je de hele transactie over en die mist daarna voor altijd. Een duplicate key bij een INSERT betekent dat de rij er al staat. Is die gelijk, dan is overslaan onschuldig. Een UPDATE overslaan die zijn rij niet vindt, betekent dat je replica nu afwijkt. En alles wat verder in die transactie zat, ben je ook kwijt. Dus eerst kijken wat erin zit, en dan beslissen.
- Mijn slave loopt structureel achter. Wat helpt?
- Grote transacties opsplitsen, elke tabel een primary key geven, parallelle workers aanzetten (op MariaDB staan die standaard uit) 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, data die weg is na een update 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.
Wil je dit bespreken?
Bel of mail met je vraag. Neem ik niet op, stuur dan even een mail.
Terug naar Linux-serverbeheer en hosting