Come eseguire il backup e il ripristino di ClusterControl

ClusterControl 1.7.1 ha introdotto una nuova funzionalità che consente di eseguire il backup del server ClusterControl e ripristinarlo (insieme ai metadati relativi ai database gestiti) su un altro server. Esegue il backup dell'applicazione ClusterControl e di tutti i suoi dati di configurazione. La migrazione di ClusterControl su un nuovo server era una seccatura, ma ora non più.

Questo post del blog ti guida attraverso questa nuova funzionalità.

Migreremo ClusterControl da un server all'altro, preservando tutte le configurazioni e le impostazioni.

Ti mostreremo anche come trasferire la gestione di un cluster da un'istanza ClusterControl a un'altra.

La nostra architettura di esempio è iniziata con due cluster di produzione (mostrati nello screenshot seguente):

ID cluster 1:3 nodi Galera (PXC) + 1 HAProxy + 1 ProxySQL (5 nodi)
ID cluster 2:1 master MySQL + 2 slave MySQL + 1 ProxySQL (4 nodi)

Introduzione

ClusterControl CLI (s9s) è uno strumento di interfaccia a riga di comando per interagire, controllare e gestire i cluster di database utilizzando la piattaforma ClusterControl. A partire dalla versione 1.4.1, lo script di installazione installerà automaticamente questo pacchetto sul nodo ClusterControl.

Ci sono fondamentalmente 4 nuove opzioni introdotte sotto il comando "s9s backup", che possono essere utilizzate per raggiungere il nostro obiettivo:

Bandiera	Descrizione
--save-controller	Salva lo stato del controller in un tarball.
--restore-controller	Ripristina l'intero controller da un tarball creato in precedenza (creato utilizzando --save-controller
--save-cluster-info	Salva le informazioni che il controller ha su un cluster.
--restore-cluster-info	Ripristina le informazioni che il controller ha su un cluster da un file di archivio creato in precedenza.

Questo post del blog tratterà casi d'uso di esempio su come utilizzare tali opzioni. Al momento, sono in fase di rilascio candidato e disponibili solo tramite lo strumento ClusterControl CLI.

Backup di ClusterControl

Per fare ciò, il server ClusterControl deve essere almeno su v1.7.1 e versioni successive. Per eseguire il backup del controller ClusterControl, è sufficiente eseguire il seguente comando sul nodo ClusterControl come utente root (o con sudo):

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

Il --output-file deve essere un nome di file o un percorso fisico (se si desidera omettere il flag --backup-directory) e il file non deve esistere in anticipo. ClusterControl non sostituirà il file di output se esiste già. Specificando --log, attenderà che il lavoro venga eseguito e i registri dei lavori verranno mostrati nel terminale. È possibile accedere agli stessi registri tramite ClusterControl UI in Attività -> Lavori -> Salva controller :

Il lavoro 'Salva controller' esegue sostanzialmente le seguenti procedure:

Recupera la configurazione del controller ed esportala in JSON
Esporta il database CMON come file di dump MySQL
Per ogni cluster di database:
1. Recupera la configurazione del cluster ed esportala in JSON

Nell'output, potresti notare che il lavoro trovato è N + 1 cluster, ad esempio "Trovato 3 cluster da salvare" anche se abbiamo solo due cluster di database. Ciò include l'ID cluster 0, che ha un significato speciale in ClusterControl come cluster inizializzato globale. Tuttavia, non appartiene al componente CmonCluster, che è il cluster di database in Gestione ClusterControl.

Ripristino di ClusterControl su un nuovo ClusterControl Server

Supponendo che ClusterControl sia già installato sul nuovo server, vorremmo migrare i cluster di database che devono essere gestiti dal nuovo server. Il diagramma seguente illustra il nostro esercizio di migrazione:

Innanzitutto, trasferisci il backup dal vecchio server al nuovo server:

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

Prima di eseguire il ripristino, dobbiamo configurare SSH senza password su tutti i nodi dal nuovo server ClusterControl:

$ 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

Quindi, sul nuovo server, esegui il ripristino:

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

Quindi dobbiamo sincronizzare il cluster nell'interfaccia utente andando su Impostazioni globali -> Registrazioni cluster -> Sincronizza cluster . Quindi, se torni alla dashboard principale di ClusterControl, vedrai quanto segue:

Niente panico. La nuova interfaccia utente ClusterControl non è in grado di recuperare i dati di monitoraggio e gestione a causa di un token API RPC errato. Dobbiamo solo aggiornarlo di conseguenza. Innanzitutto, recupera il valore rpc_key per i rispettivi cluster:

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

Nell'interfaccia utente, fare clic sul collegamento "qui" in corrispondenza della riga "Modifica qui il token API RPC". Apparirà la seguente finestra di dialogo:

Incolla il rispettivo valore rpc_key nel campo di testo e fai clic su Salva. Ripetere per il prossimo cluster. Attendi un momento e l'elenco dei cluster dovrebbe essere aggiornato automaticamente.

L'ultimo passaggio consiste nel correggere i privilegi utente MySQL cmon per le nuove modifiche all'indirizzo IP di ClusterControl, 192.168.0.190. Accedi a uno dei nodi PXC ed esegui quanto segue:

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

** Sostituisci con una password MySQL cmon identica a quella del valore mysql_password all'interno di /etc/cmon.cnf. Ripeti lo stesso passaggio sul secondo cluster, la replica MySQL, ma eseguilo solo una volta sul nodo master.

Una volta impostato il privilegio, dovresti vedere che l'elenco dei cluster è in verde, simile a quello precedente:

Vale la pena ricordare che per impostazione predefinita, ClusterControl disabiliterà il ripristino automatico del cluster (come puoi vedere l'icona rossa accanto alla parola "Cluster") per evitare race condition con un'altra istanza di ClusterControl. Si consiglia di abilitare questa funzione (facendo clic sull'icona in verde) una volta che il vecchio server è stato disattivato.

La nostra migrazione è ora completata. Tutte le configurazioni e le impostazioni del vecchio server vengono conservate e trasferite al nuovo server.

Migrazione della gestione di un cluster su un altro server ClusterControl

Backup delle informazioni sul cluster

Si tratta di eseguire il backup dei metadati e delle informazioni del cluster in modo da poterli trasferire a un altro server ClusterControl, noto anche come backup parziale. In caso contrario, dobbiamo eseguire "Importa server/cluster esistente" per reimportarli nel nuovo ClusterControl, il che significa che i dati di monitoraggio del vecchio server andrebbero persi. Se hai sistemi di bilanciamento del carico o istanze slave asincrone, questo dovrebbe essere importato una volta importato il cluster, un nodo alla volta. Quindi è un po' una seccatura se hai una serie completa di impostazioni di produzione.

L'esercizio di migrazione del "manager" del cluster è illustrato nel diagramma seguente:

Fondamentalmente, vogliamo migrare la nostra replica MySQL (ID cluster:2) per essere gestita da un'altra istanza ClusterControl. Useremo le opzioni --save-cluster-info e --restore-cluster-info per questo. L'opzione --save-cluster-info esporterà le informazioni del cluster corrispondenti per essere salvate da qualche altra parte. Esportiamo il nostro MySQL Replication Cluster (ID cluster:2). Sul server ClusterControl corrente, eseguire:

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

Vedrai una serie di nuove righe stampate nel terminale, che indicano che il processo di backup è in esecuzione (l'output è accessibile anche tramite ClusterControl -> Attività -> Lavori ):

Se guardi da vicino i registri del lavoro, noterai che il lavoro stava tentando di esportare tutte le informazioni e i metadati correlati per l'ID cluster 2. L'output è archiviato come file compresso e si trova nel percorso che abbiamo specificato in using --backup -bandiera della directory. Se questo flag viene ignorato, ClusterControl salverà l'output nella directory di backup predefinita che è la directory home dell'utente SSH, in $HOME/backups.

Ripristino delle informazioni sul cluster

I passaggi qui illustrati sono simili ai passaggi di ripristino per il backup completo di ClusterControl. Trasferisci il backup dal server corrente all'altro server ClusterControl:

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

Prima di eseguire il ripristino, dobbiamo configurare SSH senza password su tutti i nodi dal nuovo server ClusterControl:

$ 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

Quindi, sul nuovo server, esegui il ripristino delle informazioni del cluster per la nostra replica MySQL:

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

Puoi verificare lo stato di avanzamento in Attività -> Lavori -> Ripristina cluster :

Se osservi i messaggi di lavoro da vicino, puoi vedere che ClusterControl riassegna automaticamente l'ID cluster a 1 su questa nuova istanza (era l'ID cluster 2 sulla vecchia istanza).

Quindi sincronizza il cluster nell'interfaccia utente andando su Impostazioni globali -> Registrazioni cluster -> Sincronizza cluster . Se torni alla dashboard principale di ClusterControl, vedrai quanto segue:

L'errore indica che la nuova interfaccia utente ClusterControl non è in grado di recuperare i dati di monitoraggio e gestione a causa di un token API RPC errato. Dobbiamo solo aggiornarlo di conseguenza. Innanzitutto, recupera il valore rpc_key per il nostro ID cluster 1:

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

Nell'interfaccia utente, fare clic sul collegamento "qui" in corrispondenza della riga "Modifica qui il token API RPC". Apparirà la seguente finestra di dialogo:

Incolla il rispettivo valore rpc_key nel campo di testo e fai clic su Salva. Attendi un momento e l'elenco dei cluster dovrebbe essere aggiornato automaticamente.

L'ultimo passaggio consiste nel correggere i privilegi utente MySQL cmon per le nuove modifiche all'indirizzo IP di ClusterControl, 192.168.0.190. Accedi al nodo master (192.168.0.31) ed esegui la seguente istruzione:

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

** Sostituisci con una password MySQL cmon identica a quella del valore mysql_password all'interno di /etc/cmon.cnf.

Puoi anche revocare i vecchi privilegi utente (la revoca non cancellerà l'utente) o semplicemente eliminare il vecchio utente:

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

Una volta impostato il privilegio, dovresti vedere che tutto è verde:

A questo punto, la nostra architettura è simile a questa:

Il nostro esercizio di migrazione è ora completo.

Pensieri finali

Ora è possibile eseguire il backup completo e parziale delle tue istanze ClusterControl e dei cluster che gestiscono, permettendoti di spostarle liberamente tra host con poco sforzo. Suggerimenti e feedback sono i benvenuti.