In een van de vorige blogs hebben we het gehad over nieuwe functies die uitkomen in MariaDB 10.4. We hebben daar vermeld dat in deze versie een nieuwe Galera Cluster-release zal zijn. In deze blogpost bespreken we de functies van Galera Cluster 26.4.0 (of Galera 4), bekijken we ze snel en onderzoeken we hoe ze van invloed zijn op uw instellingen wanneer u met MariaDB Galera Cluster werkt.
Streaming-replicatie
Galera Cluster is zeker geen vervanging voor standalone MySQL. De manier waarop de writeset-certificering werkt, introduceerde verschillende beperkingen en randgevallen die de mogelijkheid om naar Galera Cluster te migreren ernstig kunnen beperken. De drie meest voorkomende beperkingen zijn...
- Problemen met lange transacties
- Problemen met grote transacties
- Problemen met hotspots in tabellen
Wat geweldig is om te zien, is dat Galera 4 Streaming Replication introduceert, wat kan helpen bij het verminderen van deze beperkingen. Laten we de huidige staat wat gedetailleerder bekijken.
Langlopende transacties
In dit geval hebben we het over de tijd, wat zeker problematisch is in Galera. Het belangrijkste om te begrijpen is dat Galera transacties repliceert als schrijfsets. Die schrijfsets zijn gecertificeerd op de leden van het cluster, zodat alle knoop punten de gegeven schrijfset kunnen toepassen. Het probleem is dat vergrendelingen op het lokale knooppunt worden gemaakt, ze worden niet over het hele cluster gerepliceerd, dus als uw transactie enkele minuten duurt om te voltooien en als u naar meer dan één Galera-knooppunt schrijft, wordt het na verloop van tijd steeds waarschijnlijker dat op een van de resterende knooppunten sommige transacties zullen enkele van de rijen wijzigen die zijn bijgewerkt in uw langlopende transactie. Hierdoor mislukt de certificering en moet een langlopende transactie worden teruggedraaid. Kortom, aangezien u schrijfbewerkingen naar meer dan één knooppunt in het cluster verzendt, geldt dat hoe langer de transactie, hoe groter de kans is dat de certificering mislukt vanwege een conflict.
Hotspots
Daarmee bedoelen we rijen, die regelmatig worden bijgewerkt. Meestal is het een soort teller die steeds opnieuw wordt bijgewerkt. De boosdoener van het probleem is hetzelfde als bij lange transacties - rijen worden alleen lokaal vergrendeld. Nogmaals, als u schrijfacties naar meer dan één knooppunt verzendt, is het waarschijnlijk dat dezelfde teller tegelijkertijd op meer dan één knooppunt wordt gewijzigd, waardoor er conflicten ontstaan en de certificering mislukt.
Voor beide problemen is er één oplossing:u kunt uw schrijfbewerkingen naar slechts één knooppunt sturen in plaats van ze over het hele cluster te verdelen. U kunt daarvoor proxy's gebruiken - ClusterControl implementeert HAProxy en ProxySQL, beide kunnen zo worden geconfigureerd dat schrijfbewerkingen naar slechts één knooppunt worden verzonden. Als u geen schrijfbewerkingen naar slechts één knooppunt kunt verzenden, moet u accepteren dat u van tijd tot tijd certificeringsconflicten en terugdraaiingen zult zien. Over het algemeen moet de applicatie in staat zijn om rollbacks uit de database aan te kunnen - daar kan niet omheen, maar het is nog belangrijker wanneer de applicatie werkt met Galera Cluster.
Toch is het verzenden van het verkeer naar één knooppunt niet voldoende om het derde probleem aan te pakken.
Grote transacties
Het is belangrijk om in gedachten te houden dat de schrijfset pas ter certificering wordt verzonden wanneer de transactie is voltooid. Vervolgens wordt de schrijfset naar alle knooppunten verzonden en vindt het certificeringsproces plaats. Dit leidt tot limieten voor hoe groot de enkele transactie kan zijn, aangezien Galera deze bij het voorbereiden van de schrijfset opslaat in een in-memory buffer. Te grote transacties verminderen de clusterprestaties. Daarom zijn er twee variabelen geïntroduceerd:wsrep_max_ws_rows, die het aantal rijen per transactie beperkt (hoewel het kan worden ingesteld op 0 - onbeperkt) en, belangrijker:wsrep_max_ws_size, dat kan worden ingesteld tot 2 GB. De grootste transactie die u met Galera Cluster kunt uitvoeren, is dus maximaal 2 GB groot. Houd er ook rekening mee dat certificering en het toepassen van de grote transactie ook tijd kost, waardoor "lag" ontstaat - lees na schrijven, dat hitknooppunt anders dan waar u de transactie aanvankelijk hebt gepleegd, hoogstwaarschijnlijk zal resulteren in onjuiste gegevens omdat de transactie wordt nog steeds toegepast.
Galera 4 wordt geleverd met Streaming Replication, die kan worden gebruikt om al deze problemen te verhelpen. Het belangrijkste verschil is dat de schrijfset nu in delen kan worden opgesplitst - het is niet langer nodig om te wachten tot de hele transactie is voltooid voordat de gegevens worden gerepliceerd. U vraagt zich misschien af:hoe ziet de certificering er in zo'n geval uit? Kortom, certificering is on-the-fly - elk fragment is gecertificeerd en alle betrokken rijen zijn vergrendeld op alle knooppunten in het cluster. Dit is een serieuze verandering in de manier waarop Galera werkt - tot nu toe werden vergrendelingen lokaal gemaakt, met streaming-replicatievergrendelingen zullen op alle knooppunten worden gemaakt. Dit helpt in de gevallen die we hierboven hebben besproken - het vergrendelen van rijen als transactiefragmenten binnenkomen, helpt de kans te verkleinen dat de transactie moet worden teruggedraaid. Conflicterende transacties die lokaal worden uitgevoerd, kunnen niet de vergrendelingen krijgen die ze nodig hebben en zullen moeten wachten tot de replicerende transactie is voltooid en de rijvergrendelingen vrijgeven.
In het geval van hotspots is het met streamingreplicatie mogelijk om de vergrendelingen op alle knooppunten te krijgen bij het bijwerken van de rij. Andere zoekopdrachten die dezelfde rij willen bijwerken, moeten wachten tot de vergrendeling is vrijgegeven voordat ze hun wijzigingen kunnen uitvoeren.
Grote transacties zullen profiteren van de streaming-replicatie omdat het niet langer nodig is om te wachten tot de hele transactie is voltooid, en ook niet wordt beperkt door de transactiegrootte - grote transacties worden opgesplitst in fragmenten. Het helpt ook om het netwerk beter te gebruiken - in plaats van 2 GB aan gegevens tegelijk te verzenden, kan dezelfde 2 GB aan gegevens worden opgesplitst in fragmenten en over een langere periode worden verzonden.
Er zijn twee configuratie-opties voor streaming-replicatie:wsrep_trx_fragment_size, dat aangeeft hoe groot een fragment moet zijn (standaard is dit ingesteld op 0, wat betekent dat de streaming-replicatie is uitgeschakeld) en wsrep_trx_fragment_unit, dat vertelt wat het fragment werkelijk is. Standaard is dit bytes, maar het kan ook een ‘statements’ of ‘rows’ zijn. Die variabelen kunnen (en moeten) worden ingesteld op sessieniveau, waardoor de gebruiker kan beslissen welke specifieke query moet worden gerepliceerd met behulp van streamingreplicatie. Door eenheid in te stellen op 'statements' en grootte op 1 kunt u bijvoorbeeld streamingreplicatie gebruiken voor slechts een enkele query die bijvoorbeeld een hotspot bijwerkt.
Natuurlijk zijn er nadelen aan het uitvoeren van de streamingreplicatie, voornamelijk vanwege het feit dat nu alle knooppunten in het cluster worden vergrendeld. Als u al eeuwenlang grote transacties terugdraait, moet een dergelijke transactie nu op alle knooppunten worden teruggedraaid. Het is duidelijk dat de beste praktijk is om de omvang van een transactie zo veel mogelijk te verminderen om te voorkomen dat het terugdraaien uren in beslag neemt. Een ander nadeel is dat, vanwege de crashherstelredenen, schrijfsets die van elk fragment zijn gemaakt, worden opgeslagen in de tabel wsrep_schema.SR op alle knooppunten, wat een soort van dubbele schrijfbuffer implementeert, waardoor de belasting van het cluster toeneemt. Daarom moet u zorgvuldig beslissen welke transactie moet worden gerepliceerd met behulp van de streamingreplicatie en, zolang dit mogelijk is, moet u zich nog steeds houden aan de best practices van het hebben van kleine, korte transacties of het opsplitsen van de grote transactie in kleinere batches.
Back-upvergrendelingen
Ten slotte kunnen MariaDB-gebruikers profiteren van back-upvergrendelingen voor SST. Het idee achter SST uitgevoerd met behulp van (voor MariaDB) mariabackup is dat de hele dataset on-the-fly moet worden overgedragen, waarbij de logs opnieuw worden verzameld op de achtergrond. Vervolgens moet een globale vergrendeling worden verkregen, die ervoor zorgt dat er niet wordt geschreven, en de uiteindelijke positie van het redo-logboek moet worden verzameld en opgeslagen. Historisch gezien werd voor MariaDB het vergrendelingsgedeelte uitgevoerd met behulp van FLUSH TABLES WITH READ LOCK, wat zijn werk deed, maar onder zware belasting vrij moeilijk te verkrijgen was. Het is ook behoorlijk zwaar - niet alleen transacties moeten wachten tot het slot wordt vrijgegeven, maar ook de gegevens moeten naar de schijf worden gespoeld. Nu, met MariaDB 10.4, is het mogelijk om minder opdringerige BACKUP LOCK te gebruiken, waarvoor geen gegevens hoeven te worden leeggemaakt, alleen commits worden geblokkeerd voor de duur van de vergrendeling. Dit zou minder opdringerige SST-bewerkingen moeten betekenen, wat absoluut geweldig is om te horen. Iedereen die zijn Galera-cluster in noodmodus moest laten draaien, op één knooppunt, duimen dat SST geen invloed zal hebben op clusteractiviteiten, zou meer dan blij zijn om over deze verbetering te horen.
Causale waardes van de toepassing
Galera 4 heeft drie nieuwe functies geïntroduceerd die bedoeld zijn om ondersteuning voor causale leesbewerkingen in de toepassingen toe te voegen:WSREP_LAST_WRITTEN_GTID(), die de GTID retourneert van de laatste schrijfactie die door de klant is gemaakt, WSREP_LAST_SEEN_GTID(), die de GTID retourneert van de laatst waargenomen schrijftransactie door de client en WSREP_SYNC_WAIT_UPTO_GTID(), die de client blokkeert totdat de GTID die aan de functie is doorgegeven, op het knooppunt wordt vastgelegd. Natuurlijk kun je zelfs nu causale leesbewerkingen in Galera afdwingen, maar door deze functies te gebruiken, is het mogelijk om veilig lezen na schrijven te implementeren in die delen van de applicatie waar dat nodig is, zonder dat er wijzigingen in de Galera-configuratie hoeven te worden aangebracht.
Upgraden naar MariaDB Galera 10.4
Als je Galera 4 wilt proberen, het is beschikbaar in de nieuwste release candidate voor MariaDB 10.4. Volgens de MariaDB-documentatie is er op dit moment geen manier om een live upgrade van 10.3 Galera naar 10.4 uit te voeren. U moet het hele 10.3-cluster stoppen, het upgraden naar 10.4 en het dan terug starten. Dit is een serieuze blokkering en we hopen dat deze beperking in een van de volgende versies zal worden verwijderd. Het is van het grootste belang om de mogelijkheid te hebben voor een live-upgrade en daarvoor zullen zowel MariaDB 10.3 als MariaDB 10.4 naast elkaar moeten bestaan in hetzelfde Galera-cluster. Een andere optie, die ook geschikt kan zijn, is het opzetten van asynchrone replicatie tussen oude en nieuwe Galera Cluster.
We hopen echt dat je genoten hebt van deze korte bespreking van de functies van MariaDB 10.4 Galera Cluster, we kijken uit naar streamingreplicatie in echte live-productieomgevingen. We hopen ook dat deze veranderingen zullen helpen om de acceptatie van Galera nog verder te vergroten. Streaming-replicatie lost immers veel problemen op die kunnen voorkomen dat mensen naar Galera migreren.