MySQL Galera Cluster 4.0 er det nye barn på databaseblokken med meget interessante nye funktioner. I øjeblikket er den kun tilgængelig som en del af MariaDB 10.4, men i fremtiden vil den også fungere med MySQL 5.6, 5.7 og 8.0. I dette blogindlæg vil vi gerne gennemgå nogle af de nye funktioner, der fulgte med Galera Cluster 4.0.
Galera Cluster Streaming Replication
Den vigtigste nye funktion i denne udgivelse er streamingreplikering. Hidtil har certificeringsprocessen for Galera-klyngen fungeret på en måde, så hele transaktioner skulle certificeres, efter de var afsluttet.
Denne proces var ikke ideel i flere scenarier...
- Hotspots i tabeller, rækker, der meget hyppigt opdateres på flere noder - hundredvis af hurtige transaktioner, der kører på flere noder, ændring af det samme sæt rækker resulterer i hyppige deadlocks og tilbagerulning af transaktioner
- Langevarende transaktioner - hvis en transaktion tager betydelig tid at gennemføre, øger dette alvorligt chancerne for, at en anden transaktion i mellemtiden på en anden knude kan ændre nogle af de rækker, der også blev opdateret af den lange transaktion. Dette resulterede i et dødvande under certificeringen, og en af transaktionerne skulle rulles tilbage.
- Store transaktioner - hvis en transaktion ændrer et betydeligt antal rækker, er det sandsynligt, at en anden transaktion, på samme tid, på en anden node, vil ændre en af rækkerne, der allerede er ændret af den store transaktion. Dette resulterer i et dødvande under certificeringen, og en af transaktionerne skal rulles tilbage. Ud over dette vil store transaktioner tage yderligere tid at blive behandlet, sendt til alle noder i klyngen og certificeret. Dette er ikke en ideel situation, da det tilføjer forsinkelse til commits og sinker hele klyngen.
Heldigvis kan streaming-replikering løse disse problemer. Den største forskel er, at certificeringen sker i bidder, hvor der ikke er behov for at vente på, at hele transaktionen er gennemført. Som et resultat, selvom en transaktion er stor eller lang, er flertallet (eller alle, afhængigt af de indstillinger, vi vil diskutere om et øjeblik) af rækker låst på alle noderne, hvilket forhindrer andre forespørgsler i at ændre dem.
MySQL Galera Cluster Streaming Replikeringsmuligheder
Der er to konfigurationsmuligheder for streamingreplikering:
wsrep_trx_fragment_size
Dette fortæller, hvor stort et fragment skal være (som standard er det sat til 0, hvilket betyder, at streaming-replikeringen er deaktiveret)
wsrep_trx_fragment_unit
Dette fortæller, hvad fragmentet egentlig er. Som standard er det bytes, men det kan også være et 'statements' eller 'rows'.
Disse variabler kan (og bør) indstilles på et sessionsniveau, hvilket gør det muligt for brugeren at bestemme, hvilken bestemt forespørgsel der skal replikeres ved hjælp af streamingreplikering. Indstilling af enhed til 'sætninger' og størrelse til 1 gør det f.eks. muligt at bruge streamingreplikering kun til en enkelt forespørgsel, som f.eks. opdaterer et hotspot.
Du kan konfigurere Galera 4.0 til at certificere hver række, du har ændret, og gribe låsene på alle noderne, mens du gør det. Dette gør streamingreplikering fantastisk til at løse problemer med hyppige deadlocks, som før Galera 4.0 kun var mulige at løse ved at omdirigere alle skrivninger til en enkelt node.
WSREP-tabeller
Galera 4.0 introducerer flere tabeller, som vil hjælpe med at overvåge klyngens tilstand:
- wsrep_cluster
- wsrep_cluster_members
- wsrep_streaming_log
Alle er placeret i 'mysql'-skemaet. wsrep_cluster vil give indsigt i klyngens tilstand. wsrep_cluster_members vil give dig information om de noder, der er en del af klyngen. wsrep_streaming_log hjælper med at spore tilstanden af streaming-replikeringen.
Kommende funktioner i Galera Cluster
Codership, virksomheden bag Galera, er ikke færdig endnu. Vi var i stand til at få en forhåndsvisning af køreplanen fra CEO, Seppo Jaakola, som blev givet på Percona Live tidligere i år. Tilsyneladende kommer vi til at se funktioner som XA-transaktionssupport og gcache-kryptering. Det er rigtig gode nyheder.
Support til XA-transaktioner vil være mulig takket være streamingreplikeringen. Kort sagt er XA-transaktioner de distribuerede transaktioner, som kan køre på tværs af flere noder. De bruger to-faset commit, som kræver først at erhverve alle nødvendige låse for at køre transaktionen på alle noderne og derefter, når det er gjort, commit ændringerne. I tidligere versioner havde Galera ikke midler til at låse ressourcer på eksterne noder, med streamingreplikering er dette ændret.
Gcache er en fil, som gemmer skrivesæt. Dens indhold sendes til joiner noder, som beder om en dataoverførsel. Hvis alle data er gemt i gcachen, vil joiner kun modtage de manglende transaktioner i processen kaldet Incremental State Transfer (IST). Hvis gcache ikke indeholder alle påkrævede data, vil State Snapshot Transfer (SST) være påkrævet, og hele datasættet skal overføres til den forbindende node.
Gcache indeholder oplysninger om de seneste ændringer, derfor er det fantastisk at se indholdet krypteret for bedre sikkerhed. Med bedre sikkerhedsstandarder, der indføres gennem flere og flere reguleringer, er det afgørende, at softwaren bliver bedre til at opnå compliance.
Konklusion
Vi ser bestemt frem til at se, hvordan Galera Cluster 4.0 vil fungere på databaser end MariaDB. At kunne implementere MySQL 5.7 eller 8.0 med Galera Cluster vil være virkelig fantastisk. Galera er trods alt en af de mest testede synkrone replikeringsløsninger, der er tilgængelige på markedet.