Hur man säkerhetskopierar och återställer ClusterControl

ClusterControl 1.7.1 introducerade en ny funktion som låter dig säkerhetskopiera din ClusterControl-server och återställa den (tillsammans med metadata om dina hanterade databaser) till en annan server. Den säkerhetskopierar ClusterControl-applikationen såväl som alla dess konfigurationsdata. Att migrera ClusterControl till en ny server brukade vara jobbigt, men inte längre.

Det här blogginlägget leder dig genom den här nya funktionen.

Vi kommer att migrera ClusterControl från en server till en annan och bevara alla konfigurationer och inställningar.

Vi kommer också att visa dig hur du överför hanteringen av ett kluster från en ClusterControl-instans till en annan.

Vår exempelarkitektur började med två produktionskluster (visas i skärmdumpen nedan):

• Kluster-ID 1:3 Galera-noder (PXC) + 1 HAProxy + 1 ProxySQL (5 noder)
• Kluster-ID 2:1 MySQL-master + 2 MySQL-slavar + 1 ProxySQL (4 noder)

Introduktion

ClusterControl CLI (s9s) är ett kommandoradsgränssnittsverktyg för att interagera, kontrollera och hantera databaskluster med hjälp av ClusterControl-plattformen. Från och med version 1.4.1 kommer installationsskriptet automatiskt att installera detta paket på ClusterControl-noden.

Det finns i princip fyra nya alternativ som introduceras under kommandot "s9s backup", som kan användas för att uppnå vårt mål:

Det här blogginlägget kommer att täcka exempel på användningsfall om hur man använder dessa alternativ. För tillfället är de i release-kandidatstadiet och endast tillgängliga via ClusterControl CLI-verktyget.

Säkerhetskopiera ClusterControl

För att göra detta måste ClusterControl-servern vara minst v1.7.1 och senare. För att säkerhetskopiera ClusterControl-kontrollern kör du helt enkelt följande kommando på ClusterControl-noden som root-användare (eller med sudo):

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

--output-filen måste vara ett filnamn eller en fysisk sökväg (om du vill utelämna --backup-katalogflaggan), och filen får inte existera i förväg. ClusterControl kommer inte att ersätta utdatafilen om den redan finns. Genom att specificera --log kommer det att vänta tills jobbet är utfört och jobbloggarna kommer att visas i terminalen. Samma loggar kan nås via ClusterControl UI under Aktivitet -> Jobb -> Spara styrenhet :

Jobbet 'Spara styrenhet' utför i princip följande procedurer:

1. Hämta kontrollerns konfiguration och exportera den till JSON
2. Exportera CMON-databas som MySQL-dumpfil
3. För varje databaskluster:
   1. Hämta klusterkonfigurationen och exportera den till JSON

I utgången kan du märka att jobbet hittat är N + 1 kluster, till exempel "Hittade 3 kluster att spara" trots att vi bara har två databaskluster. Detta inkluderar kluster-ID 0, som har speciell betydelse i ClusterControl som det globala initierade klustret. Den tillhör dock inte CmonCluster-komponenten, som är databasklustret under ClusterControl-hantering.

Återställer ClusterControl till en ny ClusterControl-server

Om ClusterControl redan är installerat på den nya servern, skulle vi vilja migrera databasklustren för att hanteras av den nya servern. Följande diagram illustrerar vår migreringsövning:

Överför först säkerhetskopian från den gamla servern till den nya servern:

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

Innan vi utför återställningen måste vi ställa in lösenordslös SSH till alla noder från den nya ClusterControl-servern:

$ 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

Utför sedan återställningen på den nya servern:

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

Sedan måste vi synkronisera klustret i användargränssnittet genom att gå till Globala inställningar -> Klusterregistreringar -> Synkronisera kluster . Om du sedan går tillbaka till ClusterControls huvudinstrumentpanel ser du följande:

Få inte panik. Det nya ClusterControl-gränssnittet kan inte hämta övervaknings- och hanteringsdata på grund av felaktig RPC API-token. Vi behöver bara uppdatera den därefter. Hämta först värdet rpc_key för respektive kluster:

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

I användargränssnittet klickar du på länken "här" och sedan på raden "Ändra RPC API-token här". Det kommer att dyka upp följande dialogruta:

Klistra in respektive rpc_key-värde i textfältet och klicka på Spara. Upprepa för nästa kluster. Vänta ett ögonblick och klusterlistan bör uppdateras automatiskt.

Det sista steget är att fixa MySQL cmon-användarprivilegierna för de nya ClusterControl IP-adressändringarna, 192.168.0.190. Logga in på en av PXC-noderna och kör följande:

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

** Ersätt med identiskt cmon MySQL-lösenord som i mysql_password-värdet inuti /etc/cmon.cnf. Upprepa samma steg på det andra klustret, MySQL-replikering, men kör det bara en gång på huvudnoden.

När privilegiet har ställts in bör du se att klusterlistan är i grönt, liknande den gamla:

Det är värt att nämna att som standard kommer ClusterControl att inaktivera klustrets automatiska återställning (som du kan se den röda ikonen bredvid ordet 'Cluster') för att undvika rastillstånd med en annan ClusterControl-instans. Vi rekommenderar att du aktiverar den här funktionen (genom att klicka på ikonen till grön) när den gamla servern har tagits ur drift.

Vår migrering är nu klar. Alla konfigurationer och inställningar från den gamla servern bevaras och överförs till den nya servern.

Migrera hanteringen av ett kluster till en annan ClusterControl-server

Säkerhetskopiera klusterinformation

Det här handlar om att säkerhetskopiera klustermetadata och information så att vi kan överföra den till en annan ClusterControl-server, även känd som partiell backup. Annars måste vi utföra "Importera befintlig server/kluster" för att återimportera dem till den nya ClusterControl vilket innebär att du skulle förlora övervakningsdata från den gamla servern. Om du har lastbalanserare eller asynkrona slavinstanser, måste detta importeras när klustret har importerats, en nod i taget. Så det är lite krångligt om du har en komplett uppsättning produktionsinställningar.

Migreringsövningen för kluster "manager" illustreras i följande diagram:

I grund och botten vill vi migrera ut vår MySQL-replikering (kluster-ID:2) för att hanteras av en annan ClusterControl-instans. Vi kommer att använda --save-cluster-info och --restore-cluster-info alternativ för den här. Alternativet --save-cluster-info kommer att exportera motsvarande klusterinformation för att sparas någon annanstans. Låt oss exportera vårt MySQL-replikeringskluster (kluster-ID:2). På den aktuella ClusterControl-servern gör du:

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

Du kommer att se ett gäng nya rader utskrivna i terminalen, vilket indikerar att backupjobbet körs (utgången är också tillgänglig via ClusterControl -> Aktivitet -> Jobb ):

Om du tittar på jobbloggarna noga, skulle du märka att jobbet försökte exportera all relaterad information och metadata för kluster-ID 2. Utdata lagras som en komprimerad fil och ligger under sökvägen som vi har angett under med --backup -katalogflagga. Om denna flagga ignoreras kommer ClusterControl att spara utdata till standard backup-katalogen som är SSH-användarens hemkatalog, under $HOME/backups.

Återställa klusterinformation

Stegen som förklaras här liknar återställningsstegen för ClusterControl full backup. Överför säkerhetskopian från den aktuella servern till den andra ClusterControl-servern:

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

Innan vi utför återställningen måste vi ställa in lösenordslös SSH till alla noder från den nya ClusterControl-servern:

$ 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

Utför sedan klusterinformationsåterställningen för vår MySQL-replikering på den nya servern:

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

Du kan verifiera framstegen under Aktivitet -> Jobb -> Återställ kluster :

Om du tittar noga på jobbmeddelandena kan du se att ClusterControl automatiskt omtilldelar kluster-ID till 1 på den här nya instansen (det var kluster-ID 2 på den gamla instansen).

Synkronisera sedan klustret i användargränssnittet genom att gå till Globala inställningar -> Klusterregistreringar -> Synkronisera kluster . Om du går tillbaka till ClusterControls huvudinstrumentpanel ser du följande:

Felet innebär att det nya ClusterControl-gränssnittet inte kan hämta övervaknings- och hanteringsdata på grund av felaktig RPC API-token. Vi behöver bara uppdatera den därefter. Hämta först värdet rpc_key för vårt kluster-ID 1:

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

I användargränssnittet klickar du på länken "här" och sedan på raden "Ändra RPC API-token här". Det kommer att dyka upp följande dialogruta:

Klistra in respektive rpc_key-värde i textfältet och klicka på Spara. Vänta ett ögonblick och klusterlistan bör uppdateras automatiskt.

Det sista steget är att fixa MySQL cmon-användarprivilegierna för de nya ClusterControl IP-adressändringarna, 192.168.0.190. Logga in på masternoden (192.168.0.31) och kör följande sats:

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

** Ersätt med identiskt cmon MySQL-lösenord som i mysql_password-värdet inuti /etc/cmon.cnf.

Du kan också återkalla de gamla användarrättigheterna (återkallelse tar inte bort användaren) eller helt enkelt släppa den gamla användaren:

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

När privilegiet har ställts in bör du se att allt är grönt:

Vid det här laget ser vår arkitektur ut ungefär så här:

Vår migreringsövning är nu klar.

Sluta tankar

Det är nu möjligt att utföra fullständig och partiell säkerhetskopiering av dina ClusterControl-instanser och de kluster de hanterar, så att du kan flytta dem fritt mellan värdar med små ansträngningar. Förslag och feedback är välkomna.