MySQL Galera Cluster 4.0 is de nieuweling in het databaseblok met zeer interessante nieuwe functies. Momenteel is het alleen beschikbaar als onderdeel van MariaDB 10.4, maar in de toekomst zal het ook werken met MySQL 5.6, 5.7 en 8.0. In deze blogpost willen we enkele van de nieuwe functies bespreken die bij Galera Cluster 4.0 zijn geleverd.
Galera Cluster Streaming Replicatie
De belangrijkste nieuwe functie in deze release is streamingreplicatie. Tot dusver werkte het certificeringsproces voor het Galera-cluster zodanig dat hele transacties moesten worden gecertificeerd nadat ze waren voltooid.
Dit proces was in verschillende scenario's niet ideaal...
- Hotspots in tabellen, rijen die zeer vaak worden bijgewerkt op meerdere knooppunten - honderden snelle transacties die op meerdere knooppunten worden uitgevoerd, waarbij dezelfde reeks rijen wordt gewijzigd, resulteert dit in frequente impasses en terugdraaien van transacties
- Langlopende transacties - als een transactie veel tijd kost om te voltooien, vergroot dit de kans aanzienlijk dat een andere transactie, in de tussentijd, op een ander knooppunt, enkele van de rijen kan wijzigen die ook zijn bijgewerkt door de lange transactie. Dit resulteerde in een impasse tijdens de certificering en een van de transacties moest worden teruggedraaid.
- Grote transacties - als een transactie een aanzienlijk aantal rijen wijzigt, is het waarschijnlijk dat een andere transactie, op hetzelfde moment, op een ander knooppunt, een van de rijen zal wijzigen die al zijn gewijzigd door de grote transactie. Dit resulteert in een impasse tijdens de certificering en een van de transacties moet worden teruggedraaid. Daarnaast kost het extra tijd om grote transacties te verwerken, naar alle nodes in het cluster te verzenden en te certificeren. Dit is geen ideale situatie omdat het vertragingen toevoegt aan de commits en het hele cluster vertraagt.
Gelukkig kan streaming-replicatie deze problemen oplossen. Het belangrijkste verschil is dat de certificering in delen gebeurt, waarbij niet hoeft te worden gewacht tot de hele transactie is voltooid. Het resultaat is dat, zelfs als een transactie groot of lang is, de meerderheid (of alle, afhankelijk van de instellingen die we zo dadelijk zullen bespreken) van rijen op alle knooppunten is vergrendeld, waardoor wordt voorkomen dat andere zoekopdrachten deze wijzigen.
MySQL Galera Cluster Streaming Replicatie Opties
Er zijn twee configuratie-opties voor streaming-replicatie:
wsrep_trx_fragment_size
Dit vertelt hoe groot een fragment moet zijn (standaard is dit ingesteld op 0, wat betekent dat de streaming-replicatie is uitgeschakeld)
wsrep_trx_fragment_unit
Dit vertelt wat het fragment werkelijk is. Standaard is dit bytes, maar het kan ook een ‘statements’ of ‘rows’ zijn.
Deze 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.
Je kunt Galera 4.0 configureren om elke rij die je hebt gewijzigd te certificeren en daarbij de vergrendelingen op alle knooppunten te pakken te krijgen. Dit maakt streamingreplicatie uitstekend geschikt voor het oplossen van problemen met frequente deadlocks die vóór Galera 4.0 alleen konden worden opgelost door alle schrijfbewerkingen naar één enkel knooppunt om te leiden.
WSREP-tabellen
Galera 4.0 introduceert verschillende tabellen, die zullen helpen om de status van het cluster te controleren:
- wsrep_cluster
- wsrep_cluster_members
- wsrep_streaming_log
Ze bevinden zich allemaal in het 'mysql'-schema. wsrep_cluster geeft inzicht in de status van het cluster. wsrep_cluster_members geeft u informatie over de knooppunten die deel uitmaken van het cluster. wsrep_streaming_log helpt bij het volgen van de status van de streamingreplicatie.
Galera Cluster Aankomende functies
Codership, het bedrijf achter de Galera, is nog niet klaar. We kregen een preview van de roadmap van CEO, Seppo Jaakola, die eerder dit jaar op Percona Live werd gegeven. Blijkbaar gaan we functies zien zoals XA-transactieondersteuning en gcache-codering. Dit is echt goed nieuws.
Ondersteuning voor XA-transacties is mogelijk dankzij de streamingreplicatie. Kort gezegd zijn XA-transacties de gedistribueerde transacties die over meerdere knooppunten kunnen lopen. Ze gebruiken commit in twee fasen, wat vereist dat eerst alle vereiste vergrendelingen worden verkregen om de transactie op alle knooppunten uit te voeren en vervolgens, als het eenmaal is gedaan, de wijzigingen vast te leggen. In eerdere versies had Galera geen middelen om bronnen op externe knooppunten te vergrendelen, met streamingreplicatie is dit veranderd.
Gcache is een bestand waarin schrijfsets worden opgeslagen. De inhoud ervan wordt verzonden naar joiner-knooppunten die om een gegevensoverdracht vragen. Als alle gegevens in de gcache zijn opgeslagen, ontvangt de joiner alleen de ontbrekende transacties in het proces dat Incremental State Transfer (IST) wordt genoemd. Als gcache niet alle vereiste gegevens bevat, is State Snapshot Transfer (SST) vereist en moet de hele gegevensset worden overgedragen naar het verbindingsknooppunt.
Gcache bevat informatie over recente wijzigingen, daarom is het geweldig om de inhoud versleuteld te zien voor een betere beveiliging. Nu door steeds meer regelgeving betere beveiligingsnormen worden ingevoerd, is het van cruciaal belang dat de software beter wordt in het bereiken van compliance.
Conclusie
We kijken er zeker naar uit om te zien hoe Galera Cluster 4.0 zal werken op databases dan MariaDB. In staat zijn om MySQL 5.7 of 8.0 te implementeren met Galera Cluster zal echt geweldig zijn. Galera is immers een van de meest geteste oplossingen voor synchrone replicatie die op de markt verkrijgbaar zijn.