MySQL Galera Cluster 4.0 är det nya barnet i databasblocket med mycket intressanta nya funktioner. För närvarande är det endast tillgängligt som en del av MariaDB 10.4 men i framtiden kommer det att fungera lika bra med MySQL 5.6, 5.7 och 8.0. I det här blogginlägget skulle vi vilja gå igenom några av de nya funktionerna som kom tillsammans med Galera Cluster 4.0.
Galera Cluster Streaming Replication
Den viktigaste nya funktionen i den här utgåvan är strömmande replikering. Hittills har certifieringsprocessen för Galera Cluster fungerat på ett sätt att hela transaktioner måste certifieras efter att de slutförts.
Denna process var inte idealisk i flera scenarier...
- Hotspots i tabeller, rader som ofta uppdateras på flera noder - hundratals snabba transaktioner som körs på flera noder, modifiering av samma uppsättning rader resulterar i frekventa dödlägen och återställning av transaktioner
- Långa transaktioner - om en transaktion tar betydande tid att slutföra, ökar detta allvarligt chanserna att någon annan transaktion, under tiden, på en annan nod, kan ändra några av raderna som också uppdaterades av den långa transaktionen. Detta resulterade i ett dödläge under certifieringen och en av transaktionerna måste rullas tillbaka.
- Stora transaktioner - om en transaktion modifierar ett betydande antal rader, är det troligt att en annan transaktion, samtidigt, på en annan nod, kommer att modifiera en av raderna som redan modifierats av den stora transaktionen. Detta resulterar i ett dödläge under certifieringen och en av transaktionerna måste rullas tillbaka. Utöver detta kommer stora transaktioner att ta ytterligare tid att bearbeta, skickas till alla noder i klustret och certifieras. Det här är inte en idealisk situation eftersom det lägger till fördröjning i åtaganden och saktar ner hela klustret.
Lyckligtvis kan strömmande replikering lösa dessa problem. Den största skillnaden är att certifieringen sker i bitar där det inte finns något behov av att vänta på att hela transaktionen ska slutföras. Som ett resultat, även om en transaktion är stor eller lång, låses majoriteten (eller alla, beroende på inställningarna vi kommer att diskutera om ett ögonblick) av rader på alla noder, vilket hindrar andra frågor från att ändra dem.
MySQL Galera Cluster Streaming Replikeringsalternativ
Det finns två konfigurationsalternativ för strömmande replikering:
wsrep_trx_fragment_size
Detta talar om hur stort ett fragment ska vara (som standard är det satt till 0, vilket betyder att strömmande replikering är inaktiverad)
wsrep_trx_fragment_unit
Detta berättar 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.
Du kan konfigurera Galera 4.0 för att certifiera varje rad som du har ändrat och ta tag i låsen på alla noder medan du gör det. Detta gör strömmande replikering bra på att lösa problem med frekventa dödlägen som före Galera 4.0 var möjliga att lösa endast genom att omdirigera alla skrivningar till en enda nod.
WSREP-tabeller
Galera 4.0 introducerar flera tabeller som hjälper till att övervaka klustrets tillstånd:
- wsrep_cluster
- wsrep_cluster_members
- wsrep_streaming_log
Alla finns i mysql-schemat. wsrep_cluster ger insikt i klustrets tillstånd. wsrep_cluster_members kommer att ge dig information om noderna som är en del av klustret. wsrep_streaming_log hjälper till att spåra tillståndet för streamingreplikeringen.
Kommande funktioner för Galera Cluster
Codership, företaget bakom Galera, är inte klart än. Vi kunde få en förhandstitt på färdplanen från VD, Seppo Jaakola som gavs på Percona Live tidigare i år. Tydligen kommer vi att se funktioner som XA-transaktionsstöd och gcache-kryptering. Det här är riktigt goda nyheter.
Stöd för XA-transaktioner kommer att vara möjligt tack vare strömmande replikering. Kort sagt, XA-transaktioner är de distribuerade transaktionerna som kan köras över flera noder. De använder två-fas commit, vilket kräver att man först skaffar alla nödvändiga lås för att köra transaktionen på alla noder och sedan, när det är gjort, commit ändringarna. I tidigare versioner hade Galera inte möjlighet att låsa resurser på fjärrnoder, med strömmande replikering har detta ändrats.
Gcache är en fil som lagrar skrivuppsättningar. Dess innehåll skickas till joiner-noder som ber om en dataöverföring. Om all data lagras i gcachen kommer joiner att ta emot bara de saknade transaktionerna i processen som kallas Incremental State Transfer (IST). Om gcache inte innehåller alla nödvändiga data, kommer State Snapshot Transfer (SST) att krävas och hela datauppsättningen måste överföras till den anslutande noden.
Gcache innehåller information om de senaste ändringarna, därför är det bra att se dess innehåll krypterat för bättre säkerhet. Med bättre säkerhetsstandarder som införs genom fler och fler regleringar är det avgörande att programvaran blir bättre på att uppnå efterlevnad.
Slutsats
Vi ser definitivt fram emot att se hur Galera Cluster 4.0 kommer att fungera på databaser än MariaDB. Att kunna distribuera MySQL 5.7 eller 8.0 med Galera Cluster kommer att vara riktigt bra. Galera är trots allt en av de mest testade lösningarna för synkron replikering som finns på marknaden.