Ga naar de inhoud 
MariaDB Undo bepaalt hoe InnoDB oude rijversies opslaat, rollbacks veilig uitvoert en consistente leesweergaven levert terwijl schrijfbewerkingen worden uitgevoerd. Ik laat zien hoe undo-logs samenwerken met de History List en Purge, waarom lange transacties geheugen vastleggen en hoe ik de groei van de Ongedaan maken-gebieden controleer.
Centrale punten
- MVCC en consistente leesbewerkingen: Undo slaat oude versies op, lezers worden niet geblokkeerd.
- Geschiedenislijst: Commits voegen geschiedenis toe, Purge verwijdert deze.
- Lange transacties: Ze behouden oude versies, belasten het geheugen en veroorzaken vertragingen.
- Configuratie: Undo-tablespaces, purge-threads en truncate bepalen de groei.
- Controle: Controleer vroegtijdig de lengte van de geschiedenis, de leeftijd van transacties en de grootte van undo-blokken.
Hoe undo-logs MVCC mogelijk maken
Ik begin met de kern: elke wijziging schrijft de vorige versie van de regel naar de Ongedaan maken-Log, zodat een consistente momentopname geldig blijft. Lezers hebben toegang tot de juiste oudere versie, terwijl schrijvers nieuwe gegevens opslaan en indexen bijwerken; zo blijft Parallellisme hoog. Rijen vormen een keten met hun voorgangers, totdat Purge ze mag verwijderen. Zonder deze keten zouden rollbacks ontbreken en zouden leestoepassingen in de war raken. Juist hier vormt Undo de schakel tussen transactieveiligheid, isolatie en betrouwbare leestoegang.
Interne structuur van de undo-logs
Onder de motorkap onderscheid ik vooral twee soorten ‘undo’: Invoegen-Ongedaan maken en Update ongedaan maken. Met Insert-Undo kun je nog niet bevestigde invoegingen ongedaan maken. Update-Undo behoudt oudere versies bij wijzigingen of verwijderingsmarkeringen, zodat snapshots blijven functioneren. InnoDB markeert verwijderde rijen in eerste instantie alleen als verwijderd (Delete-Mark) en stelt de daadwerkelijke verwijdering uit totdat geen enkele snapshot ze meer kan zien. Deze scheiding is cruciaal: rollbacks hebben nauwkeurige eerdere toestanden nodig, terwijl consistente lezers een versie moeten vinden die logisch aansluit bij hun starttijdstip. Daarom verwijzen rijen intern naar de vorige versie, en bevatten indexen aanvullende informatie, zodat Purge later indexvermeldingen netjes kan bijwerken.
Geschiedenislijst, opschonen en opslag
Na elke commit worden de historische wijzigingen opgeslagen in de globale Geschiedenis Lijst die door de Purge-thread asynchroon wordt afgebroken. Als Purge dit niet bij kan houden, groeit deze lijst en blijven oude regelversies kunstmatig in stand. Dit leidt tot meer leesbewerkingen, meer I/O en grotere undo-tablespaces. In dergelijke situaties controleer ik altijd de isolatieniveaus en open snapshots, want een ongunstige Keuze van de isolatie verlengt de levensduur van oude versies. Wie de purge-snelheid, de lengte van de geschiedenis en actieve transacties in samenhang bekijkt, herkent knelpunten in een vroeg stadium en remt geheugendrift af voordat deze kritiek wordt.
Purge-mechanisme en afstemmingsopties
Purge werkt best effort: Het verzamelt opschoonbare vermeldingen uit de History List, verwijdert Delete-marks definitief, werkt secundaire indexen bij en maakt Undo-gebieden vrij. In systemen met een hoge wijzigingsfrequentie schaal ik de Parallellisme (bijvoorbeeld via meerdere Purge-workers) en pas de batchstrategie aan, zodat Purge continu, maar niet te intensief draait. Vuistregels:
- Korte, constante batches in plaats van sporadische grote runs – dat zorgt voor een gelijkmatige verdeling van I/O en checkpoints.
- Zet 'Purge' niet tegenover 'Geheugen' of 'Log-Flushing': beide methoden moeten gelijke tred houden.
- Ik los eerst lange snapshots op voordat ik de batchgrootte verder vergroot – anders gaat het effect verloren.
Belangrijk: Purge is geen vervanging voor een goede transactiediscipline. Zelfs bij een hoge mate van parallelliteit blijft Undo geblokkeerd zolang er oude snapshots bestaan. Ik houd daarom zowel de voortgang van Purge als de leeftijd van de transacties in de gaten en pas de werklast aan als Purge voortdurend achterloopt.
Configuratie van de Undo-tablespaces
Afhankelijk van de configuratie kan undo-informatie worden opgeslagen in de systeem-tablespace of in afzonderlijke Ongedaan maken-tablespaces. Ik scheid Undo graag af om de groei en I/O beter te kunnen beheersen. Veel installaties maken dynamische groei mogelijk, deels inclusief het vrijgeven van ruimte via Truncate. Dat klinkt handig, maar vergroot de noodzaak tot monitoring, omdat lange snapshots een snelle krimp verhinderen. Ik kies de opslaglocatie, grootte en paralleliteit van de purge-bewerkingen zo dat wijzigingsfrequenties en tijdvensters in de dagelijkse praktijk goed worden opgevangen en Restauratie niet lijdt.
| Instelling | Effect | Tip |
|---|---|---|
| innodb_undo_directory | Opslaglocatie voor Ongedaan maken-bestanden | Afzonderlijke gegevensdragers ontkoppelen I/O |
| innodb_purge_threads | Meer Zuiveren-Mijnwerkers | Verhogen bij een hoge wijzigingsfrequentie |
| innodb_undo_log_truncate | Maakt ongebruikte ruimte weer vrij | Alleen effectief als de geschiedenis vrij is |
| innodb_max_undo_log_size | Grenzwarde voor groei | Beschikbaarheid afhankelijk van de versie |
Geheugenindeling en aspecten van het bestandssysteem
Ik plaats afzonderlijke Undo-tablespaces bij voorkeur op snelle SSD’s, gescheiden van gegevens- en log-I/O. Als het bestandssysteem TRIM/Discard ondersteunt, kan een Truncate-bewerking opslagruimte fysiek teruggeven aan het besturingssysteem. Toch houd ik rekening met conservatieve bovengrenzen, omdat het vrijgeven van ruimte niet gegarandeerd is zolang snapshots aan Undo zijn gekoppeld. Ook compressie op het bestandssysteem loont alleen de moeite als er CPU-capaciteit beschikbaar is en schrijfpatronen niet fragmenteren. Het blijft belangrijk om pieken in de latentie in de gaten te houden: als Undo groeit op een overbelaste schijf, nemen write amplification en checkpoint-druk geleidelijk toe.
Monitoring en diagnose
Ik controleer regelmatig de grootte van de Ongedaan maken-tablespaces, de lengte van de History List en de leeftijd van openstaande transacties. SHOW ENGINE InnoDB STATUS, Performance-schema en Information-schema geven duidelijke signalen. Als de Undo-gebieden groeien terwijl Purge weinig effect heeft, sluit ik eerst oude sessies af. Daarnaast kijk ik naar vergrendelingen, want onnodige Rijsloten verlengen transacties en snapshots. Wie deze statistieken dagelijks bekijkt, voorkomt plotselinge I/O-pieken en verkort de paden in het Geheugen.
Gevolgen voor de prestaties van langdurige transacties
Lange lees- of schrijftransacties uitstellen Versies vast, zelfs als ze logisch gezien verouderd zijn. Dit zorgt ervoor dat de Undo-lijst uitdijt, scans langer duren en de druk op de cache toeneemt. Ik beperk dergelijke effecten door kortere batches te gebruiken, consequent COMMIT uit te voeren en time-outs voor sessies in te stellen. Rapporten die urenlang worden gelezen, draaien beter in kleinere vensters of tegen replicaten. Wie autocommit uitschakelt, queryplannen stroomlijnt en inactieve transacties afsluit, ontlast Purge en verlicht de druk op de Instantie.
Rollback-segmenten en parallelliteit
Undo-vermeldingen bevinden zich in Rollback-segmenten, die als het ware slots bieden voor gelijktijdig actieve wijzigingen. Veel gelijktijdige schrijvers hebben baat bij voldoende rollback-segmenten, omdat invoegingen en updates hun undo-ketens dan minder vaak hoeven te delen. Ik houd wachtrijpatronen voor rollback-bronnen in de gaten en verhoog het aantal daarvan waar de versie en distributie dat toelaten. Symptomen van een gebrek aan parallelliteit zijn onverwachte wachttijden in verder korte updatefasen of sterk schommelende schrijflatenties onder belasting. Meer segmenten verdelen de druk, maar doen niets af aan de basisregel: lange snapshots zijn beter dan welke tuning dan ook.
Isolatieniveaus in detail
De Isolatieniveau bepaalt hoe lang undo-versies zinvol zijn. In REPEATABLE READ behoudt een transactie haar start-snapshot gedurende de gehele looptijd; undo blijft dus potentieel zeer lang vastgelegd. In READ COMMITTED worden per instructie weergavevensters gevormd; dit verkort bij veel workloads de levensduur van oude versies aanzienlijk. SELECT … FOR UPDATE en LOCK IN SHARE MODE leggen vergrendelingen op en wijzigen het concurrency-profiel – nuttig tegen ‘lost updates’, maar kritisch voor ‘undo’ als lezers te lang open blijven staan. Ik gebruik READ COMMITTED daarom doelgericht op plaatsen waar rapporten of API-leesbewerkingen consistente, maar niet transactiebrede weergaven nodig hebben, en blijf bij REPEATABLE READ wanneer de bedrijfslogica dat vereist.
Herstel- en opstartscenario's
Bij het opstarten gebruikt InnoDB de Ongedaan maken-Informatie om onvolledige transacties netjes terug te draaien. Dit zorgt voor consistente weergaven voordat nieuwe clients aan de slag gaan. In uitzonderlijke gevallen zijn er opstartmodi die controles inkorten, maar ik gebruik deze alleen in noodgevallen. Louter versnellen zonder diagnose heeft nadelige gevolgen, omdat integriteit voorrang heeft. Wie de hersteltijd en de omvang van ongedaan-maakbewerkingen in de gaten houdt, neemt betere beslissingen over onderhoudsvensters en Risico.
Praktijkregels voor de administratie
Ik houd transacties kort, voer regelmatig commit-bewerkingen uit en vermijd eindeloze leessessies, zodat Zuiveren de vrije loop heeft. Grotere massale wijzigingen verdeel ik in zorgvuldig gedoseerde batches, zodat de History List niet te groot wordt. Ik schaal de purge-threads op basis van de wijzigingssnelheid en pas de undo-lay-out aan de opslaghardware aan. Daarnaast documenteer ik bedrijfsprocessen die lange snapshots vereisen en plan ik bewust tijdvensters in. Zo blijft het gebruik van Undo voorspelbaar en de Latency laag.
Workloadpatronen en optimalisatie
E-commerce, rapportages en contentsystemen brengen veel veranderingen met zich mee en vereisen een gedisciplineerde aanpak Transacties. Ik stel conservatieve time-outs in voor lezers, optimaliseer indexen voor uiterst nauwkeurige updates en beperk de batchgroottes. Bij een hoge schrijfbelasting verhoog ik de paralleliteit van het opschonen en regel ik de checkpoint-druk. Daarnaast controleer ik de schrijfsnelheid in verhouding tot Transactielogboeken en herstel, zodat het herstel na een crash voorspelbaar blijft. Deze samenwerking zorgt ervoor dat het Undo-volume planbaar blijft en beschermt de Consistentie.
Back-ups en replicatie
Logische back-ups met een consistente snapshot verlengen noodzakelijkerwijs de levensduur van oude versies – de Undo-log groeit totdat de back-up is voltooid. Ik plan dergelijke runs buiten piekuren, beperk het aantal gelijktijdige schrijvers en zorg voor voldoende purge-capaciteit. Fysieke back-ups kunnen de Undo-belasting verminderen, maar ontslaan je niet van de zorgvuldigheid bij het maken van snapshots. Op replica’s bewaar ik rapporten bij voorkeur in READ COMMITTED en sluit ik lange inactieve transacties af, zodat SQL-Apply geen achterstand oploopt. Als een replica achterop raakt, neemt ook daar de undo-belasting toe, omdat het bijwerken van veel verwijderingen en updates een golf aan geschiedenis produceert die eerst door purge moet worden verwerkt.
Runbook: De groei van Undo snel een halt toeroepen
- Actieve langlaufers identificeren: de duur van open transacties en sessies met grote resultatensets controleren.
- Transacties die inactief zijn, consequent beëindigen: controleer of autocommit is ingeschakeld en sluit vergeten cursors.
- De purge-capaciteit verhogen: extra workers activeren en de batches iets vergroten.
- Tips voor schrijvers: batchgroottes beperken, micro-commits invoeren.
- Gebruik onderhoudsvensters: verplaats grote verwijderings- en updategolven naar planbare tijdvakken.
- Na stabilisatie: ‘Undo-Truncate’ toestaan totdat de grootte van het bestandssysteem weer aan de behoefte voldoet.
Capaciteitsplanning voor Undo
Ik bereken de Undo-capaciteit op conservatieve wijze op basis van de wijzigingssnelheid, de gemiddelde regelgrootte en het maximale snapshot-venster. Een eenvoudige benadering: wijzigingsgebeurtenissen per seconde × gemiddelde payload × gepland venster in seconden. Houd rekening met een veiligheidsmarge voor index- en metagegevens. Deze vuistregel geeft een idee van de worst-case-behoefte en voorkomt verrassingen bij rapportages, back-ups of migraties. tegelijkertijd Snapshots vastleggen. In groeiende systemen controleer ik elk kwartaal of verschuivingen in de werklast (nieuwe functies, meer mobiele clients, grotere pieken) de behoefte veranderen.
Bijzondere gevallen: tijdelijke tabellen en DDL
Tijdelijke InnoDB-tabellen maken gebruik van eigen gebieden; wijzigingen daarin belasten de reguliere undo-functie minder, maar kunnen bij grote sorteer- en join-bewerkingen toch veel I/O genereren. DDL-bewerkingen zoals ALTER TABLE veroorzaken vaak enorme golven van wijzigingen – indien nodig splits ik deze op in incrementele stappen en plan ik ze in tijdens rustige periodes. Ook hier geldt: korte, nette transacties zijn beter dan riskante snelkoppelingen. Als een DDL-run wordt afgebroken, helpt Undo om terug te keren naar een consistente toestand; daarvoor is echter voldoende geheugen en tijd nodig, die ik van tevoren inplan.
Voorbeeld: effecten meten
Ik begin met een momentopname van de grootte van de undo-buffer, die Geschiedenis-lengte en de gemiddelde transactieduur. Vervolgens breng ik gerichte wijzigingen aan, zoals het verhogen van het aantal purge-threads of het verkleinen van de batchgroottes. Vervolgens vergelijk ik de statistieken totdat de groei van het undo-volume en de latentie in een gezond evenwicht komen. Als ik uitschieters tegenkom, bekijk ik queryplannen en sessielijsten om vastgelopen lezers te identificeren. Deze cyclische werkwijze levert snelle resultaten op, zonder dat de Beschikbaarheid in gevaar brengen.
Veelvoorkomende misvattingen
Een commit verwijdert oude versies niet onmiddellijk; Zuiveren beslist pas later. Truncate-opties lossen geen fundamenteel ontwerpprobleem op als transacties te lang blijven bestaan. Grote undo-bestanden duiden niet per se op corruptie; vaak blokkeert één enkele sessie het systeem. Lezers blokkeren schrijvers weliswaar zelden, maar ongeschikte query's verlengen indirect de duur van snapshots. Wie deze misvattingen uit de weg ruimt, neemt betere beslissingen en vermindert Uitvaltijden.
Samenvatting voor wie haast heeft
Undo-logs bijhouden Verleden tastbaar, zodat InnoDB transacties veilig ongedaan maakt en lezers een consistent beeld te zien krijgen. Ik houd de groei onder controle door transacties te stroomlijnen, purge-threads op de juiste manier in te stellen en undo-tablespaces op een verstandige manier te plaatsen. Door de lengte van de geschiedenis, de omvang van de undo-tablespaces en de leeftijd van transacties te monitoren, worden trends al in een vroeg stadium zichtbaar. Bij afwijkingen controleer ik de werklast, vergrendelingen en sessies, in plaats van alleen aan de symptomen te sleutelen. Wie deze routine in stand houdt, behoudt prestaties, consistentie en herstart altijd onder controle.
