Det är mycket vanligt att se databaser fördelade över flera geografiska platser. Ett scenario för att göra den här typen av inställningar är för återställning efter katastrof, där ditt standby-datacenter finns på en annan plats än ditt huvuddatacenter. Det kan lika gärna krävas så att databaserna ligger närmare användarna.
Den största utmaningen för att uppnå denna inställning är att designa databasen på ett sätt som minskar risken för problem relaterade till nätverkspartitioneringen.
MariaDB Cluster kan vara ett bra val för att bygga en sådan miljö av flera skäl. Vi skulle vilja diskutera dem här och även prata lite om hur en sådan miljö kan se ut.
Varför använda MariaDB Cluster för geodistribuerade miljöer?
Första anledningen är att MariaDB Cluster kan stödja flera skribenter. Detta gör skrivdirigeringen lättare att designa - du skriver bara till de lokala MariaDB-noderna. Givet synkron replikering påverkar latensen naturligtvis skrivprestandan och du kan se att dina skrivningar blir långsammare om du sprider ditt kluster för långt geografiskt. När allt kommer omkring kan du inte ignorera fysikens lagar och de säger, åtminstone nu, att även ljusets hastighet i fiberanslutningar är begränsad. Alla routrar som läggs till kommer också att öka latensen även om det bara är ett par millisekunder.
För det andra, fördröjningshantering i MariaDB Cluster. Asynkron replikering är föremål för replikeringsfördröjning - slavar kanske inte är uppdaterade med data om de kämpar för att tillämpa alla ändringar i tid. I MariaDB Cluster är detta annorlunda - flödeskontroll är en mekanism som är avsedd att hålla klustret synkroniserat. Tja, nästan - i vissa kantfall kan du fortfarande observera eftersläpning. Vi pratar här om, vanligtvis, millisekunder, ett par sekunder som mest medan det är gränsen i den asynkrona replikeringshimlen.
Tredje, segment. Som standard använder MariaDB Cluster all till all kommunikation och varje skrivuppsättning skickas av noden till alla andra noder i klustret. Detta beteende kan ändras med hjälp av segment. Segment tillåter användare att dela upp MariaDB-kluster i flera delar. Varje segment kan innehålla flera noder och det väljer en av dem som en relänod. Sådana noder tar emot skrivuppsättningar från andra segment och omfördelar dem över MariaDB-noder lokalt för segmentet. Som ett resultat, som du kan se i diagrammet ovan, är det möjligt att minska replikeringstrafiken som går över WAN tre gånger - bara två "repliker" av replikeringsströmmen skickas över WAN:en per datacenter jämfört med en per slav i asynkron replikering.
Slutligen, där MariaDB Cluster verkligen lyser är hanteringen av nätverkspartitioneringen. MariaDB Cluster övervakar ständigt tillståndet för noderna i klustret. Varje nod försöker ansluta till sina kamrater och byta tillstånd för klustret. Om en delmängd av noder inte kan nås försöker MariaDB vidarebefordra kommunikationen så om det finns ett sätt att nå dessa noder kommer de att nås.
Ett exempel kan ses i diagrammet ovan:DC 1 förlorade anslutningen med DC2 men DC2 och DC3 kan ansluta. I det här fallet kommer en av noderna i DC3 att användas för att vidarebefordra data från DC1 till DC2 för att säkerställa att kommunikationen inom kluster kan upprätthållas.
MariaDB kan vidta åtgärder baserat på klustrets tillstånd. Den implementerar kvorum - majoriteten av noderna måste vara tillgängliga för att klustret ska kunna fungera. Om noden kopplas bort från klustret och inte kan nå någon annan nod, kommer den att sluta fungera.
Som kan ses i diagrammet ovan sker en partiell förlust av nätverkskommunikationen i DC1 och den berörda noden tas bort från klustret, vilket säkerställer att applikationen inte kommer åt föråldrad data.
Detta är också sant i en större skala. DC1 fick all kommunikation avbruten. Som ett resultat har hela datacentret tagits bort från klustret och ingen av dess noder kommer att betjäna trafiken. Resten av klustret behöll majoriteten (6 av 9 noder är tillgängliga) och det omkonfigurerade sig för att behålla anslutningen mellan DC 2 och DC3. I diagrammet ovan antog vi att skribenten träffar noden i DC2, men kom ihåg att MariaDB kan köras med flera skribenter.
Designa geografiskt distribuerat MariaDB-kluster
Vi gick igenom några av funktionerna som gör MariaDB Cluster till en bra passform för geodistribuerade miljöer, låt oss nu fokusera lite på designen. Låt oss i början förklara vilken miljö vi arbetar med. Vi kommer att använda tre fjärrdatacenter, anslutna via Wide Area Network (WAN). Varje datacenter kommer att ta emot skrivningar från lokala applikationsservrar. Läsning kommer också att vara endast lokal. Detta är avsett att undvika onödig trafik som korsar WAN.
För att göra den här bloggen mindre komplicerad kommer vi inte att gå in på detaljer om hur anslutningen ska se ut. Vi antar någon form av en korrekt konfigurerad, säker anslutning mellan alla datacenter. VPN eller andra verktyg kan användas för att implementera det.
Vi kommer att använda MaxScale som en lastbalanserare. MaxScale kommer att distribueras lokalt i varje datacenter. Det kommer också att dirigera trafik endast till de lokala noderna. Fjärrnoder kan alltid läggas till manuellt och vi kommer att förklara fall där detta kan vara en bra lösning. Applikationer kan konfigureras för att ansluta till en av de lokala MaxScale-noderna med hjälp av en round-robin-algoritm. Vi kan lika väl använda Keepalved och Virtual IP för att dirigera trafiken mot den enda MaxScale-noden, så länge som en enda MaxScale-nod skulle kunna hantera all trafik.
En annan möjlig lösning är att samlokalisera MaxScale med applikationsnoder och konfigurera applikationen för att ansluta till proxyn på den lokala värden. Detta tillvägagångssätt fungerar ganska bra under antagandet att det är osannolikt att MaxScale inte kommer att vara tillgänglig men applikationen skulle fungera ok på samma nod. Det vi ser är vanligtvis nodfel eller nätverksfel, vilket skulle påverka både MaxScale och applikationen samtidigt.
Diagrammet ovan visar versionen av miljön, där MaxScale bildar proxyfarmar - Alla proxynoder med samma konfiguration, belastningsbalanserade med Keepalved, eller helt enkelt round robin från applikationen över alla MaxScale-noder. MaxScale är konfigurerad för att fördela arbetsbelastningen över alla MariaDB-noder i det lokala datacentret. En av dessa noder skulle väljas som en nod att skicka skrivningarna till medan SELECT:er skulle distribueras över alla noder. Att ha en dedikerad skribentnod i ett datacenter hjälper till att minska antalet möjliga certifieringskonflikter, vilket vanligtvis leder till bättre prestanda. För att minska detta ytterligare skulle vi behöva börja skicka trafiken över WAN-anslutningen, vilket inte är idealiskt eftersom bandbreddsutnyttjandet skulle öka avsevärt. Just nu, med segment på plats, skickas bara två kopior av skrivuppsättningen över datacenter - en per DC.
Slutsats
Som du kan se kan MariaDB Cluster enkelt användas för att skapa geodistribuerade kluster som kan fungera även över hela världen. Den begränsande faktorn kommer att vara nätverkslatens. Om den är för hög kan du behöva överväga att använda separata MariaDB-kluster anslutna med asynkron replikering.