MariaDB Server erbjuder asynkron och synkron replikering. Den kan ställas in för att ha en replikering med flera källor eller med en multi-master inställning.
För en läs- och skrivintensiv applikation är en master-slave-installation vanlig, men kan skilja sig beroende på den underliggande stack som behövs för att bygga en högtillgänglig databasmiljö.
Att ha en master-slave replikeringsinställning kanske inte uppfyller dina behov, särskilt i en produktionsmiljö. Enbart en MariaDB-server (master-slave setup) räcker inte för att erbjuda hög tillgänglighet eftersom den fortfarande har en enda felpunkt (SPOF).
MariaDB introducerade en företagsprodukt (MariaDB Platform) för att lösa detta problem med hög tillgänglighet. Den innehåller olika komponenter:en företagsversion av MariaDB, MariaDB ColumnStore, MaxScale och lätta MariaDB Connectors. Jämfört med andra leverantörer med samma företagslösningserbjudande kan det vara ett kostnadseffektivt alternativ, men alla behöver inte denna komplexitetsnivå.
I den här bloggen visar vi dig hur du använder MariaDB Server med hjälp av replikering i en högt tillgänglig miljö med möjlighet att välja mellan att använda alla gratisverktyg eller vår kostnadseffektiva hanteringsprogramvara för att köra och övervaka din MariaDB Server-infrastruktur.
MariaDB High-Availability Topology Setup
En vanlig inställning för en master-slav-topologi med MariaDB Server använder asynkron eller synkron tillvägagångssätt med bara en master som tar emot skrivningar, och replikerar sedan dess ändringar till slavarna precis som i diagrammet nedan:
Men återigen, detta har ingen hög tillgänglighet och har en enda punkt av misslyckande. Om mastern dör, fungerar inte längre din applikationsklient. Nu måste vi lägga till i stacken för att ha en auto-failover-mekanism för att undvika SPOF och erbjuder även lastbalansering för att dela läs-skriv och på ett round-robin-sätt. Så för nu kommer vi att ha den typen av topologi,
Nu tjänar denna topologi mer säkerhet när det gäller SPOF. MaxScale kommer att göra läs- och skrivdelningen över databasnoderna från din master mot slavarna. MaxScale gör ett perfekt tillvägagångssätt när det gäller denna typ av installation. MaxScale har också inbyggd autodetektering. Så vilka förändringar som än sker på tillståndet för dina databasnoder, kommer den att upptäcka och agera därefter. MaxScale har möjlighet att fortsätta en failover eller till och med en övergång. För att veta mer om dess failover-mekanism, läs vår tidigare blogg som tar itu med mekanismen för MariaDB MaxScale-failover.
Observera att MaxScale failover-mekanism med MariaDB Monitor också har sina begränsningar. Det är bäst att tillämpa det endast för en master-slave-installation utan överkomplicerad installation. Detta innebär att en master-master-inställning inte stöds. MaxScale har dock fler saker att erbjuda. Den gör inte bara en viss lastbalansering när den utför läs- och skrivdelningar, den har inbyggd SmartRouter som skickar frågan till den mest presterande noden. Även om detta inte lägger till funktionen att vara högst tillgänglig men det hjälper noderna att fastna i trafiken och undvika att vissa databasnoder underpresterar som kan orsaka timeout eller till en helt otillgänglig server orsakad av pågående hög resurskrävande aktivitet .
En sak som en varning för att använda MaxScale, de använder BSL (Business Source License). Du kanske måste granska FAQ innan du använder den här programvaran.
Ett annat alternativ att välja mellan är att använda ett mer bekvämt tillvägagångssätt. Det kan vara kostnadseffektivt för dig att välja att använda ClusterControl och ha proxyservrar i mitten med HaProxy, MaxScale eller ProxySQL, för vilka den senare kan konfigureras till från lättvikts- till en mer produktionsnivåkonfiguration som gör frågedirigering, frågefiltrering, brandvägg eller säkerhet. Se illustrationen nedan:
Nu sitter ClusterControl ovanpå dem. ClusterControl är inställt med hög tillgänglighet, dvs CMON HA. Alternativt kan proxylagret väljas från antingen HaProxy - ett mycket lätt alternativ att välja mellan, MaxScale, som tidigare nämnts, eller ProxySQL som har en mer förfinad uppsättning parametrar om du vill ha mer flexibilitet och konfiguration idealisk för en högskalad produktionsupplägg. ClusterControl kommer att hantera den automatiska upptäckten när det gäller nodernas hälsostatus, speciellt mastern som är huvudnoden för att avgöra om den kräver en failover eller inte. Nu kan detta vara mer självförsörjande men det tillför mer kostnad på grund av ett antal noder som krävs för att implementera den här inställningen och även genom att använda ClusterControl auto-failover som gäller på vår förhands- och företagslicens. Men å andra sidan ger det dig all säkerhet, säkerhet och observerbarhet mot din databasinfrastruktur. Det är faktiskt mer en lågkostnadsföretagsimplementering jämfört med de tillgängliga lösningarna på den globala marknaden.
Distribuera din MariaDB Master-Slave-replikering för hög tillgänglighet
Låt oss anta att du har en befintlig master-slave-installation av MariaDB. För det här exemplet kommer vi att använda ClusterControl med den kostnadsfria community-utgåvan som du kan installera och använda gratis. Det gör bara ditt arbete enkelt och snabbt att ställa in. För att göra detta behöver du bara importera ditt befintliga MariaDB-replikeringskluster. Kolla in vår tidigare blogg om hur du hanterar MariaDB med ClusterControl. För den här bloggen har jag följande inställning initialt som mitt MariaDB-replikeringskluster enligt nedan:
Låt oss nu använda MaxScale här som en alternativ lösning från MariaDB Platform som också erbjuder hög tillgänglighet. För att göra det är det väldigt enkelt att använda med ClusterControl med bara några klick, du kan sedan ställa in din MaxScale som körs ovanpå ditt befintliga MariaDB-replikeringskluster. För att göra det, gå bara till Hantera → Load Balancer → MaxScale, och du kommer att kunna ställa in och tillhandahålla lämpliga värden som visas nedan,
Aktivera eller klicka sedan på kryssrutan för att välja vilka servrar som måste vara läggs till som en del av din MaxScale-övervakning. Se nedan,
Förutsatt att du har mer än en MaxScale-nod att lägga till, upprepa bara samma steg.
Sistligen kommer vi att ställa in Keepalived för att hålla våra MaxScale-noder alltid tillgängliga när det behövs. Det här går väldigt snabbt med bara enkla steg med ClusterControl. Återigen måste du gå till Hantera → Load Balancer men istället väljer du Keepalived,
Som du har märkt har jag placerat min Keepalive tillsammans med MaxScale på samma nod av min slav (192.168.10.30). Medan, å andra sidan, den andra (2:a) Keepalived körs 192.168.10.40 tillsammans med Maxscale på samma värd.
Resultatet av topologin är produktionsklar som kan ge dig frågedirigering, hög tillgänglighet och med auto-failover utrustad med omfattande övervakning och observerbarhet med ClusterControl. Se nedan,
Slutsats
Enbart användning av MariaDB Server-replikering ger dig inte hög tillgänglighet. Att utöka och använda verktyg från tredje part kommer att utrusta dig att ha din databasstack högt tillgänglig genom att inte bara lita på MariaDB-produkter eller till och med använda MariaDB-plattformen.
Det finns sätt att uppnå detta och hantera det så att det blir mer kostnadseffektivt. Ändå är det en enorm skillnad att använda dessa lösningar som finns tillgängliga på marknaden, såsom ClusterControl, eftersom det ger dig snabbhet, mindre krångel, och naturligtvis den ultimata observerbarheten med realtids- och uppdaterade händelser, inte bara hälsan men också de händelser som inträffar i ditt databaskluster.