09/04/2021
Redundantie en betrouwbare failovers
Het zijn open deuren, maar toch zijn redundantie en failovers vaak niet goed geregeld. Hoe zorg je ervoor dat je redundantie en betrouwbare failovers goed zijn geregeld?
Blog
MySQL, welke variant dan ook, wordt vandaag de dag ontzettend veel gebruikt. Of het nu voor een standaard Magento website is, of een volledig eigen ontwikkelde applicatie; een database is een must. De eerste versie van MySQL werd al in 1995 uitgebracht, en sinds juli 2013 is MySQL op SQLite na het meest gebruikt (SQLite staat op elk iPhone en Android device).
MySQL biedt replicatie sinds 2000 met MySQL versie 3.23. Met replicatie is het mogelijk om een master-slave setup te draaien waarbij de master gebruikt wordt door de applicatie. Alle wijzigingen op de master komen middels replicatie ook op de slave terecht die daarna gebruikt kan worden als hot standby of om consistente back-ups te maken. Het is ook mogelijk om beide servers met elkaar in een master-slave setup te zetten wat ook wel een MySQL Multi Master setup, of master-master setup wordt genoemd. Door de verschillende mogelijkheden goed te combineren met een goed doordachte applicatie, kunnen mooie redundante setups gemaakt worden.
Figuur 1. Een master-master setup
Replicatie is nodig om een redundante setup te kunnen creëren. Hierdoor kan een hogere beschikbaarheid behaald worden en kan er onderhoud uitgevoerd worden zonder dat de applicatie hiervan last heeft. Ook kan dit gebruikt worden om extra servers bij te schalen voor het verdelen van de belasting en dus het verbeteren van de performance. Master-master replicatie is bij Cyso een heel vaak gebruikte setup.
Dit klinkt allemaal heel mooi, en veelal is dat het ook, er zijn echter natuurlijk ook problemen. Het is vrij simpel om de replicatie te breken of ervoor te zorgen dat de verschillende databases niet meer over gelijke data beschikken. Soms is het dan noodzakelijk om één node leeg te halen en volledig opnieuw te voorzien van de data van de andere. Om die data te krijgen moet er een volledige consistente database dump gemaakt worden, waarbij de tabellen gelocked worden en de applicatie vrijwel altijd voor een aanzienlijke tijd offline moet. Dit wil je natuurlijk liever voorkomen. Niemand zit te wachten op downtime van zijn of haar applicatie en net als andere mensen slapen beheerders ‘s nachts ook liever.
In 2008 heeft Percona geïnvesteerd in een open source project dat ‘Maatkit’ werd genoemd. Dit project bood een aantal tools om ontwikkelaars en administrators te helpen die met open source databases als MySQL bezig zijn. Maatkit is inmiddels door Percona opgenomen in de Percona Toolkit. Dit is geen onderdeel van de Percona database zelf (een variant van MySQL), maar een aparte open source toolkit die te gebruiken is voor MySQL of compatible databases.
Ik wil in dit artikel twee onderdelen van de Percona Toolkit onder de aandacht brengen omdat deze enorm kunnen helpen als er afwijkingen optreden tussen gerepliceerde databases. De pt-table-checksum en pt-table-sync tool.
Stel we hebben een MySQL master-master setup zoals eerder weergegeven. Deze bestaat uit 2 nodes die beide actief worden gebruikt. Ondanks dat alles er goed uitziet kan het onzeker zijn of er wellicht afwijkingen tussen de 2 databases zijn geslopen de laatste tijd; om wat voor reden dan ook. Een dump maken en de replicatie opnieuw opzetten kan, maar wellicht overschrijf je dan data die op de andere node stond, en niet weg mag. Het is dus gewenst om beide data sets met elkaar te vergelijken.
Hier biedt de Percona Toolkit uitkomst met de tool ‘pt-table-checksum‘ omdat deze exact dit doet.
De tool wordt uitgevoerd op één van de master nodes met de benodigde opties (zoals welke databases je wel en niet wilt controleren). De tool zal op die node de database ‘percona’ met de tabel ‘checksums’ aanmaken. Door de replicatie worden deze ook op de andere node aangemaakt. De tool gaat per database aan de slag en verwerkt één tabel tegelijk. Per tabel zal deze een set aan rows (een chunk) pakken, van deze set een crc value berekenen en in de percona.checksums tabel invoegen. Doordat we statement-based replicatie gebruiken (hetgeen hiervoor noodzakelijk is) zal exact dezelfde set aan de andere kant gebruikt worden en de resultaten daar in dezelfde tabel weggeschreven worden.
Fig. 2 pt-table-checksums
Er wordt een query op de master database uitgevoerd (1a) die een row invoegt in percona.checksums met de uit te rekenen crc waarde van een chunk. Het resultaat wordt weggeschreven in een this_crc record. Vervolgens wordt automatisch de query gerepliceerd naar de slave (2a) waarna hetzelfde proces opnieuw begint voor de volgende chunk.
Ondertussen zal de tool de this_crc ophalen en de row updaten waarbij de value in master_crc wordt gezet (1b). Hier wordt dus niet iets uitgelezen en meteen gezet in één query, maar zal de waarde letterlijk meegegeven worden. Ook dit wordt gerepliceerd naar de slave (2b).
Op deze wijze zal de master nu zijn eigen berekende crc hebben staan in this_crc en zijn eigen master_crc waarde. De slave zal dus zijn eigen berekende waarde in ‘this_crc’ hebben staan door de gerepliceerde query, echter doordat de master_crc gezet wordt door een value zal deze de data bevatten van de master.
Uiteindelijk hebben we op beide databases een als het goed is identieke persona.checksums tabel.
Als je de percona.checksums tabel in detail bekijkt zie je dat voor elke set of chunk er een rij wordt ingevoegd met de volgende data:
DB de database
TBL de tabel
CHUNCK het chunk id
CHUNK_TIME de tijd die nodig was om deze chunk te berekenen
CHUNK _INDEX de index gebruikt om de tabel in sets op te delen
LOWER_BOUNDRY de index waarde die het begin van de set aangeeft
UPPER_BOUNDRY de index waarde die het einde van de set aangeeft
THIS_CRC de berekende crc waarde van de chunk op DEZE HOST
THIS_CNT het aantal rows in de chunk op DEZE HOST
MASTER_CRC de berekende crc waarde van de chunk op de MASTER
MASTER_CNT het aantal rows in de chunk op de MASTER
TS het tijdstip waarop de tool klaar was met het checksummen van de tabel
Hierin zien we dus ook duidelijk welke master_? en this_? data er wordt opgeslagen. Dit biedt ons de mogelijkheid om per host de data op te vragen en vrij simpel te zien of er afwijkingen zijn ten opzichte van zijn master.
De tool kan een gesegmenteerde checksum berekening doen op de hele database zonder de performance te erg te beïnvloeden. Dit komt doordat de tool zelf de setgrootte bepaalt en deze zal aanpassen zodat een set nooit langer dan een halve seconde gelocked wordt. De setgrootte is dus variabel (en eventueel ook zelf op te geven). Op deze wijze wordt de load op de machine niet te hoog en blijven de tables niet te lang gelocked.
De tool verbindt ook met de slave server en houdt de replicatie in de gaten. Indien die te ver achter gaat lopen wordt de checksumming tijdelijk stop gezet. Structureel gezien zouden de databases bij de zelfde sql volgorde altijd dezelfde data moeten bevatten.
Indien er afwijkingen in de replicatie zijn, wordt dit gemeld en is er werk aan de winkel. Behalve dat we willen weten waarom dit gebeurd is, is het zaak om zo snel mogelijk consistente data te kunnen leveren aan de applicatie zodat de redundante setup hersteld kan worden.
Om de data gelijk te trekken heeft men de pt-table-sync tool gemaakt.
Vroeger was het veelal noodzakelijk om bij afwijkingen uit te zoeken wat er precies afwijkt en te kijken of en hoe dit te repareren is. Dit was een tijdrovend proces waarbij de databases uit productie gehaald moesten worden zodat met de hand één en ander vergeleken kon worden. Vaak was het al snel makkelijker om een volledige dump te maken en deze over te zetten naar de afwijkende database. Hiervoor moest echter vrijwel altijd de database gelocked worden zodat een consistente export gemaakt kon worden. Dat vereiste vervolgens een algehele database lock, hetgeen ervoor zorgde dat de applicatie niet kon wegschrijven naar de database. De meeste applicaties werkten dus gedurende dat proces niet of met verminderde functionaliteit.
Gelukkig heeft iemand daar over nagedacht en dat bracht de tool pt-table-sync voort. Deze tool kan de tabellen gebruiken die we net hebben laten aanmaken of zelf dezelfde check uitvoeren. Daarna wordt de slave gerepareerd door statements uit te voeren op de master. Deze statements gaan dan door de gehele replicatie heen en zullen op alle slave databases uitgevoerd worden. Dezelfde wijziging wordt dus overal gedaan waarbij het vervangen van data door identieke data natuurlijk geen probleem is. Het is dus wel zaak goed te begrijpen wat je doet en precies te doen wat nodig is in de specifieke situatie. Indien verkeerd gebruikt, kan deze tool meer stuk maken dan repareren; een eigenschap die vaak opgaat. Niets engs op zichzelf, maar wel goed nadenken en exact weten wat je doet.
Fig. 3 pt-table-sync
De tool ziet een afwijking (een verschil tussen master_crc en this_crc) in een aantal rows op de slave database (1). Om deze afwijking recht te trekken wordt de corresponderende chunk eerst opgehaald op de master (2) om vervolgens middels een REPLACE statement op de master nogmaals weg te schrijven (3). Deze (identieke, maar gewijzigde) data zal door de replicatie opgepakt worden en op die manier de data overschrijven (en dus corrigeren) op de slave (4).
Dit is slechts één voorbeeld van een simpele manier van reparatie, die ook niet in alle gevallen zal volstaan. De tool heeft echter enorm veel meer instellingen en mogelijkheden om nagenoeg elke situatie aan te kunnen; of het nu een master-slave setup is of een multi-master setup met daaronder meerdere lagen van slaves. Het is bijzonder belangrijk om de eigen situatie te begrijpen en daar vervolgens naar te handelen.
Met pt-table-checksum hebben we de mogelijkheid om afwijkingen in databases op te sporen zodat we gericht kunnen terugvinden wat de afwijkingen zijn. Als die gevonden en geanalyseerd zijn, biedt pt-table-sync de mogelijkheid om tabellen te synchroniseren zonder dat hiervoor de applicatie offline hoeft te worden gebracht.
“De Percona Toolkit gedraaid over een 40 GB database. Ik kon exact aangeven welke twee records fout waren, wat de oorzaak was en hoe de klant het zou kunnen oplossen.”
De extra controle is een mooie geruststelling voor klanten van Cyso. Aangezien de pt-table-sync tool ons in staat stelt om online meerdere databases gelijk te trekken kan dit kostbare downtime en mogelijk dataverlies schelen.