I en av de tidigare bloggarna täckte vi nya funktioner som kommer ut i MariaDB 10.4. Vi nämnde där att inkluderad i den här versionen kommer att vara en ny Galera Cluster-release. I det här blogginlägget kommer vi att gå över funktionerna i Galera Cluster 26.4.0 (eller Galera 4), ta en snabb titt på dem och utforska hur de kommer att påverka din installation när du arbetar med MariaDB Galera Cluster.
Strömmande replikering
Galera Cluster är inte på något sätt en drop-in-ersättning för fristående MySQL. Sättet på vilket skrivuppsättningscertifieringen fungerar introducerade flera begränsningar och kantfall som allvarligt kan begränsa möjligheten att migrera till Galera Cluster. De tre vanligaste begränsningarna är...
- Problem med långa transaktioner
- Problem med stora transaktioner
- Problem med hotspots i tabeller
Vad som är bra att se är att Galera 4 introducerar Streaming Replication, vilket kan hjälpa till att minska dessa begränsningar. Låt oss granska det aktuella tillståndet lite mer detaljerat.
Långa transaktioner
I det här fallet talar vi tidsmässigt, vilket definitivt är problematiska i Galera. Det viktigaste att förstå är att Galera replikerar transaktioner som skrivuppsättningar. Dessa skrivuppsättningar är certifierade på medlemmarna i klustret, vilket säkerställer att alla noder kan tillämpa en given skrivuppsättning. Problemet är att lås skapas på den lokala noden, de replikeras inte över klustret, så om din transaktion tar flera minuter att slutföra och om du skriver till mer än en Galera-nod, är det mer och mer troligt att på en av de återstående noderna kommer vissa transaktioner att ändra några av raderna som uppdateras i din långa transaktion. Detta kommer att göra att certifieringen misslyckas och långvariga transaktioner måste återställas. Kort sagt, om du skickar skrivningar till mer än en nod i klustret, längre är transaktionen, desto mer sannolikt är det att certifieringen misslyckas på grund av någon konflikt.
Hotspots
Med det menar vi rader, som uppdateras ofta. Vanligtvis är det någon sorts räknare som uppdateras om och om igen. Boven till problemet är densamma som vid långa transaktioner - rader låses endast lokalt. Återigen, om du skickar skrivningar till mer än en nod är det troligt att samma räknare kommer att ändras samtidigt på mer än en nod, vilket orsakar konflikter och gör att certifieringen misslyckas.
För båda dessa problem finns det en lösning - du kan skicka dina skrivningar till bara en nod istället för att distribuera dem över hela klustret. Du kan använda proxyservrar för det - ClusterControl distribuerar HAProxy och ProxySQL, båda kan konfigureras så att skrivningar skickas till endast en nod. Om du inte kan skicka skrivningar till endast en nod måste du acceptera att du kommer att se certifieringskonflikter och återställningar från tid till annan. I allmänhet måste applikationer kunna hantera återställningar från databasen - det finns ingen väg runt det, men det är ännu viktigare när applikationen fungerar med Galera Cluster.
Ändå är det inte tillräckligt att skicka trafiken till en nod för att hantera det tredje problemet.
Stora transaktioner
Det som är viktigt att tänka på är att skrivsetet skickas för certifiering först när transaktionen är klar. Därefter skickas skrivuppsättningen till alla noder och certifieringsprocessen äger rum. Detta inducerar gränser för hur stor den enskilda transaktionen kan vara eftersom Galera, när den förbereder skrivuppsättningen, lagrar den i minnesbuffert. För stora transaktioner kommer att minska klustrets prestanda. Därför har två variabler introducerats:wsrep_max_ws_rows, som begränsar antalet rader per transaktion (även om det kan sättas till 0 - obegränsat) och, ännu viktigare:wsrep_max_ws_size, som kan ställas in till 2 GB. Så den största transaktionen du kan köra med Galera Cluster är upp till 2 GB i storlek. Du måste också komma ihåg att certifiering och tillämpning av den stora transaktionen också tar tid, vilket skapar "lag" - läs efter skrivning kommer den träffnoden annan än där du ursprungligen utförde transaktionen med största sannolikhet resultera i felaktig data eftersom transaktionen tillämpas fortfarande.
Galera 4 kommer med Streaming Replication, som kan användas för att lindra alla dessa problem. Huvudskillnaden blir att skrivuppsättningen nu kan delas upp i delar - det kommer inte längre att behövas vänta på att hela transaktionen är klar innan data replikeras. Det kan få dig att undra - hur ser certifieringen ut i så fall? Kort sagt, certifieringen är i farten - varje fragment är certifierat och alla inblandade rader är låsta på alla noder i klustret. Detta är en allvarlig förändring i hur Galera fungerar - tills nu har lås skapats lokalt, med strömmande replikeringslås kommer att skapas på alla noder. Detta hjälper i de fall vi diskuterade ovan - att låsa rader när transaktionsfragment kommer in, hjälper till att minska sannolikheten för att transaktionen måste återställas. Motstridiga transaktioner som utförs lokalt kommer inte att kunna få de lås de behöver och kommer att behöva vänta på att den replikerande transaktionen slutförs och släpper radlåsen.
När det gäller hotspots, med strömmande replikering är det möjligt att få lås på alla noder vid uppdatering av raden. Andra frågor som vill uppdatera samma rad måste vänta på att låset släpps innan de kommer att utföra sina ändringar.
Stora transaktioner kommer att dra nytta av streamingreplikeringen eftersom det inte längre kommer att behövas vänta på att hela transaktionen ska slutföras och de kommer inte heller att begränsas av transaktionsstorleken - stora transaktioner kommer att delas upp i fragment. Det hjälper också till att utnyttja nätverket bättre - istället för att skicka 2 GB data på en gång kan samma 2 GB data delas upp i fragment och skickas över en längre tidsperiod.
Det finns två konfigurationsalternativ för strömmande replikering:wsrep_trx_fragment_size, som talar om hur stort ett fragment ska vara (som standard är det satt till 0, vilket betyder att strömmande replikering är inaktiverat) och wsrep_trx_fragment_unit, som talar om vad fragmentet egentligen är. Som standard är det bytes, men det kan också vara ett "statement" eller "rader". Dessa variabler kan (och bör) ställas in på en sessionsnivå, vilket gör det möjligt för användaren att bestämma vilken speciell fråga som ska replikeras med hjälp av strömmande replikering. Om du ställer in enheten till "statement" och storleken till 1 kan du till exempel använda strömmande replikering bara för en enda fråga som till exempel uppdaterar en hotspot.
Naturligtvis finns det nackdelar med att köra streaming-replikeringen, främst på grund av att låsningar nu tas på alla noder i klustret. Om du har sett stora transaktioner rulla tillbaka i evigheter, nu kommer en sådan transaktion att behöva rulla tillbaka på alla noder. Uppenbarligen är bästa praxis att minska storleken på en transaktion så mycket som möjligt för att undvika att återkallningar tar timmar att slutföra. En annan nackdel är att, av kraschåterställningsskäl, skrivuppsättningar som skapats från varje fragment lagras i tabellen wsrep_schema.SR på alla noder, vilket typ implementerar dubbelskrivbuffert, vilket ökar belastningen på klustret. Därför bör du noggrant bestämma vilken transaktion som ska replikeras med hjälp av strömmande replikering och, så länge det är möjligt, bör du fortfarande hålla fast vid de bästa metoderna för att ha små, korta transaktioner eller dela upp den stora transaktionen i mindre omgångar.
Backuplås
Slutligen kommer MariaDB-användare att kunna dra nytta av säkerhetskopieringslås för SST. Tanken bakom SST som körs med hjälp av (för MariaDB) mariabackup är att hela datasetet måste överföras i farten med redo-loggar som samlas in i bakgrunden. Sedan måste ett globalt lås skaffas, vilket säkerställer att ingen skrivning kommer att ske, slutpositionen för redo-loggen måste samlas in och lagras. Historiskt sett, för MariaDB, utfördes låsdelen med hjälp av SPOLLBORD MED LÄSLÅS som gjorde sitt jobb men under tung belastning var det ganska svårt att skaffa. Det är också ganska tungt - inte bara transaktioner måste vänta på att låset släpps utan även data måste spolas till disken. Nu, med MariaDB 10.4, kommer det att vara möjligt att använda mindre påträngande BACKUP LOCK, vilket inte kräver att data töms, bara commits kommer att blockeras under låsets varaktighet. Detta borde innebära mindre påträngande SST-operationer, vilket definitivt är fantastiskt att höra. Alla som var tvungna att köra sitt Galera Cluster i nödläge, på en nod, och håller tummarna för att SST inte kommer att påverka klusterverksamheten borde mer än gärna höra om denna förbättring.
Kausala läser från applikationen
Galera 4 introducerade tre nya funktioner som är avsedda att hjälpa till att lägga till stöd för kausala läsningar i applikationerna - WSREP_LAST_WRITTEN_GTID(), som returnerar GTID för den senaste skrivningen gjord av klienten, WSREP_LAST_SEEN_GTID(), som returnerar GTID för den senast observerade skrivtransaktionen av klienten och WSREP_SYNC_WAIT_UPTO_GTID(), som kommer att blockera klienten tills det GTID som skickas till funktionen kommer att begås på noden. Visst, du kan framtvinga kausala läsningar i Galera även nu, men genom att använda dessa funktioner kommer det att vara möjligt att implementera säker läsning efter skrivning i de delar av applikationen där det behövs, utan att behöva göra ändringar i Galera-konfigurationen.
Uppgradering till MariaDB Galera 10.4
Om du vill prova Galera 4 är den tillgänglig i den senaste versionskandidaten för MariaDB 10.4. Enligt MariaDB-dokumentationen finns det för närvarande inget sätt att göra en liveuppgradering av 10.3 Galera till 10.4. Du måste stoppa hela 10.3-klustret, uppgradera det till 10.4 och sedan starta det igen. Detta är en allvarlig blockerare och vi hoppas att denna begränsning kommer att tas bort i en av de kommande versionerna. Det är av yttersta vikt att ha möjligheten till en liveuppgradering och för det måste både MariaDB 10.3 och MariaDB 10.4 samexistera i samma Galera-kluster. Ett annat alternativ, som också kan vara lämpligt, är att ställa in asynkron replikering mellan gamla och nya Galera Cluster.
Vi hoppas verkligen att du gillade den här korta recensionen av funktionerna i MariaDB 10.4 Galera Cluster, vi ser fram emot att se strömmande replikering i riktiga liveproduktionsmiljöer. Vi hoppas också att dessa ändringar kommer att bidra till att öka användningen av Galera ytterligare. När allt kommer omkring löser strömmande replikering många problem som kan hindra människor från att migrera till Galera.