Hoe maak je een back-up en herstel je ClusterControl

ClusterControl 1.7.1 heeft een nieuwe functie geïntroduceerd waarmee u een back-up van uw ClusterControl-server kunt maken en deze (samen met metadata over uw beheerde databases) op een andere server kunt terugzetten. Het maakt een back-up van de ClusterControl-toepassing en van alle configuratiegegevens. Het migreren van ClusterControl naar een nieuwe server was vroeger lastig, maar nu niet meer.

Deze blogpost leidt je door deze nieuwe functie.

We migreren ClusterControl van de ene server naar de andere, waarbij alle configuraties en instellingen behouden blijven.

We laten u ook zien hoe u het beheer van een cluster van de ene ClusterControl-instantie naar de andere kunt overbrengen.

Onze voorbeeldarchitectuur begon met twee productieclusters (getoond in de onderstaande schermafbeelding):

• Cluster-ID 1:3 Galera-knooppunten (PXC) + 1 HAProxy + 1 ProxySQL (5 knooppunten)
• Cluster-ID 2:1 MySQL-master + 2 MySQL-slaves + 1 ProxySQL (4 nodes)

Inleiding

ClusterControl CLI (s9s) is een opdrachtregelinterfacetool voor interactie, controle en beheer van databaseclusters met behulp van het ClusterControl-platform. Vanaf versie 1.4.1 zal het installatiescript dit pakket automatisch installeren op het ClusterControl-knooppunt.

Er zijn in principe 4 nieuwe opties geïntroduceerd onder het commando "s9s backup", die kunnen worden gebruikt om ons doel te bereiken:

Deze blogpost behandelt voorbeelden van gebruiksscenario's over het gebruik van die opties. Op dit moment bevinden ze zich in de fase van de kandidaat-release en zijn ze alleen beschikbaar via de ClusterControl CLI-tool.

Back-up maken van ClusterControl

Hiervoor moet de ClusterControl-server minimaal op v1.7.1 en hoger staan. Om een ​​back-up van de ClusterControl-controller te maken, voert u eenvoudig de volgende opdracht uit op het ClusterControl-knooppunt als rootgebruiker (of met sudo):

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

Het --output-bestand moet een bestandsnaam of fysiek pad zijn (als u de vlag --backup-directory wilt weglaten), en het bestand mag niet vooraf bestaan. ClusterControl zal het uitvoerbestand niet vervangen als het al bestaat. Door --log op te geven, wacht het totdat de taak is uitgevoerd en worden de taaklogboeken weergegeven in de terminal. Dezelfde logs zijn toegankelijk via de gebruikersinterface van ClusterControl onder Activiteit -> Taken -> Controller opslaan :

De taak 'Save Controller' voert in principe de volgende procedures uit:

1. Haal de controllerconfiguratie op en exporteer deze naar JSON
2. CMON-database exporteren als MySQL-dumpbestand
3. Voor elk databasecluster:
   1. Haal de clusterconfiguratie op en exporteer deze naar JSON

In de uitvoer ziet u misschien dat de gevonden baan N + 1 is cluster, bijvoorbeeld '3 cluster(s) gevonden om op te slaan', ook al hebben we maar twee databaseclusters. Dit omvat cluster-ID 0, dat een speciale betekenis heeft in ClusterControl als het globale geïnitialiseerde cluster. Het behoort echter niet tot de component CmonCluster, het databasecluster onder ClusterControl-beheer.

ClusterControl herstellen naar een nieuwe ClusterControl-server

Stel dat ClusterControl al op de nieuwe server is geïnstalleerd, willen we de databaseclusters migreren die door de nieuwe server moeten worden beheerd. Het volgende diagram illustreert onze migratieoefening:

Breng eerst de back-up over van de oude server naar de nieuwe server:

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

Voordat we het herstel uitvoeren, moeten we SSH zonder wachtwoord instellen voor alle knooppunten van de nieuwe 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

Voer vervolgens het herstel uit op de nieuwe server:

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

Vervolgens moeten we het cluster in de gebruikersinterface synchroniseren door naar Algemene instellingen -> Clusterregistraties -> Cluster synchroniseren te gaan . Als u vervolgens teruggaat naar het hoofddashboard van ClusterControl, ziet u het volgende:

Geen paniek. De nieuwe gebruikersinterface van ClusterControl kan de bewakings- en beheergegevens niet ophalen vanwege een onjuist RPC API-token. We moeten het alleen dienovereenkomstig bijwerken. Haal eerst de rpc_key waarde op voor de respectievelijke clusters:

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

Klik in de gebruikersinterface op de link "hier" en vervolgens op de regel "De RPC API-token hier wijzigen". Het volgende dialoogvenster verschijnt:

Plak de respectieve rpc_key-waarde in het tekstveld en klik op Opslaan. Herhaal dit voor het volgende cluster. Wacht even en de clusterlijst zou automatisch moeten worden vernieuwd.

De laatste stap is het herstellen van de MySQL cmon-gebruikersrechten voor de nieuwe ClusterControl IP-adreswijzigingen, 192.168.0.190. Log in op een van de PXC-knooppunten en voer het volgende uit:

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

** Vervang door een identiek cmon MySQL-wachtwoord zoals in de waarde mysql_password in /etc/cmon.cnf. Herhaal dezelfde stap op het tweede cluster, MySQL-replicatie, maar voer het slechts één keer uit op het hoofdknooppunt.

Zodra het privilege is ingesteld, zou u moeten zien dat de clusterlijst groen is, vergelijkbaar met de oude:

Het is de moeite waard om te vermelden dat ClusterControl standaard automatisch clusterherstel uitschakelt (zoals u het rode pictogram naast het woord 'Cluster' kunt zien) om racecondities met een andere ClusterControl-instantie te voorkomen. Het wordt aanbevolen om deze functie in te schakelen (door op het pictogram naar groen te klikken) zodra de oude server buiten gebruik is gesteld.

Onze migratie is nu voltooid. Alle configuraties en instellingen van de oude server worden bewaard en overgebracht naar de nieuwe server.

Het beheer van een cluster migreren naar een andere ClusterControl-server

Back-up maken van clusterinformatie

Dit gaat over het maken van een back-up van clustermetadata en informatie, zodat we deze kunnen overbrengen naar een andere ClusterControl-server, ook wel gedeeltelijke back-up genoemd. Anders moeten we "Bestaande server/cluster importeren" uitvoeren om ze opnieuw in de nieuwe ClusterControl te importeren, wat betekent dat u de bewakingsgegevens van de oude server zou verliezen. Als u load balancers of asynchrone slave-instanties hebt, moet dit worden geïmporteerd zodra het cluster is geïmporteerd, één knooppunt tegelijk. Het is dus een beetje gedoe als je een complete set productie-instellingen hebt.

De migratie-oefening van de cluster "manager" wordt geïllustreerd in het volgende diagram:

Kortom, we willen onze MySQL-replicatie (cluster-ID:2) migreren om te worden beheerd door een andere ClusterControl-instantie. We gaan hiervoor --save-cluster-info en --restore-cluster-info opties gebruiken. De --save-cluster-info optie zal de corresponderende clusterinformatie exporteren om ergens anders opgeslagen te worden. Laten we onze MySQL-replicatiecluster exporteren (cluster-ID:2). Doe op de huidige ClusterControl-server:

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

U ziet een aantal nieuwe regels afgedrukt in de terminal, die aangeven dat de back-uptaak ​​wordt uitgevoerd (de uitvoer is ook toegankelijk via ClusterControl -> Activiteit -> Taken ):

Als je goed naar de taaklogboeken kijkt, zou je zien dat de taak alle gerelateerde informatie en metadata voor cluster-ID 2 probeerde te exporteren. De uitvoer wordt opgeslagen als een gecomprimeerd bestand en bevindt zich onder het pad dat we hebben opgegeven met --backup -map vlag. Als deze vlag wordt genegeerd, zal ClusterControl de uitvoer opslaan in de standaard back-upmap, de basismap van de SSH-gebruiker, onder $HOME/backups.

Clusterinformatie herstellen

De stappen die hier worden uitgelegd, zijn vergelijkbaar met de herstelstappen voor volledige back-up van ClusterControl. Breng de back-up over van de huidige server naar de andere ClusterControl-server:

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

Voordat we het herstel uitvoeren, moeten we SSH zonder wachtwoord instellen voor alle knooppunten van de nieuwe 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

Voer vervolgens op de nieuwe server het herstel van de clusterinformatie uit voor onze MySQL-replicatie:

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

U kunt de voortgang controleren onder Activiteit -> Taken -> Cluster herstellen :

Als je de taakberichten goed bekijkt, kun je zien dat ClusterControl automatisch cluster-ID opnieuw toewijst aan 1 op deze nieuwe instantie (het was cluster-ID 2 op de oude instantie).

Synchroniseer vervolgens het cluster in de gebruikersinterface door naar Algemene instellingen -> Clusterregistraties -> Cluster synchroniseren te gaan . Als u teruggaat naar het hoofddashboard van ClusterControl, ziet u het volgende:

De fout betekent dat de nieuwe gebruikersinterface van ClusterControl de bewakings- en beheergegevens niet kan ophalen vanwege een onjuist RPC API-token. We moeten het alleen dienovereenkomstig bijwerken. Haal eerst de rpc_key-waarde op voor onze cluster-ID 1:

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

Klik in de gebruikersinterface op de link "hier" en vervolgens op de regel "De RPC API-token hier wijzigen". Het volgende dialoogvenster verschijnt:

Plak de respectieve rpc_key-waarde in het tekstveld en klik op Opslaan. Wacht even en de clusterlijst zou automatisch moeten worden vernieuwd.

De laatste stap is het herstellen van de MySQL cmon-gebruikersrechten voor de nieuwe ClusterControl IP-adreswijzigingen, 192.168.0.190. Log in op het hoofdknooppunt (192.168.0.31) en voer de volgende instructie uit:

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

** Vervang door een identiek cmon MySQL-wachtwoord zoals in de mysql_password-waarde in /etc/cmon.cnf.

U kunt ook de oude gebruikersrechten intrekken (intrekken zal de gebruiker niet verwijderen) of gewoon de oude gebruiker verwijderen:

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

Zodra het privilege is ingesteld, zou je moeten zien dat alles groen is:

Op dit moment ziet onze architectuur er ongeveer zo uit:

Onze migratie-oefening is nu voltooid.

Laatste gedachten

Het is nu mogelijk om een ​​volledige of gedeeltelijke back-up uit te voeren van uw ClusterControl-instanties en de clusters die ze beheren, zodat u ze met weinig moeite vrijelijk tussen hosts kunt verplaatsen. Suggesties en feedback zijn welkom.