Sådan implementeres MariaDB Cluster 10.5 for høj tilgængelighed

MariaDB Cluster 10.5-implementering er blevet understøttet i ClusterControl siden version 1.8.1.

MariaDB 10.5 er udstyret med:

• Flere detaljerede privilegier

• InnoDB-ydelsesforbedringer

• Fuld GTID-understøttelse af Galera Cluster

• Flere metadata til replikering og binære logfiler

• Flere SQL-syntakssætninger (RETURNING-sætning til INSERT, EXCEPT ALL og INTERSECT ALL, …)

• Performanceskemaopdateringer, der matcher MySQL 5.7

• S3 Storage Engine

Du kan tjekke yderligere på vores tidligere blog 

For flere detaljer om denne særlige versionsudgivelse, tjek hvad der er nyt i MariaDB 10.5? Nogle af de væsentligste ændringer fra version 10.4 til 10.5 omfatter:

• GTID-konsistens 

• Klynge inkonsistens/fejl ved afstemning 

• ikke-blokerende DDL-operationer (kun tilgængelig på virksomhedsversion)

• Sort boks (kun tilgængelig på virksomhedsversion) 

• Opgraderede dets Galera wsrep-bibliotek, som 26.4.6 er den seneste version for

Oprindeligt forventedes XA Transaction Support for denne udgivelse (må ikke forveksles, da XA Transactions understøttes af MariaDB Server, men ikke på Galera Cluster). Men på grund af visse præstationsimplikationer understøtter MariaDB Galera Cluster ikke XA-transaktioner.

I denne blog vil vi diskutere, hvordan man implementerer MariaDB Cluster 10.5 for høj tilgængelighed.

MariaDB-klynge for høj tilgængelighed

MariaDB-klyngen er i bund og grund en Galera-klynge, der bruger MariaDB-implementeringen som databaselag til at interface med InnoDB- eller XtraDB-motoren. MariaDB Galera Cluster er en praktisk talt synkron multi-master klynge til MariaDB. Den er kun tilgængelig på Linux og understøtter XtraDB/InnoDB-lagringsmotorerne (selvom der er eksperimentel understøttelse af MyISAM — se systemvariablen wsrep_replicate_myisam). Når Galera Cluster bruges, kan databaselæsninger og -skrivninger dirigeres til enhver node. Enhver individuel node kan gå tabt uden afbrydelse i driften og uden brug af komplekse failover-procedurer.

Med Galeras karakter tilpasset i MariaDB Cluster er det en høj tilgængelighedsløsning med synkron replikering, failover og resynkronisering. Det giver fordelene ved intet datatab, ingen slaveforsinkelse, læse- og skriveskalerbarhed og høj tilgængelighed i forskellige datacentre.

Implementering af MariaDB Cluster 10.5

MariaDB giver en ligetil og nem opsætning til installation af din MariaDB Cluster 10.5. Den manuelle proces kan være kedelig, men med automatiserede scripts leveret af MariaDB kan repositories konfigureres i overensstemmelse med din måldatabaseversion, OS-type og OS-version.

Til denne øvelse har jeg følgende 3-node Galera Cluster-opsætning med følgende IP-adresser:192.168.40.210, 192.168.40.220, 192.168.40.230.

Konfigurer dit lager

Som tidligere nævnt har MariaDB et script ved navn mariadb_repo_setup, og det er nemt at bruge. Du kan angive målversionen af ​​din database, OS-typen og din OS-version.

For eksempel installerer jeg ved hjælp af EL 8:

curl -LsS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup |  sudo bash -s -- --mariadb-server-version="mariadb-10.5" --os-type=rhel --os-version=8

eller installere det i Ubuntu Focal Fossa,

curl -LsS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup |  sudo bash -s -- --mariadb-server-version="mariadb-10.5" --os-type=ubuntu --os-version=focal

Bemærk, at når du bruger mariadb_repo_setup-scriptet, kræver det pakken apt-transport-https som en afhængighed. Så installer denne pakke først, før du kan drage fordel af mariadb_repo_setup scriptet.

apt update

apt install apt-transport-https

Kør nu kommandoen til dine tre noder i henhold til deres OS. Naturligvis skal MariaDB-versionen være 10.5.

Opsætning af MySQL-konfiguration

Konfigurationsfilen afhænger af dine serverressourcer, type servermiljø og tildelt IP-adresse. Til denne blog kan du bruge denne produktionsklare MariaDB Cluster/PXC-konfigurationsopsætning, som vi brugte til at implementere i vores Percona XtraDB Cluster/MariaDB Cluster-databaser ved hjælp af ClusterControl. Bemærkelsesværdige variabler, som du har brug for eller kan ændres, er følgende:

• innodb_buffer_pool_size — Indstil bufferpuljen fra 70 % - 80 % tilgængeligt RAM på din server

• wsrep_provider — Path of the Galera compiled library. For Enterprise Linux skal stien være  /usr/lib64/galera-4/libgalera_smm.so. Hvorimod Debian/Ubuntu er i /usr/lib/galera/libgalera_smm.so.

• wsrep_node_address — Dette er nodens IP-adresse

• wsrep_sst_method — Enten kan du ændre det, men vi anbefaler, at du bruger mariabackup. Mulige værdier du kan vælge er rsync, mysqldump, xtrabackup, xtrabackup-v2, mariabackup.

• wsrep_cluster_name — Navnet på din MariaDB-klynge. Det skal være identisk med alle dine noder i en enkelt MariaDB-klynge.

• wsrep_cluster_address — Dette indeholder adresserne på dine noder i klyngen. Det skal være en gyldig IP, værtsnavn eller FQDN.

• wsrep_node_name — Navnet på din node. Navnet kan bruges i wsrep_sst_donor som en foretrukken donor. Bemærk, at flere noder i en klynge kan have samme navn.

For at udføre SST kan brugeren og adgangskoden til de følgende sektioner [mysqldump], [xtrabackup] og [mysqld] ændres, hvis du vil. Til denne øvelse, lad os holde det simpelt, og du kan bare lade værdierne være som de er.

Kopiér nu konfigurationsfilen og placer den i /etc/my.cnf. Gør dette på alle dine tre Galera-noder.

Installation af nødvendige pakker

Installer pakkerne til alle tre Galera-noder. Følg kommandoen nedenfor baseret på dit mål OS-miljø.

For RHEL/Rocky/AlmaLinux:

sudo yum install MariaDB-server MariaDB-client galera-4 MariaDB-backup

For Debian/Ubuntu:

sudo apt update

sudo apt-get install mariadb-server galera-4 mariadb-client libmariadb3 mariadb-backup mariadb-common

Når installationen er fuldført, skal du stoppe MariaDB-processen og initialisere klyngen som en enkelt node. Dette skal starte din Galera Cluster. På dette tidspunkt kører jeg det på node 192.168.40.210.

$ /usr/bin/galera_new_cluster

Opret SST/IST-bruger

Opret backup-brugeren, som skal bruges til SST eller IST. Kør kun følgende SQL-sætninger nedenfor på den første node, hvor du har startet klyngen. På dette stadium har jeg udført det i node 192.168.40.210.

CREATE USER [email protected] IDENTIFIED BY 'backuppassword';

GRANT PROCESS, RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'backupuser'@'localhost';

På dette tidspunkt er vi allerede sat op og klar til at forbinde de resterende noder.

Start MariaDB-serveren

Nu har vi allerede sat den første node op. Vi er klar til at forbinde de resterende noder. Du skal blot starte MariaDB-tjenesten. Bare kør kommandoen nedenfor:

systemctl start mariadb

Kør kommandoen for de resterende noder én ad gangen. På dette tidspunkt er alle noder synkroniseret.

Tilføjelse af steroider til din MariaDB Cluster 10.5 for høj tilgængelighed

Sandsynligvis er implementering af MariaDB Cluster 10.5 for høj tilgængelighed muligvis ikke tilstrækkeligt til dine behov i en produktionsopsætning. Tilføjelse af flere steroider, såsom at installere HAProxy sammen med Keepalved for din redundans, vil give mere høj tilgængelighed for dit databasemiljø.

Opsætning af HAProxy og Keepalved for at opnå den ønskede topologi og miljø kan give mere besvær. Du kan dog automatisere dette med ClusterControl. Ved at bruge ClusterControl kan du implementere din MariaDB Cluster 10.5 og tilføje flere løsninger til belastningsbalancering, såsom ProxySQL, MaxScale eller garbd. Du kan tilføje Keepalved til din klynge for at tilføje redundans og auto-failover-løsninger i tilfælde af en katastrofe.

Du kan downloade en gratis prøveversion af ClusterControl, som giver dig mulighed for at implementere disse HA-løsninger og administrere hele din databaseoperation fra en enkelt glasrude. Vi vil gennemgå, hvordan du implementerer din MariaDB 10.5 Cluster med ClusterControl.

Implementering af MariaDB 10.5 Cluster med ClusterControl

Når du har installeret ClusterControl, skal du klikke på ikonet i øverste højre hjørne, og du vil se implementeringsguiden ligesom nedenfor.

Du kan nemt konfigurere det. Bare følg rækken af ​​trin baseret på flowet i brugergrænsefladen.

Implementer HAProxy til belastningsbalancering

På dette tidspunkt vil jeg antage, at du har din MariaDB Cluster 10.5 opsat. Lad os nu implementere HAProxy:

Alternativt kan du gå til Administrer → Load Balancer → HAProxy.

Vælg eller skriv derefter adressen, hvor HAProxy'en skal installeres, og vælg dine Galera-noder, der vil blive overvåget af HAProxy'en. Se eksemplet nedenfor:

Tilføj mindst to implementeringer af HAProxy for at tilføje mere tilgængelighed. Når en af ​​dine HAProxy går ned, vil din applikation dirigeres over til den anden node, der stadig er tilgængelig eller online. Dette er meget vigtigt, især når du håndterer database- eller systemopgraderinger, bortset fra katastrofale eller katastrofale hændelser.

Implementer Keepalived

Du vil bruge den samme proces ovenfor til at implementere Keepalived, som vist nedenfor:

Hvis du bemærkede det, har jeg to HAProxy-forekomster, som jeg vil installere Keepalived for , som skal være til stede i hver node, hvor HAProxy'en kører.

Afslutning af din MariaDB Cluster 10.5 med høj tilgængelighed

Nu hvor vi har alt sat op, burde du have et miljø, der ser sådan ud:

Afslutning

Denne opsætning til din MariaDB 10.5 Cluster giver dig fordelene ved at opnå høj tilgængelighed med flere ni. HAProxy giver dig flere belastningsbalanceringsmuligheder med sin læse- og skriveadskillelse, og Keepalved sikrer, at hvis en af ​​dine HAProxy dør, vil den failover til den næste tilgængelige node. Din applikation vil kun oprette forbindelse til den virtuelle IP-adresse (som følger VRRP) og kræver ikke ekstra konfiguration eller opsætning.

For at tilføje endnu mere fleksibilitet og læse-/skriveadskillelse ved kun at spille i én port, kan du erstatte HAProxy med ProxySQL. Det kan være svært at opnå en perfekt opsætning til høj tilgængelighed, og hver kommer med sine ulemper. Men det vigtigste er, at der opnås lav eller ingen nedetid.

For flere tips om at bygge en meget tilgængelig MariaDB-opsætning, tjek dette stykke om implementering af MariaDB-replikering.

Hvis du ønsker at holde dig opdateret om databasetrends og bedste praksis, kan du abonnere på vores nyhedsbrev og følge os på Twitter og LinkedIn.