Automatiser implementering af din MySQL- eller Postgres-klynge fra backup

ClusterControl 1.7.1 introducerer en ny funktion kaldet Create Cluster from Backup, som giver dig mulighed for at implementere en ny MySQL eller Postgres-baseret klynge og gendanne data på den fra en sikkerhedskopi. Dette blogindlæg viser, hvordan denne nye funktion fungerer, og hvordan denne type automatisering kan levere forbedringer til din infrastrukturdrift.

Introduktion:Opret klynge fra sikkerhedskopi

Sikkerhedskopiering er den mest elskede funktion af vores brugere, og vi har lige løftet den til næste niveau. Denne nye funktionalitet lyder simpel - ClusterControl 1.7.1 er i stand til at implementere en ny klynge fra en eksisterende backup. Der er dog flere procedurer og kontroller involveret for at implementere en produktionskvalitetsklynge direkte fra en backup. Restaurering i sig selv kommer med sine egne udfordringer, såsom:

Fuld eller delvis gendannelseskonsekvenser
Basissikkerhedskopiering og dens trinvise sikkerhedskopieringsbestilling (til trinvis sikkerhedskopiering)
Sikkerhedskopieringsdekryptering (hvis krypteret)
Gendannelsesværktøjsmuligheder
Dekompression (hvis komprimeret)
Sikkerhedskopiering af streaming fra kilden til destinationsserveren
Udnyttelse af diskplads under og efter gendannelsen
Statusrapportering for restaurering

Kombiner ovenstående med kompleksiteten og gentagelsen af databaseklyngeimplementeringsopgaver, du kan spare tid og reducere risikoen ved at køre fejludsatte procedurer. Den sværeste del fra brugerens perspektiv er at vælge, hvilken backup der skal gendannes fra. ClusterControl vil håndtere alle de tunge løft bag scenen og rapportere slutresultatet, når det er færdigt.

Trinnene er grundlæggende enkle:

Konfigurer adgangskodefri SSH fra ClusterControl-noden til de nye servere.
Vælg én logisk sikkerhedskopi fra backuplisten, eller opret en under Sikkerhedskopier -> Opret sikkerhedskopi .
Klik på Gendan -> Opret klynge fra sikkerhedskopi og følg installationsguiden.

Denne funktion er specifikt bygget til MySQL Galera Cluster og PostgreSQL på nuværende tidspunkt. Her er, hvad du vil se i brugergrænsefladen efter at have klikket på "Gendan" på en eksisterende sikkerhedskopi:

Den nederste mulighed er det, vi leder efter. Dernæst er oversigtsdialogen på den valgte backup før installationskonfigurationen:

Dernæst vil den samme databaseklyngeimplementeringsguide for den respektive klynge (MySQL Galera Cluster eller PostgreSQL) blive vist for at konfigurere en ny klynge:

Bemærk, at du skal angive det samme database root/admin brugernavn og adgangskode som det, du har i sikkerhedskopien. Ellers ville implementeringen mislykkes halvvejs ved opstart af den første node. Generelt vil gendannelses- og implementeringsprocedurer ske i følgende rækkefølge:

Installer nødvendig software og afhængigheder på alle databasenoder.
Start den første node.
Stream og gendan backup på den første node (med auto-genstart flag).
Konfigurer og tilføj resten af noderne.

En ny databaseklynge vil blive vist under ClusterControl-klynge-dashboard, når jobbet er fuldført.

Hvad kan du få ud af det?

Der er en række ting, du kan drage fordel af denne funktion, som forklaret i de følgende afsnit.

Test dit datasæt under forskellige forhold

Nogle gange undrer du dig måske over, at den nye databaseversion ville fungere eller fungere for din databasearbejdsbelastning, og at teste den er den eneste måde at vide det. Det er her, denne funktion kommer til nytte. Det giver dig mulighed for at udføre test og benchmarke på mange involverede variabler, der vil påvirke databasens stabilitet eller ydeevne, for eksempel den underliggende hardware, softwareversion, leverandør og database eller applikationsarbejdsbelastninger.

For et simpelt eksempel er der en stor forbedring af DDL-udførelsen mellem MySQL 5.6 og MySQL 5.7. Den følgende DROP-operation på en tabel med 10 millioner rækker beviser det hele:

mysql-5.7> ALTER TABLE sbtest1 DROP COLUMN xx;
Query OK, 0 rows affected (1 min 58.12 sec)

mysql-5.6> ALTER TABLE sbtest1 DROP COLUMN xx;
Query OK, 0 rows affected (2 min 23.74 sec)

At have en anden klynge at sammenligne med giver os faktisk mulighed for at måle forbedringen og retfærdiggøre en migrering.

Databasemigration med logisk backup

Logisk backup som mysqldump og pg_dumpall er den sikreste måde at opgradere, nedgradere eller migrere dine data fra en version eller leverandør til en anden. Alle logiske sikkerhedskopier kan bruges til at udføre databasemigrering. Databaseopgraderingstrinene er grundlæggende enkle:

Opret (eller planlæg) en logisk backup - mysqldump til MySQL eller pg_dumpall til PostgreSQL
Konfigurer adgangskodefri SSH fra ClusterControl node til de nye servere.
Vælg en oprettet logisk sikkerhedskopi fra backuplisten.
Klik på Gendan -> Opret klynge fra sikkerhedskopi og følg installationsguiden.
Bekræft datagendannelsen på den nye klynge.
Peg din applikation til den nye klynge.

Hurtigere samlet klyngendannelsestid

Forestil dig en katastrofal fejl, der forhindrer din klynge i at køre, som for eksempel en centraliseret lagerfejl, der påvirkede alle de virtuelle maskiner, der var forbundet til den, du kunne få en erstatningsklynge næsten med det samme (forudsat at sikkerhedskopieringsfilerne er gemt uden for de mislykkede databasenoder , med angivelse af det åbenlyse). Denne funktion kan automatiseres via s9s klient, hvor du kan udløse et job via kommandolinjegrænsefladen, for eksempel:

$ s9s cluster \
--create \
--cluster-type=postgresql \
--nodes="192.168.0.101?master;192.168.0.102?slave;192.168.0.103?slave" \
--provider-version=11 \
--db-admin=postgres \
--db-admin-passwd='s3cr3tP455' \
--os-user=root \
--os-key-file=/root/.ssh/id_rsa \
--cluster-name="PostgreSQL 9.6 - Test"
--backup-id=214 \
--log

En ting at bemærke, når du bruger denne funktion, er at bruge det samme admin-brugernavn og adgangskode som det, der er gemt i sikkerhedskopien. Også den adgangskodeløse SSH til alle databasenoder skal konfigureres på forhånd. Ellers, hvis du foretrækker at konfigurere det interaktivt, skal du blot bruge web-UI-grænsefladen.

Skaler ud via asynkron replikering

For MySQL Galera Cluster har den nyoprettede klynge mulighed for at blive udskaleret via MySQL asynkron replikering. Lad os sige, at vi allerede har gendannet en ny klynge på kontoret baseret på den seneste backup fra produktionsklyngen i datacentret, og vi vil gerne have, at kontorklyngen fortsætter med at replikere fra produktionsklyngen, som illustreret i følgende diagram:

Du kan derefter konfigurere det asynkrone replikeringslink ved at bruge følgende måde:

Vælg en node i produktionen og aktiver binær logning (hvis deaktiveret). Gå til Noder -> vælg en node -> Nodehandlinger -> Aktiver binær logning.
Aktiver binær logning på alle noder for kontorklynge. Denne handling kræver en rullende genstart, som udføres automatisk, hvis du vælger "Ja" under rullemenuen "Auto-genstart node":

Ellers kan du udføre denne handling uden nedetid ved at bruge Administrer -> Opgrader -> Rullende genstart (eller manuelt genstart én node ad gangen).
Opret en replikeringsbruger på produktionsklyngen ved at bruge Administrer -> Skemaer og brugere -> Brugere -> Opret ny bruger:

Vælg derefter en node, der skal replikeres til masternoden i produktionsklyngen, og opsæt replikeringslinket:

mysql> CHANGE MASTER master_host = 'prod-mysql1', master_user = 'slave', master_password = 'slavepassw0rd', master_auto_position = 1;
mysql> START SLAVE;

Bekræft, om replikeringen kører:
```
mysql> SHOW SLAVE STATUS\G
```
Sørg for, at Slave_IO_Thread og Slave_SQL_thread rapporterer 'Ja'. Kontorets klynge bør begynde at indhente hovedknuden, hvis den halter bagud.

Det var det for nu folkens!