I en af de tidligere blogs dækkede vi nye funktioner, som kommer ud i MariaDB 10.4. Vi nævnte der, at inkluderet i denne version vil være en ny Galera Cluster-udgivelse. I dette blogindlæg vil vi gennemgå funktionerne i Galera Cluster 26.4.0 (eller Galera 4), tage et hurtigt kig på dem og undersøge, hvordan de vil påvirke din opsætning, når du arbejder med MariaDB Galera Cluster.
Streamende replikering
Galera Cluster er på ingen måde en drop-in-erstatning for standalone MySQL. Den måde, hvorpå skrivesættets certificering fungerer, introducerede adskillige begrænsninger og kanttilfælde, som alvorligt kan begrænse muligheden for at migrere til Galera Cluster. De tre mest almindelige begrænsninger er...
- Problemer med lange transaktioner
- Problemer med store transaktioner
- Problemer med hotspots i tabeller
Det, der er fantastisk at se, er, at Galera 4 introducerer Streaming Replication, som kan hjælpe med at reducere disse begrænsninger. Lad os gennemgå den aktuelle tilstand lidt mere detaljeret.
Langvarende transaktioner
I dette tilfælde taler vi tidsmæssigt, hvilket helt sikkert er problematisk i Galera. Det vigtigste at forstå er, at Galera replikerer transaktioner som skrivesæt. Disse skrivesæt er certificeret på medlemmerne af klyngen, hvilket sikrer, at alle noder kan anvende et givet skrivesæt. Problemet er, at låse oprettes på den lokale node, de replikeres ikke på tværs af klyngen, så hvis din transaktion tager flere minutter at gennemføre, og hvis du skriver til mere end én Galera-node, er det med tiden mere og mere sandsynligt, at en af de resterende noder vil nogle transaktioner ændre nogle af rækkerne, der er opdateret i din langvarige transaktion. Dette vil medføre, at certificeringen mislykkes, og en langvarig transaktion skal rulles tilbage. Kort sagt, hvis du sender skrivninger til mere end én node i klyngen, er transaktionen længere, jo større er sandsynligheden for, at certificeringen mislykkes på grund af en eller anden konflikt.
Hotspots
Med det mener vi rækker, som jævnligt opdateres. Typisk er det en slags tæller, der bliver opdateret igen og igen. Synderen bag problemet er den samme som ved lange transaktioner - rækker låses kun lokalt. Igen, hvis du sender skrivninger til mere end én node, er det sandsynligt, at den samme tæller vil blive ændret på samme tid på mere end én node, hvilket forårsager konflikter og får certificeringen til at mislykkes.
For begge disse problemer er der én løsning - du kan sende dine skrivninger til kun én node i stedet for at distribuere dem på tværs af hele klyngen. Du kan bruge proxyer til det - ClusterControl implementerer HAProxy og ProxySQL, begge kan konfigureres, så skrivninger kun sendes til én node. Hvis du ikke kan sende skrivninger til kun én node, skal du acceptere, at du fra tid til anden vil se certificeringskonflikter og rollbacks. Generelt skal applikationer kunne håndtere rollbacks fra databasen - der er ingen vej udenom, men det er endnu vigtigere, når applikationen fungerer med Galera Cluster.
Alligevel er det ikke nok at sende trafikken til én node til at håndtere det tredje problem.
Store transaktioner
Det, der er vigtigt at huske på, er, at skrivesættet først sendes til certificering, når transaktionen er gennemført. Derefter sendes skrivesættet til alle noder, og certificeringsprocessen finder sted. Dette inducerer grænser for, hvor stor den enkelte transaktion kan være, da Galera, når den forbereder skrivesæt, gemmer den i en buffer i hukommelsen. For store transaktioner vil reducere klyngens ydeevne. Derfor er to variable blevet introduceret:wsrep_max_ws_rows, som begrænser antallet af rækker pr. transaktion (selvom det kan sættes til 0 - ubegrænset) og, endnu vigtigere:wsrep_max_ws_size, som kan sættes op til 2 GB. Så den største transaktion, du kan køre med Galera Cluster, er op til 2 GB i størrelse. Du skal også huske på, at certificering og anvendelse af den store transaktion også tager tid, hvilket skaber "lag" - læs efter skrivning vil den anden hitknude end der, hvor du oprindeligt foretog transaktionen, højst sandsynligt resultere i forkerte data, da transaktionen anvendes stadig.
Galera 4 kommer med Streaming Replication, som kan bruges til at afhjælpe alle disse problemer. Den største forskel vil være, at skrivesættet nu kan opdeles i dele - det vil ikke længere være nødvendigt at vente på, at hele transaktionen er færdig, før data vil blive replikeret. Dette kan få dig til at spekulere på - hvordan ser certificeringen ud i et sådant tilfælde? Kort sagt, certificering er på farten - hvert fragment er certificeret, og alle involverede rækker er låst på alle noderne i klyngen. Dette er en alvorlig ændring i, hvordan Galera fungerer - indtil nu blev låse oprettet lokalt, med streaming-replikeringslåse vil blive oprettet på alle noderne. Dette hjælper i de tilfælde, vi diskuterede ovenfor - låsning af rækker, når transaktionsfragmenter kommer ind, hjælper med at reducere sandsynligheden for, at transaktionen skal rulles tilbage. Modstridende transaktioner, der udføres lokalt, vil ikke være i stand til at få de låse, de har brug for, og vil skulle vente på, at den replikerende transaktion fuldfører og frigiver rækkelåsene.
I tilfælde af hotspots er det med streaming-replikering muligt at få låsene på alle noderne, når rækken opdateres. Andre forespørgsler, der ønsker at opdatere den samme række, skal vente på, at låsen frigives, før de vil udføre deres ændringer.
Store transaktioner vil drage fordel af streaming-replikeringen, fordi det ikke længere vil være nødvendigt at vente på, at hele transaktionen afsluttes, og de vil heller ikke være begrænset af transaktionsstørrelsen - store transaktioner vil blive opdelt i fragmenter. Det hjælper også med at udnytte netværket bedre - i stedet for at sende 2 GB data på én gang kan de samme 2 GB data opdeles i fragmenter og sendes over en længere periode.
Der er to konfigurationsmuligheder for streaming replikering:wsrep_trx_fragment_size, som fortæller hvor stort et fragment skal være (som standard er det sat til 0, hvilket betyder at streaming replikering er deaktiveret) og wsrep_trx_fragment_unit, som 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.
Selvfølgelig er der ulemper ved at køre streaming-replikeringen, primært på grund af det faktum, at låse nu er taget på alle noder i klyngen. Hvis du har set store transaktioner rulle tilbage i evigheder, vil en sådan transaktion nu skulle rulle tilbage på alle noderne. Det er klart, at den bedste praksis er at reducere størrelsen af en transaktion så meget som muligt for at undgå, at tilbagerulninger tager timer at gennemføre. En anden ulempe er, at skrivesæt, der er oprettet fra hvert fragment, af hensyn til nedbrudsgendannelse gemmes i tabellen wsrep_schema.SR på alle noder, som på en måde implementerer dobbelt-skrivebuffer, hvilket øger belastningen på klyngen. Derfor bør du omhyggeligt beslutte, hvilken transaktion der skal replikeres ved hjælp af streaming-replikeringen, og så længe det er muligt, bør du stadig holde dig til den bedste praksis med at have små, korte transaktioner eller opdele den store transaktion i mindre batches.
Backuplåse
Endelig vil MariaDB-brugere kunne drage fordel af backup-låse til SST. Ideen bag SST udført ved hjælp af (for MariaDB) mariabackup er, at hele datasættet skal overføres på et øjeblik, med redo-logs, der indsamles i baggrunden. Derefter skal der anskaffes en global lås, der sikrer, at der ikke sker nogen skrivning, den endelige position af fortryd-loggen skal indsamles og gemmes. Historisk set blev låsedelen for MariaDB udført ved hjælp af FLUSKE BORDE MED LÆSELÅS, som gjorde sit arbejde, men under tung belastning var det ret svært at erhverve. Det er også ret tungt - ikke kun transaktioner skal vente på, at låsen bliver frigivet, men også data skal skylles til disken. Nu, med MariaDB 10.4, vil det være muligt at bruge mindre påtrængende BACKUP LOCK, som ikke vil kræve, at data skal skylles, kun commits vil blive blokeret i låsens varighed. Dette burde betyde mindre påtrængende SST-operationer, hvilket bestemt er dejligt at høre. Alle, der skulle køre deres Galera Cluster i nødtilstand på én knude og krydsede fingre for, at SST ikke vil påvirke klyngedriften, burde være mere end glade for at høre om denne forbedring.
Kausal læses fra applikationen
Galera 4 introducerede tre nye funktioner, som er beregnet til at hjælpe med at tilføje understøttelse af kausale læsninger i applikationerne - WSREP_LAST_WRITTEN_GTID(), som returnerer GTID for den sidste skrivning foretaget af klienten, WSREP_LAST_SEEN_GTID(), som returnerer GTID for den sidst observerede skrivetransaktion af klienten og WSREP_SYNC_WAIT_UPTO_GTID(), som vil blokere klienten, indtil det GTID, der sendes til funktionen, vil blive begået på noden. Selvfølgelig kan du håndhæve kausale læsninger i Galera selv nu, men ved at bruge disse funktioner vil det være muligt at implementere sikker læsning efter skrivning i de dele af applikationen, hvor det er nødvendigt, uden at du behøver at foretage ændringer i Galera-konfigurationen.
Opgradering til MariaDB Galera 10.4
Hvis du gerne vil prøve Galera 4, er den tilgængelig i den seneste udgivelseskandidat til MariaDB 10.4. I henhold til MariaDB-dokumentationen er der i øjeblikket ingen måde at lave en live-opgradering af 10.3 Galera til 10.4. Du skal stoppe hele 10.3-klyngen, opgradere den til 10.4 og derefter starte den igen. Dette er en alvorlig blokering, og vi håber, at denne begrænsning vil blive fjernet i en af de næste versioner. Det er af yderste vigtighed at have mulighed for en live-opgradering, og for at både MariaDB 10.3 og MariaDB 10.4 skal eksistere side om side i den samme Galera Cluster. En anden mulighed, som også kan være egnet, er at opsætte asynkron replikering mellem gamle og nye Galera Cluster.
Vi håber virkelig, du nød denne korte gennemgang af funktionerne i MariaDB 10.4 Galera Cluster, vi ser frem til at se streaming-replikering i rigtige live-produktionsmiljøer. Vi håber også, at disse ændringer vil bidrage til at øge Galera-adoptionen yderligere. Når alt kommer til alt, løser streamingreplikering mange problemer, som kan forhindre folk i at migrere til Galera.