MariaDB Server tilbyder asynkron og synkron replikering. Det kan sættes op til at have en multi-source replikering eller med en multi-master opsætning.
For en læse- og skriveintensiv applikation er en master-slave-opsætning almindelig, men den kan variere baseret på den underliggende stak, der er nødvendig for at bygge et meget tilgængeligt databasemiljø.
At have en master-slave-replikeringsopsætning opfylder muligvis ikke dine behov, især i et produktionsmiljø. En MariaDB-server alene (master-slave-opsætning) er ikke nok til at tilbyde høj tilgængelighed, da den stadig har et enkelt fejlpunkt (SPOF).
MariaDB introducerede et virksomhedsprodukt (MariaDB Platform) for at løse dette problem med høj tilgængelighed. Det inkluderer forskellige komponenter:en virksomhedsversion af MariaDB, MariaDB ColumnStore, MaxScale og lette MariaDB Connectors. Sammenlignet med andre leverandører med den samme virksomhedsløsning, kan det være en omkostningseffektiv løsning, men ikke alle har brug for dette kompleksitetsniveau.
I denne blog viser vi dig, hvordan du bruger MariaDB Server ved hjælp af replikering i et meget tilgængeligt miljø med mulighed for at vælge mellem at bruge alle gratis værktøjer eller vores omkostningseffektive, administrationssoftware til at køre og overvåge din MariaDB Server-infrastruktur.
MariaDB High-Availability Topology Setup
En sædvanlig opsætning af en master-slave-topologi med MariaDB Server bruger asynkron eller synkron tilgang med kun én master, der modtager skrivninger, og replikerer derefter dens ændringer til slaverne ligesom diagrammet nedenfor:
Men igen, dette tjener ikke nogen høj tilgængelighed og har en enkelt fejlpunkt. Hvis masteren dør, fungerer din applikationsklient ikke længere. Nu er vi nødt til at tilføje i stakken for at have en auto-failover-mekanisme for at undgå SPOF og tilbyder også belastningsbalancering til opdeling af læse-skriving og på en round-robin måde. Så indtil videre ender vi med at have den type topologi,
Nu tjener denne topologi mere sikkerhed med hensyn til SPOF. MaxScale vil foretage læse- og skriveopdelingen over databasenoderne fra din master mod slaverne. MaxScale gør en perfekt tilgang, når de håndterer denne type opsætning. MaxScale har også indbygget auto-detektion. Så uanset hvilke ændringer der sker på tilstanden af dine databasenoder, vil den opdage og handle i overensstemmelse hermed. MaxScale har mulighed for at fortsætte en failover eller endda en overgang. For at vide mere om dens failover-mekanisme, læs vores tidligere blog, som tackler mekanismen for MariaDB MaxScale-failover.
Bemærk, at MaxScale failover-mekanisme med MariaDB Monitor også har sine begrænsninger. Det er bedst kun at anvende til en master-slave-opsætning uden overkompliceret opsætning. Det betyder, at en master-master-opsætning ikke understøttes. MaxScale har dog flere ting at byde på. Den laver ikke kun en vis belastningsbalancering, da den udfører læse-skrive-opdelinger, den har indbygget SmartRouter, som sender forespørgslen til den mest effektive node. Selvom dette ikke tilføjer funktionen af at være meget tilgængelig, men det hjælper knudepunkterne med at sidde fast i trafikken og undgår, at visse databasenoder underpræsterer, der kan forårsage timeouts eller til en fuldstændig utilgængelig server forårsaget af igangværende høj ressourcekrævende aktivitet .
En ting som en advarsel ved at bruge MaxScale, de bruger BSL (Business Source License). Du skal muligvis gennemgå ofte stillede spørgsmål, før du bruger denne software.
En anden mulighed at vælge imellem er at bruge en mere bekvem tilgang. Det kan være omkostningseffektivt for dig at vælge at bruge ClusterControl og have proxyer i midten ved hjælp af HaProxy, MaxScale eller ProxySQL, hvor sidstnævnte kan konfigureres til fra letvægts til en mere produktionsniveau konfiguration, der udfører forespørgselsrouting, forespørgselsfiltrering, firewall eller sikkerhed. Se illustrationen nedenfor:
Nu sidder ClusterControl oven på dem. ClusterControl er sat op med en høj tilgængelighed, dvs. CMON HA. Alternativt kan proxy-laget vælges fra enten HaProxy - en meget let mulighed at vælge imellem, MaxScale, som tidligere nævnt, eller ProxySQL, som har et mere raffineret sæt parametre, hvis du ønsker mere fleksibilitet og konfiguration ideel til en højskaleret produktionsopsætning. ClusterControl vil håndtere den automatiske detektion med hensyn til nodernes sundhedsstatus, især masteren, som er hovedknuden til at bestemme, om den kræver en failover eller ej. Nu kan dette være mere selvforsynende, men det tilføjer flere omkostninger på grund af en række noder, der kræves for at implementere denne opsætning og også ved at bruge ClusterControl auto-failover, som gælder på vores forhånds- og virksomhedslicens. Men på den anden side giver det dig al sikkerhed, sikkerhed og observerbarhed i forhold til din databaseinfrastruktur. Det er faktisk mere en lavpris virksomhedsimplementering sammenlignet med de tilgængelige løsninger på det globale marked.
Implementering af din MariaDB Master-Slave-replikering for høj tilgængelighed
Lad os antage, at du har en eksisterende master-slave-opsætning af MariaDB. Til dette eksempel bruger vi ClusterControl ved hjælp af den gratis community-udgave, som du kan installere og bruge gratis. Det gør bare dit arbejde nemt og hurtigt at sætte op. For at gøre dette skal du bare importere din eksisterende MariaDB-replikeringsklynge. Tjek vores tidligere blog om, hvordan du administrerer MariaDB med ClusterControl. Til denne blog har jeg følgende opsætning oprindeligt som min MariaDB-replikeringsklynge som vist nedenfor:
Lad os nu bruge MaxScale her som en alternativ løsning fra MariaDB Platform, som også tilbyder høj tilgængelighed. For at gøre det er det meget nemt at bruge med ClusterControl med blot et par klik, du er derefter i stand til at konfigurere din MaxScale, der kører oven på din eksisterende MariaDB-replikeringsklynge. For at gøre det skal du bare gå til Administrer → Load Balancer → MaxScale, og du vil være i stand til at opsætte og angive de relevante værdier som vist nedenfor,
Så skal du bare aktivere eller klikke på afkrydsningsfeltet for at vælge, hvilke servere der skal være tilføjet som en del af din MaxScale-overvågning. Se nedenfor,
Forudsat at du har mere end én MaxScale-node at tilføje, skal du blot gentage samme trin.
Til sidst sætter vi Keepalived op for at holde vores MaxScale-noder altid tilgængelige, når det er nødvendigt. Dette er bare meget hurtigt med blot enkle trin ved hjælp af ClusterControl. Igen skal du gå til Administrer → Load Balancer, men i stedet skal du vælge Keepalived,
Som du har bemærket, har jeg placeret min Keepalived sammen med MaxScale på samme knudepunkt af min slave (192.168.10.30). Hvorimod den anden (2.) Keepalived kører på 192.168.10.40 sammen med Maxscale på samme vært.
Resultatet af topologien er produktionsklar, som kan give dig forespørgselsruting, høj tilgængelighed og auto-failover udstyret med omfattende overvågning og observerbarhed ved hjælp af ClusterControl. Se nedenfor,
Konklusion
Brug af MariaDB Server-replikering alene giver dig ikke høj tilgængelighed. Udvidelse og brug af tredjepartsværktøjer vil udstyre dig med at have din databasestak meget tilgængelig ved ikke kun at stole på MariaDB-produkter eller endda bruge MariaDB Platform.
Der er måder at opnå dette på og administrere det til at være mere omkostningseffektivt. Alligevel er der en enorm forskel på at benytte disse løsninger, der er tilgængelige på markedet, såsom ClusterControl, da det giver dig hastighed, mindre besvær, og selvfølgelig den ultimative observerbarhed med real-time og opdaterede begivenheder, ikke kun sundheden men også de hændelser, der forekommer i din databaseklynge.