Ripristino completo di un cluster MySQL o MariaDB Galera dal backup

L'esecuzione di backup regolari del cluster di database è fondamentale per l'elevata disponibilità e il ripristino di emergenza. Se per qualsiasi motivo hai perso l'intero cluster e hai dovuto eseguire un ripristino completo dal backup, avresti bisogno di un backup affidabile e aggiornato da cui partire.

Best practice per i backup

Alcuni consigli da considerare per un buon regime di backup pianificato:

• Dovresti essere in grado di eseguire il ripristino completo da un errore irreversibile da almeno due backup completi precedenti. Nel caso in cui il backup completo più recente sia danneggiato, perso o danneggiato,
• Il tuo backup dovrebbe contenere almeno un backup completo all'interno di un ciclo prescelto, normalmente settimanale,
• Memorizza i backup lontano dalla posizione corrente dei dati, preferibilmente fuori sede,
• Utilizza una combinazione di mysqldump e Xtrabackup per una maggiore sicurezza e non fare affidamento su un solo metodo,
• Verifica regolarmente il ripristino dei backup, ad es. ogni due mesi.

Normalmente è sufficiente un backup completo settimanale combinato con un backup incrementale giornaliero. Mantenere un certo numero di backup per un periodo di tempo è sempre un buon piano, magari mantenere ogni backup settimanale per un mese. Ciò ti consente di ripristinare un database più vecchio in caso di emergenza o se per qualche motivo hai il danneggiamento del file di backup locale.

mysqldump o Xtrabackup

mysqldump è molto probabilmente il modo più popolare per eseguire il backup di MySQL. Esegue un backup logico dei dati, leggendo da ciascuna tabella utilizzando le istruzioni SQL, quindi esportando i dati in file di testo. Ripristino di un mysqldump è facile come creare il file dump. Gli svantaggi principali sono che è molto lento per database di grandi dimensioni, non è "caldo" e cancella il pool di buffer InnoDB.

Xtrabackup esegue backup a caldo, non blocca il database durante il backup ed è generalmente più veloce. I backup a caldo sono importanti per l'elevata disponibilità, poiché vengono eseguiti senza bloccare l'applicazione. Questo è anche un fattore importante quando viene utilizzato con Galera, poiché Galera si basa sulla replica sincrona. Tuttavia, il ripristino di un xtrabackup può essere un po' complicato usando metodi manuali.

ClusterControl supporta la pianificazione di mysqldump e Xtrabackup (completo e incrementale), nonché il ripristino del backup direttamente dall'interfaccia utente.

Ripristino completo dal backup

In questo post, ti mostreremo come ripristinare Xtrabackup (completo + incrementale) su un cluster vuoto in esecuzione su MariaDB Galera Cluster. Questi passaggi dovrebbero funzionare anche su Percona XtraDB Cluster o Galera Cluster for MySQL di Codership.

Nel nostro cluster originale, avevamo un xtrabackup completo pianificato ogni giorno, con backup incrementali creati ogni ora. I backup vengono archiviati su ClusterControl come mostrato nella schermata seguente:

Ora, supponiamo di aver perso il nostro cluster originale e di dover eseguire un ripristino completo su un nuovo cluster. I passaggi includono:

1. Configura un nuovo server ClusterControl.
2. Imposta un nuovo cluster MariaDB.
3. Esportare i record ei file di backup nel nuovo server ClusterControl.
4. Avvia il processo di ripristino.
5. Avvia i nodi rimanenti.

Il diagramma seguente illustra la nostra architettura per questo esercizio:

Passaggio 1:configurazione del nuovo cluster MariaDB

Installa ClusterControl e distribuisci un nuovo cluster MariaDB. Vai a ClusterControl -> Deploy -> Deploy Database Cluster -> MySQL Galera e specifica le informazioni richieste nella finestra di dialogo di distribuzione:

Fare clic sul pulsante Distribuisci e avviare la distribuzione. Poiché abbiamo solo un cluster sul vecchio server, l'ID cluster dovrebbe essere identico (ID cluster:1) in questa nuova istanza.

Sul vecchio server ClusterControl, esporta la tabella backup_records in file dump:

$ mysqldump -uroot -p --single-transaction --no-create-info cmon backup_records > backup_records.sql

Quindi, eseguire la copia remota dei file di backup dal vecchio server nel nuovo server ClusterControl:

$ scp -r /root/backups 192.168.55.150:/root/
$ scp ~/backup_records.sql 192.168.55.150:~

Successivamente è modificare i file di dump in modo che riflettano il nuovo indirizzo IP del server ClusterControl. Non dimenticare di evitare il punto nell'indirizzo IP:

$ sed -i "s/192\.168\.55\.170/192\.168\.55\.150/g" backup_records.sql

Nel nuovo server ClusterControl importare i file di dump:

$ mysql -uroot -p cmon < backup_records.sql

Verificare che l'elenco di backup sia corretto nel nuovo server ClusterControl:

Come puoi vedere, tutte le occorrenze del precedente indirizzo IP (192.168.55.170) sono state sostituite dal nuovo indirizzo IP (192.168.55.150). Ora siamo pronti per eseguire il ripristino nel nuovo server.

Fase 3:esegui il ripristino

L'esecuzione del ripristino tramite l'interfaccia utente di ClusterControl è un semplice passaggio punta e clicca. Scegli quale backup ripristinare e fai clic sul pulsante "Ripristina". Ripristineremo l'ultimo backup incrementale disponibile (Backup:9). Fai clic sul pulsante "Ripristina" appena sotto il nome del backup e ti verrà presentata la seguente finestra di pre-ripristino:

Sembra che la dimensione del backup sia piuttosto piccola (165,6 kB). Non importa perché ClusterControl preparerà tutti i backup incrementali raggruppati in Backup Set 6, che contiene Xtrabackup completo. Hai anche diverse opzioni post-restauro:

• Ripristina backup su:scegli il nodo su cui ripristinare il backup.
• Tmp Dir:la directory verrà utilizzata sul server ClusterControl locale come memoria temporanea durante la preparazione del backup. Deve essere grande quanto la directory dei dati MySQL stimata.
• Cluster di bootstrap dal nodo ripristinato:poiché si tratta di un nuovo cluster, lo attiveremo in modo che ClusterControl avvii automaticamente il cluster al termine del ripristino.
• Fai una copia della datadir prima di ripristinare il backup - Se i dati ripristinati sono danneggiati o meno come previsto, avrai un backup della precedente directory dei dati MySQL. Poiché si tratta di un nuovo cluster, ignoreremo questo.

Il ripristino di Percona Xtrabackup causerà l'arresto del cluster. ClusterControl:

1. Arresta tutti i nodi nel cluster.
2. Ripristina il backup sul nodo selezionato.
3. Esegui il bootstrap del nodo selezionato.

Per vedere l'avanzamento del ripristino, vai su Attività -> Lavori -> Ripristina backup e fai clic sul pulsante "Dettagli lavoro completo". Dovresti vedere qualcosa del genere:

Una cosa importante che devi fare è monitorare l'output del log degli errori MySQL sul nodo di destinazione (192.168.55.151) durante il processo di ripristino. Al termine del ripristino e durante il processo di bootstrap, dovresti vedere le seguenti righe che iniziano a comparire:

Version: '10.1.22-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server
2017-04-07 18:03:51 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:51 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:51 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:52 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:53 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:54 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:55 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)

Niente panico. Questo è un comportamento previsto perché questo set di backup non archivia le credenziali di accesso cmon della nuova password cmon ClusterControl. Ha invece ripristinato/sostituito il vecchio utente cmon. Quello che devi fare è riassegnare l'utente cmon al server eseguendo la seguente istruzione su questo nodo DB:

GRANT ALL PRIVILEGES ON *.* to [email protected]'192.168.55.150' IDENTIFIED BY 'mynewCMONpassw0rd' WITH GRANT OPTION;
FLUSH PRIVILEGES;

ClusterControl sarà quindi in grado di connettersi al nodo di cui è stato eseguito il bootstrap e determinare il nodo e lo stato di backup. Se tutto è a posto, dovresti vedere qualcosa del genere:

A questo punto, il nodo di destinazione è avviato e in esecuzione. Possiamo avviare i nodi rimanenti in Nodi -> scegliere nodo -> Avvia nodo e selezionare la casella di controllo "Esegui un avvio iniziale":

Il ripristino è ora completo e puoi aspettarti che Performance -> DB Growth riporti le dimensioni aggiornate del nostro set di dati appena ripristinato:

Buon ripristino!