Valg af din HA-topologi
Der er forskellige måder at bevare høj tilgængelighed med databaser. Du kan bruge virtuelle IP'er (VRRP) til at administrere værtstilgængelighed, du kan bruge ressourceadministratorer som Zookeeper og Etcd til at (om)konfigurere dine applikationer eller bruge belastningsbalancere/proxyer til at fordele arbejdsbyrden over alle tilgængelige værter.
De virtuelle IP'er har brug for enten et program til at administrere dem (MHA, Orchestrator), noget scripting (Keepalived, Pacemaker/Corosync) eller en ingeniør til manuelt at fejle, og beslutningstagningen i processen kan blive kompleks. Virtual IP failover er en ligetil og enkel proces ved at fjerne IP-adressen fra én vært, tildele den til en anden og bruge arping til at sende et gratis ARP-svar. I teorien kan en virtuel IP flyttes på et sekund, men det vil tage et par sekunder, før failover-administrationsapplikationen er sikker på, at værten har fejlet og handler i overensstemmelse hermed. I virkeligheden burde dette være et sted mellem 10 og 30 sekunder. En anden begrænsning ved virtuelle IP'er er, at nogle cloud-udbydere ikke tillader dig at administrere dine egne virtuelle IP'er eller overhovedet tildele dem. Google tillader f.eks. dig ikke at gøre det på deres computerknudepunkter.
Ressourceadministratorer som Zookeeper og Etcd kan overvåge dine databaser og (gen)konfigurere dine applikationer, når en vært fejler, eller en slave bliver forfremmet til master. Generelt er dette en god idé, men at implementere dine kontroller med Zookeeper og Etcd er en kompleks opgave.
En load balancer eller proxy vil sidde mellem applikationen og databaseværten og arbejde transparent, som om klienten ville oprette forbindelse til databaseværten direkte. Ligesom med Virtual IP og ressourcemanagere skal load balancererne og proxyerne også overvåge værterne og omdirigere trafikken, hvis en vært er nede. ClusterControl understøtter to proxyer:HAProxy og ProxySQL, og begge understøttes til MySQL master-slave replikering og Galera cluster. HAProxy og ProxySQL har begge deres egne use cases, vi vil også beskrive dem i dette indlæg.
Hvorfor har du brug for en Load Balancer?
I teorien behøver du ikke en load balancer, men i praksis vil du foretrække en. Vi forklarer hvorfor.
Hvis du har opsat virtuelle IP-adresser, skal du blot pege din ansøgning til den korrekte (virtuelle) IP-adresse, og alt skulle være i orden, hvad angår forbindelsen. Men antag, at du har skaleret antallet af læste replikaer ud, vil du måske også angive virtuelle IP'er for hver af disse læste replikaer på grund af vedligeholdelses- eller tilgængelighedsårsager. Dette kan blive en meget stor pulje af virtuelle IP'er, som du skal administrere. Hvis en af disse læste replikaer havde en fejl, skal du gentildele den virtuelle IP til en anden vært, ellers vil din applikation oprette forbindelse til enten en vært, der er nede, eller i værste fald en server med forældede data. Det er derfor nødvendigt at bevare replikeringstilstanden til den applikation, der administrerer de virtuelle IP'er.
Også for Galera er der en lignende udfordring:du kan i teorien tilføje så mange værter, som du vil, til din applikationskonfiguration og vælge en tilfældigt. Det samme problem opstår, når denne vært er nede:du kan ende med at oprette forbindelse til en utilgængelig vært. Brug af alle værter til både læsning og skrivning kan også forårsage rollbacks på grund af den optimistiske låsning i Galera. Hvis to forbindelser forsøger at skrive til den samme række på samme tid, vil den ene af dem modtage en tilbageføring. Hvis din arbejdsbyrde har sådanne samtidige opdateringer, anbefales det kun at bruge én node i Galera at skrive til. Derfor vil du have en manager, der holder styr på den interne tilstand af din databaseklynge.
Både HAProxy og ProxySQL vil tilbyde dig funktionaliteten til at overvåge MySQL/MariaDB-databaseværterne og holde status for din klynge og dens topologi. For replikeringsopsætninger, hvis en slave-replika er nede, kan både HAProxy og ProxySQL omfordele forbindelserne til en anden vært. Men hvis en replikeringsmaster er nede, vil HAProxy afvise forbindelsen, og ProxySQL vil give en ordentlig fejl tilbage til klienten. For Galera-opsætninger kan begge belastningsbalancere vælge en masterknude fra Galera-klyngen og kun sende skriveoperationerne til den specifikke node.
På overfladen kan HAProxy og ProxySQL synes at være lignende løsninger, men de adskiller sig meget i funktioner og måden, de distribuerer forbindelser og forespørgsler på. HAProxy understøtter en række balanceringsalgoritmer som mindste forbindelser, kilde, tilfældig og round-robin, mens ProxySQL distribuerer forbindelser ved hjælp af den vægtbaserede round-robin-algoritme (ligevægt betyder lige fordeling). Da ProxySQL er en intelligent proxy, er den databasebevidst og er også i stand til at analysere dine forespørgsler. ProxySQL er i stand til at lave læse/skrive opdeling baseret på forespørgselsregler, hvor du kan videresende forespørgslerne til de udpegede slaver eller master i din klynge. ProxySQL inkluderer yderligere funktionalitet som forespørgselsomskrivning, caching og forespørgselsfirewall med real-time, dybdegående statistikgenerering om arbejdsbyrden.
Det burde være nok baggrundsinformation om dette emne, så lad os se, hvordan du kan implementere både belastningsbalancere til MySQL-replikering og Galera-topologier.
Implementering af HAProxy
Det er nemt at bruge ClusterControl til at implementere HAProxy på en Galera-klynge:Gå til den relevante klynge og vælg "Tilføj belastningsbalancer":
Og du vil være i stand til at implementere en HAProxy-forekomst ved at tilføje værtsadressen og vælge de serverforekomster, du ønsker at inkludere i konfigurationen:
Som standard vil HAProxy-forekomsten være konfigureret til at sende forbindelser til de serverforekomster, der modtager det mindste antal forbindelser, men du kan ændre denne politik til enten round robin eller kilde.
Under avancerede indstillinger kan du indstille timeouts, maksimalt antal forbindelser og endda sikre proxyen ved at hvidliste et IP-område for forbindelserne.
Under fanen noder i den klynge vil HAProxy-knuden vises:
Nu er din Galera-klynge også tilgængelig via den nyligt implementerede HAProxy-node på port 3307. Glem ikke at GIVE din applikationsadgang fra HAProxy IP'en, da trafikken nu kommer fra proxyen i stedet for applikationsværterne. Husk også at pege din applikationsforbindelse til HAProxy-noden.
Antag nu, at den ene serverforekomst ville gå ned, vil HAProxy bemærke dette inden for et par sekunder og stoppe med at sende trafik til denne forekomst:
De to andre noder er stadig i orden og vil blive ved med at modtage trafik. Dette bevarer klyngen meget tilgængelig, uden at klienten overhovedet bemærker forskellen.
Implementering af en sekundær HAProxy-node
Nu hvor vi har flyttet ansvaret for at bevare høj tilgængelighed over databaseforbindelserne fra klienten til HAProxy, hvad nu hvis proxynoden dør? Svaret er at oprette en anden HAProxy-instans og bruge en virtuel IP styret af Keepalived som vist i dette diagram:
Fordelen i forhold til at bruge virtuelle IP'er på databasenoderne er, at logikken for MySQL er på proxy-niveau, og failover for proxyerne er enkel.
Så lad os implementere en sekundær HAProxy-node:
Efter at vi har installeret en sekundær HAProxy-node, skal vi tilføje Keepalved:
Og efter at Keepalved er blevet tilføjet, vil din nodeoversigt se sådan ud:
Så nu, i stedet for at pege dine applikationsforbindelser direkte til HAProxy-noden, skal du i stedet pege dem til den virtuelle IP.
I eksemplet her brugte vi separate værter til at køre HAProxy på, men du kan også nemt tilføje dem til eksisterende serverforekomster. HAProxy medfører ikke meget overhead, selvom du skal huske på, at i tilfælde af en serverfejl, vil du miste både databasenoden og proxyen.
Implementering af ProxySQL
Implementering af ProxySQL til din klynge foregår på samme måde som HAProxy:"Tilføj Load Balancer" i klyngelisten under fanen ProxySQL.
I installationsguiden skal du angive, hvor ProxySQL skal installeres, administrationsbrugeren/adgangskoden, overvågningsbrugeren/adgangskoden for at oprette forbindelse til MySQL-backends. Fra ClusterControl kan du enten oprette en ny bruger, der skal bruges af applikationen (brugeren bliver oprettet på både MySQL og ProxySQL) eller bruge de eksisterende databasebrugere (brugeren oprettes kun på ProxySQL). Indstil, om du bruger implicitte transaktioner eller ej. Grundlæggende, hvis du ikke bruger SET autocommit=0 til at oprette en ny transaktion, vil ClusterControl konfigurere læse/skriveopdeling.
Efter at ProxySQL er blevet implementeret, vil den være tilgængelig under fanen Noder:
Åbning af ProxySQL-nodeoversigten vil præsentere dig for ProxySQL-overvågnings- og administrationsgrænsefladen, så der er ingen grund til at logge ind på ProxySQL på noden længere. ClusterControl dækker det meste af ProxySQL vigtige statistikker som hukommelsesudnyttelse, forespørgselscache, forespørgselsprocessor og så videre, såvel som andre målinger som værtsgrupper, backend-servere, forespørgselsregelhits, topforespørgsler og ProxySQL-variabler. I ProxySQL-administrationsaspektet kan du administrere forespørgselsreglerne, backend-servere, brugere, konfiguration og planlægger direkte fra brugergrænsefladen.
Tjek vores ProxySQL-vejledningsside, som dækker udførligt om, hvordan du udfører databasebelastningsbalancering for MySQL og MariaDB med ProxySQL.
Implementering af Garbd
Galera implementerer en kvorum-baseret algoritme til at vælge en primær komponent, hvorigennem den håndhæver konsistens. Den primære komponent skal have et flertal af stemmer (50 % + 1 node), så i et 2 node-system ville der ikke være flertal, hvilket resulterer i split hjerne. Heldigvis er det muligt at tilføje en garbd (Galera Arbitrator Daemon), som er en letvægts statsløs dæmon, der kan fungere som den ulige node. Den ekstra fordel ved at tilføje Galera Arbitrator er, at du nu kun kan klare dig med to noder i din klynge.
Hvis ClusterControl registrerer, at din Galera-klynge består af et lige antal noder, får du advarslen/rådgivningen fra ClusterControl om at udvide klyngen til et ulige antal noder:
Vælg klogt værten at implementere garbd på, da den vil modtage alle replikerede data. Sørg for, at netværket kan håndtere trafikken og er sikkert nok. Du kan vælge en af HAProxy- eller ProxySQL-værterne at installere garbd på, som i eksemplet nedenfor:
Bemærk, at fra og med ClusterControl 1.5.1, kan garbd ikke installeres på den samme vært som ClusterControl på grund af risikoen for pakkekonflikter.
Når du har installeret garbd, vil du se det vises ved siden af dine to Galera-noder:
Sidste tanker
Vi viste dig, hvordan du gør dine MySQL master-slave og Galera cluster opsætninger mere robuste og bevarer høj tilgængelighed ved hjælp af HAProxy og ProxySQL. Garbd er også en god dæmon, der kan gemme den ekstra tredje node i din Galera-klynge.
Dette afslutter implementeringssiden af ClusterControl. I vores næste blog vil vi vise dig, hvordan du integrerer ClusterControl i din organisation ved at bruge grupper og tildele bestemte roller til brugere.