ClusterControl er et fantastisk værktøj til at implementere og administrere databaseklynger - hvis du er til MySQL, kan du nemt implementere klynger baseret på både traditionel MySQL master-slave replikering, Galera Cluster eller MySQL NDB Cluster. For at opnå høj tilgængelighed er det dog ikke nok at implementere en klynge. Noder kan (og vil højst sandsynligt) gå ned, og dit system skal være i stand til at tilpasse sig disse ændringer.
Denne tilpasning kan ske på forskellige niveauer. Du kan implementere en form for logik i applikationen - det vil kontrollere tilstanden af klynge noder og dirigere trafik til dem, der er tilgængelige på det givne tidspunkt. Du kan også bygge et proxy-lag, som vil implementere høj tilgængelighed i dit system. I dette blogindlæg vil vi gerne dele nogle tips til, hvordan du kan opnå det ved at bruge ClusterControl.
Implementering af HAProxy ved hjælp af ClusterControl
HAProxy er standarden – en af de mest populære proxyer, der bruges i forbindelse med MySQL (men ikke kun, selvfølgelig). ClusterControl understøtter implementering og overvågning af HAProxy-noder. Det hjælper også med at implementere høj tilgængelighed af selve proxyen ved hjælp af keepalived.
Implementeringen er ret enkel - du skal vælge eller udfylde IP-adressen på en vært, hvor HAProxy skal installeres, vælge port, belastningsbalanceringspolitik, beslutte, om ClusterControl skal bruge eksisterende lager eller den seneste kildekode til at implementere HAProxy. Du kan også vælge, hvilke backend-noder du gerne vil have inkluderet i proxy-konfigurationen, og om de skal være aktive eller backup.
Som standard vil HAProxy-instansen, der er implementeret af ClusterControl, fungere på MySQL Cluster (NDB), Galera Cluster, PostgreSQL-streamingreplikering og MySQL-replikering. Til master-slave-replikering kan ClusterControl konfigurere to lyttere, en til skrivebeskyttet og en anden til read-write. Applikationer skal derefter sende læsninger og skrivninger til de respektive porte. For multi-master replikering vil ClusterControl konfigurere standard TCP belastningsbalancering baseret på mindste forbindelsesbalanceringsalgoritme (f.eks. for Galera Cluster, hvor alle noder er skrivbare).
Keepalved bruges til at tilføje høj tilgængelighed til proxy-laget. Når du har mindst to HAProxy-noder i dit system, kan du installere Keepalved fra ClusterControl UI.
Du skal vælge to HAProxy-noder, og de vil blive konfigureret som et aktivt standby-par. En virtuel IP vil blive tildelt den aktive server, og hvis den mislykkes, vil den blive gentildelt til standby-proxyen. På denne måde kan du bare oprette forbindelse til VIP'en, og alle dine forespørgsler vil blive dirigeret til den aktuelt aktive og fungerende HAProxy-node.
Du kan finde flere detaljer i, hvordan de interne konfigurationer er konfigureret ved at læse vores HAProxy-tutorial.
Implementering af ProxySQL ved hjælp af ClusterControl
Mens HAProxy er en bundsolid proxy og meget populært valg, mangler den databasebevidsthed, f.eks. læse-skriveopdeling. Den eneste måde at gøre det på i HAProxy er at oprette to backends og lytte på to porte - en til læsning og en til skrivning. Dette er normalt fint, men det kræver, at du implementerer ændringer i din applikation - applikationen skal forstå, hvad der er en læsning, og hvad der er en skrivning, og derefter dirigere disse forespørgsler til den korrekte port. Det ville være meget nemmere bare at oprette forbindelse til en enkelt port og lade proxyen bestemme, hvad der skal gøres næste gang - dette er noget HAProxy ikke kan gøre, da det, den gør, bare er at dirigere pakker - der udføres ingen pakkeinspektion, og især har den ingen forståelse af MySQL-protokollen.
ProxySQL løser dette problem - den taler MySQL-protokol, og den kan (blandt andet) udføre en læse-skriveopdeling gennem sine kraftfulde forespørgselsregler og dirigere den indkommende MySQL-trafik i henhold til forskellige kriterier. Installation af ProxySQL fra ClusterControl er enkel - du vil gå til sektionen Administrer -> Load Balancer og udfyld fanen "Deploy ProxySQL" med de nødvendige data.
Kort sagt skal vi vælge, hvor ProxySQL skal installeres, hvilken administrationsbruger og adgangskode den skal have, hvilken overvågningsbruger den skal bruge til at oprette forbindelse til MySQL-backends og bekræfte deres status og overvågningstilstand. Fra ClusterControl kan du enten oprette en ny bruger, der skal bruges af applikationen - du kan bestemme over dens navn, adgangskode, adgang til hvilke databaser der tildeles og hvilke MySQL-privilegier den bruger skal have. En sådan bruger vil blive oprettet på både MySQL- og ProxySQL-siden. Anden mulighed, mere velegnet til eksisterende infrastrukturer, er at bruge de eksisterende databasebrugere. Du skal videregive brugernavn og adgangskode, og en sådan bruger oprettes kun på ProxySQL.
Til sidst skal du besvare et spørgsmål:bruger du implicitte transaktioner? Derved forstår vi transaktioner startet ved at køre SET autocommit=0; Hvis du bruger det, vil ClusterControl konfigurere ProxySQL til at sende al trafikken til masteren. Dette er nødvendigt for at sikre, at ProxySQL håndterer transaktioner korrekt i ProxySQL 1.3.x og tidligere. Hvis du ikke bruger SET autocommit=0 til at oprette en ny transaktion, konfigurerer ClusterControl læse/skriveopdeling.
ProxySQL, som enhver proxy, kan blive et enkelt fejlpunkt, og det skal gøres overflødigt for at opnå høj tilgængelighed. Der er et par metoder til at gøre det. En af dem er at samle ProxySQL på webknuderne. Ideen her er, at ProxySQL-processen for det meste vil fungere fint, og årsagen til dens utilgængelighed er, at hele noden gik ned. I sådanne tilfælde, hvis ProxySQL er samlokaliseret med web-noden, er der ikke sket meget skade, fordi den pågældende web-node heller ikke vil være tilgængelig.
En anden metode er at bruge Keepalived på en lignende måde, som vi gjorde i tilfældet med HAProxy.
Du kan finde flere detaljer om, hvordan de interne konfigurationer er konfigureret ved at læse vores ProxySQL-tutorial.