Sådan sikkerhedskopieres og gendannes ClusterControl

ClusterControl 1.7.1 introducerede en ny funktion, som giver dig mulighed for at sikkerhedskopiere din ClusterControl-server og gendanne den (sammen med metadata om dine administrerede databaser) på en anden server. Den sikkerhedskopierer ClusterControl-applikationen såvel som alle dens konfigurationsdata. At migrere ClusterControl til en ny server plejede at være en smerte, men ikke længere.

Dette blogindlæg leder dig gennem denne nye funktion.

Vi vil migrere ClusterControl fra en server til en anden og bevarer alle konfigurationer og indstillinger.

Vi vil også vise dig, hvordan du overfører administrationen af ​​en klynge fra en ClusterControl-instans til en anden.

Vores eksempelarkitektur startede med to produktionsklynger (vist på skærmbilledet nedenfor):

• Klynge ID 1:3 Galera noder (PXC) + 1 HAProxy + 1 ProxySQL (5 noder)
• Klynge-id 2:1 MySQL-master + 2 MySQL-slaver + 1 ProxySQL (4 noder)

Introduktion

ClusterControl CLI (s9s) er et kommandolinje-interfaceværktøj til at interagere, kontrollere og administrere databaseklynger ved hjælp af ClusterControl-platformen. Fra version 1.4.1 vil installationsscriptet automatisk installere denne pakke på ClusterControl-noden.

Der er grundlæggende 4 nye muligheder introduceret under kommandoen "s9s backup", som kan bruges til at nå vores mål:

Dette blogindlæg vil dække eksempler på brugssager om, hvordan man bruger disse muligheder. I øjeblikket er de i udgivelseskandidatstadiet og kun tilgængelige via ClusterControl CLI-værktøjet.

Sikkerhedskopiering af ClusterControl

For at gøre dette skal ClusterControl-serveren være mindst på v1.7.1 og nyere. For at sikkerhedskopiere ClusterControl-controlleren skal du blot køre følgende kommando på ClusterControl-noden som root-bruger (eller med sudo):

$ s9s backup \
--save-controller \
--backup-directory=$HOME/ccbackup \
--output-file=controller.tar.gz \
--log

--output-filen skal være et filnavn eller en fysisk sti (hvis du vil udelade --backup-directory flag), og filen må ikke eksistere på forhånd. ClusterControl erstatter ikke outputfilen, hvis den allerede eksisterer. Ved at specificere --log, vil det vente, indtil jobbet er udført, og jobloggene vil blive vist i terminalen. De samme logfiler kan tilgås via ClusterControl UI under Aktivitet -> Jobs -> Gem controller :

Jobbet 'Save Controller' udfører grundlæggende følgende procedurer:

1. Hent controller-konfigurationen og eksporter den til JSON
2. Eksporter CMON-database som MySQL-dumpfil
3. For hver databaseklynge:
   1. Hent klyngekonfigurationen og eksporter den til JSON

I outputtet kan du bemærke, at det fundne job er N + 1 klynge, for eksempel "Fundet 3 klynge(r) at gemme", selvom vi kun har to databaseklynger. Dette inkluderer klynge ID 0, som har særlig betydning i ClusterControl som den globale initialiserede klynge. Det hører dog ikke til CmonCluster-komponenten, som er databaseklyngen under ClusterControl-styring.

Gendannelse af ClusterControl til en ny ClusterControl-server

Hvis ClusterControl allerede er installeret på den nye server, vil vi gerne migrere databaseklyngerne for at blive administreret af den nye server. Følgende diagram illustrerer vores migreringsøvelse:

Overfør først sikkerhedskopien fra den gamle server til den nye server:

$ scp $HOME/ccbackup/controller.tar.gz 192.168.0.190:~

Før vi udfører gendannelsen, skal vi konfigurere adgangskodefri SSH til alle noder fra den nye ClusterControl-server:

$ ssh-copy-id 192.168.0.11 #proxysql cluster 1
$ ssh-copy-id 192.168.0.12 #proxysql cluster 1
$ ssh-copy-id 192.168.0.21 #pxc cluster 1
$ ssh-copy-id 192.168.0.22 #pxc cluster 1
$ ssh-copy-id 192.168.0.23 #pxc cluster 1
$ ssh-copy-id 192.168.0.30 #proxysql cluster 2
$ ssh-copy-id 192.168.0.31 #mysql cluster 2
$ ssh-copy-id 192.168.0.32 #mysql cluster 2
$ ssh-copy-id 192.168.0.33 #mysql cluster 2

Udfør derefter gendannelsen på den nye server:

$ s9s backup \
--restore-controller \
--input-file=$HOME/controller.tar.gz \
--debug \
--log

Så skal vi synkronisere klyngen i brugergrænsefladen ved at gå til Globale indstillinger -> Klyngeregistreringer -> Synkroniser klynge . Hvis du derefter går tilbage til ClusterControl-hoveddashboardet, vil du se følgende:

Gå ikke i panik. Den nye ClusterControl UI er ikke i stand til at hente overvågnings- og administrationsdata på grund af forkert RPC API-token. Vi skal bare opdatere det i overensstemmelse hermed. Hent først værdien rpc_key for de respektive klynger:

$ cat /etc/cmon.d/cmon_*.cnf | egrep 'cluster_id|rpc_key'
cluster_id=1
rpc_key=8fgkzdW8gAm2pL4L
cluster_id=2
rpc_key=tAnvKME53N1n8vCC

I brugergrænsefladen skal du klikke på linket "her" ved derefter på linjen "Skift RPC API-token her". Det vil dukke op i følgende dialogboks:

Indsæt den respektive rpc_key-værdi i tekstfeltet, og klik på Gem. Gentag for den næste klynge. Vent et øjeblik, og klyngelisten bør opdateres automatisk.

Det sidste trin er at rette MySQL cmon-brugerrettighederne for de nye ClusterControl IP-adresseændringer, 192.168.0.190. Log ind på en af ​​PXC-knuderne og kør følgende:

$ mysql -uroot -p -e 'GRANT ALL PRIVILEGES ON *.* TO [email protected]"192.168.0.190" IDENTIFIED BY "<password>" WITH GRANT OPTION';

** Erstat med identisk cmon MySQL-adgangskode som i mysql_password-værdien inde i /etc/cmon.cnf. Gentag det samme trin på den anden klynge, MySQL-replikering, men udfør det kun én gang på masternoden.

Når privilegiet er sat op, bør du se klyngelisten er i grønt, svarende til den gamle:

Det er værd at nævne, at som standard vil ClusterControl deaktivere klyngens automatiske gendannelse (som du kan se det røde ikon ved siden af ​​ordet 'Cluster') for at undgå racetilstand med en anden ClusterControl-instans. Det anbefales at aktivere denne funktion (ved at klikke på ikonet til grønt), når den gamle server er blevet taget ud af drift.

Vores migrering er nu afsluttet. Alle konfigurationer og indstillinger fra den gamle server bevares og overføres til den nye server.

Migrering af administrationen af ​​en klynge til en anden ClusterControl-server

Sikkerhedskopiering af klyngeoplysninger

Dette handler om at sikkerhedskopiere klyngemetadata og information, så vi kan overføre dem til en anden ClusterControl-server, også kendt som delvis backup. Ellers skal vi udføre "Importér eksisterende server/klynge" for at genimportere dem til den nye ClusterControl, hvilket betyder, at du ville miste overvågningsdataene fra den gamle server. Hvis du har belastningsbalancere eller asynkrone slave-instanser, skal dette importeres, når klyngen er importeret, én node ad gangen. Så det er lidt bøvlet, hvis du har et komplet sæt af produktionssetup.

Klynge-"manager"-migreringsøvelsen er illustreret i følgende diagram:

Grundlæggende ønsker vi at migrere vores MySQL-replikering (cluster-id:2) ud for at blive administreret af en anden ClusterControl-instans. Vi kommer til at bruge --save-cluster-info og --restore-cluster-info muligheder for denne. Indstillingen --save-cluster-info vil eksportere den tilsvarende klyngeinformation for at blive gemt et andet sted. Lad os eksportere vores MySQL-replikeringsklynge (klynge-id:2). På den aktuelle ClusterControl-server skal du gøre:

$ s9s backup \
--save-cluster-info \
--cluster-id=2 \
--backup-directory=$HOME/ccbackup \
--output-file=cc-replication-2.tar.gz \
--log

Du vil se en masse nye linjer udskrevet i terminalen, hvilket indikerer, at backupjobbet kører (outputtet er også tilgængeligt via ClusterControl -> Aktivitet -> Jobs ):

Hvis du ser nærmere på jobloggene, vil du bemærke, at jobbet forsøgte at eksportere alle relaterede oplysninger og metadata til klynge-ID 2. Outputtet gemmes som en komprimeret fil og er placeret under stien, som vi har angivet under brug af --backup -katalogflag. Hvis dette flag ignoreres, vil ClusterControl gemme outputtet til standard backup-biblioteket, som er SSH-brugerens hjemmebibliotek, under $HOME/backups.

Gendannelse af klyngeoplysninger

De trin, der er forklaret her, svarer til gendannelsestrinnene for ClusterControl fuld sikkerhedskopiering. Overfør sikkerhedskopien fra den aktuelle server til den anden ClusterControl-server:

$ scp $HOME/ccbackup/cc-replication-2.tar.gz 192.168.0.190:~

Før vi udfører gendannelsen, skal vi konfigurere adgangskodefri SSH til alle noder fra den nye ClusterControl-server:

$ ssh-copy-id 192.168.0.30 #proxysql cluster 2
$ ssh-copy-id 192.168.0.31 #mysql cluster 2
$ ssh-copy-id 192.168.0.32 #mysql cluster 2
$ ssh-copy-id 192.168.0.33 #mysql cluster 2
$ ssh-copy-id 192.168.0.19 #prometheus cluster 2

Udfør derefter klyngeinformationsgendannelsen for vores MySQL-replikering på den nye server:

$ s9s backup \
--restore-cluster-info \
--input-file=$HOME/cc-replication-2.tar.gz \
--log

Du kan bekræfte fremskridtene under Aktivitet -> Jobs -> Gendan klynge :

Hvis du ser nærmere på jobmeddelelserne, kan du se, at ClusterControl automatisk gentildeler klynge-id til 1 på denne nye instans (det var klynge-ID 2 på den gamle instans).

Synkroniser derefter klyngen i brugergrænsefladen ved at gå til Globale indstillinger -> Klyngeregistreringer -> Synkroniser klynge . Hvis du går tilbage til ClusterControl-hoveddashboardet, vil du se følgende:

Fejlen betyder, at den nye ClusterControl UI ikke er i stand til at hente overvågnings- og administrationsdata på grund af forkert RPC API-token. Vi skal bare opdatere det i overensstemmelse hermed. For det første skal du hente rpc_key-værdien for vores klynge-ID 1:

$ cat /etc/cmon.d/cmon_1.cnf | egrep 'cluster_id|rpc_key'
cluster_id=1
rpc_key=tAnvKME53N1n8vCC

I brugergrænsefladen skal du klikke på linket "her" ved derefter på linjen "Skift RPC API-token her". Det vil dukke op i følgende dialogboks:

Indsæt den respektive rpc_key-værdi i tekstfeltet, og klik på Gem. Vent et øjeblik, og klyngelisten bør opdateres automatisk.

Det sidste trin er at rette MySQL cmon-brugerrettighederne for de nye ClusterControl IP-adresseændringer, 192.168.0.190. Log ind på masternoden (192.168.0.31) og kør følgende sætning:

$ mysql -uroot -p -e 'GRANT ALL PRIVILEGES ON *.* TO [email protected]"192.168.0.190" IDENTIFIED BY "<password>" WITH GRANT OPTION';

** Erstat med identisk cmon MySQL-adgangskode som i mysql_password-værdien inde i /etc/cmon.cnf.

Du kan også tilbagekalde de gamle brugerrettigheder (tilbagekaldelse sletter ikke brugeren) eller blot droppe den gamle bruger:

$ mysql -uroot -p -e 'DROP USER [email protected]"192.168.0.19"'

Når privilegiet er sat op, bør du se, at alt er grønt:

På dette tidspunkt ser vores arkitektur nogenlunde sådan her ud:

Vores migreringsøvelse er nu afsluttet.

Sidste tanker

Det er nu muligt at udføre fuld og delvis backup af dine ClusterControl-instanser og de klynger, de administrerer, så du kan flytte dem frit mellem værter med en lille indsats. Forslag og feedback modtages gerne.