Come recuperare il cluster MySQL Galera da uno slave asincrono

Introduzione

Quando si esegue Galera Cluster, è prassi comune aggiungere uno o più slave asincroni nello stesso datacenter o in un altro. Questo ci fornisce un piano di emergenza con un basso RTO e con un basso costo operativo. Nel caso di un problema irreversibile nel nostro cluster, possiamo eseguire rapidamente il failover in modo che le applicazioni possano continuare ad avere accesso ai dati.

Quando si utilizza questo tipo di configurazione, non è possibile ricostruire il nostro cluster da un backup precedente. Poiché lo slave asincrono è ora la nuova fonte di verità, dobbiamo ricostruire il cluster da esso.

Questo non significa che abbiamo solo un modo per farlo, forse c'è anche un modo migliore! Sentiti libero di darci i tuoi suggerimenti nella sezione commenti alla fine di questo post.

Topologia

Sopra, possiamo vedere una topologia di esempio con Galera Cluster e una replica/slave asincrona.

Successivamente vedremo come possiamo ricreare il nostro cluster, partendo dallo slave, nel caso in cui trovassimo qualcosa del genere:

Se osserviamo l'immagine precedente, possiamo vedere che i nostri 3 nodi Galera sono inattivi. Il nostro slave non è in grado di connettersi al master Galera, ma è in uno stato "Up and running".

Promuovi schiavo

Poiché il nostro schiavo funziona correttamente, possiamo promuoverlo per padroneggiarlo e indirizzargli le nostre applicazioni. Per questo, dobbiamo disabilitare il parametro di sola lettura nel nostro slave e ripristinare la configurazione dello slave.

Nel nostro schiavo (mysql1):

mysql> SET GLOBAL read_only=0;
Query OK, 0 rows affected (0.00 sec)
mysql> STOP SLAVE;
Query OK, 0 rows affected (0.00 sec)
mysql> RESET SLAVE;
Query OK, 0 rows affected (0.18 sec)

Crea nuovo cluster

Successivamente, per avviare il ripristino del nostro cluster guasto, creeremo un nuovo cluster Galera. Questo può essere fatto facilmente tramite ClusterControl ClusterControl, per favore scorri più in basso in questo blog per vedere come.

Dopo aver distribuito il nostro nuovo cluster Galera, avremmo qualcosa di simile al seguente:

Replica

Dobbiamo assicurarci di aver configurato i parametri di replica.

Per i nodi Galera (galera1, galera2, galera3):

server_id=<ID>         # Different value in each node
binlog_format=ROW
log_bin = /var/lib/mysql-binlog/binlog
log_slave_updates = ON
gtid_mode = ON
enforce_gtid_consistency = true
relay_log = relay-bin
expire_logs_days = 7

Per il nodo principale (mysql1):

server_id=<ID>         # Different value in each node
binlog_format=ROW
log_bin=binlog
log_slave_updates=1
gtid_mode=ON
enforce_gtid_consistency=1
relay_log=relay-bin
expire_logs_days=7
read_only=ON
sync_binlog=1
report_host=<HOSTNAME or IP>    # Local server

Affinché il nostro nuovo slave (galera1) si connetta con il nostro nuovo master (mysql1), dobbiamo creare un utente con autorizzazioni di replica nel nostro master.

Nel nostro nuovo master (mysql1):

mysql> GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'%' IDENTIFIED BY 'slave_password';

Nota:possiamo sostituire "%" con l'IP del nodo Galera Cluster che sarà il nostro slave, nel nostro esempio, galera1.

Backup

Se non lo abbiamo, dobbiamo creare un backup coerente del nostro master (mysql1) e caricarlo nel nostro nuovo Galera Cluster. Per questo, possiamo usare lo strumento XtraBackup o mysqldump. Vediamo entrambe le opzioni.

Nel nostro esempio utilizziamo il database Sakila disponibile per il test.

Strumento XtraBackup

Generiamo il backup nel nuovo master (mysql1). Nel nostro caso lo inviamo alla directory locale /root/backup:

$ innobackupex /root/backup/

Dobbiamo ricevere il messaggio:

180705 22:08:14 completed OK!

Comprimiamo il backup e lo inviamo al nodo che sarà il nostro slave (galera1):

$ cd /root/backup
$ tar zcvf 2018-07-05_22-08-07.tar.gz 2018-07-05_22-08-07
$ scp /root/backup/2018-07-05_22-08-07.tar.gz galera1:/root/backup/

In galera1, estrai il backup:

$ tar zxvf /root/backup/2018-07-05_22-08-07.tar.gz

Arrestiamo il cluster (se avviato). Per questo fermiamo i servizi MySQL dei 3 nodi:

$ service mysql stop

In galera1, rinominiamo la directory dei dati di mysql e carichiamo il backup:

$ mv /var/lib/mysql /var/lib/mysql.bak
$ innobackupex --copy-back /root/backup/2018-07-05_22-08-07

Dobbiamo ricevere il messaggio:

180705 23:00:01 completed OK!

Assegniamo i permessi corretti sulla directory dei dati:

$ chown -R mysql.mysql /var/lib/mysql

Quindi dobbiamo inizializzare il cluster.

Una volta inizializzato il primo nodo, dobbiamo avviare il servizio MySQL per i nodi rimanenti, eliminando qualsiasi copia precedente del file grastate.dat, e quindi verificare che i nostri dati siano aggiornati.

$ rm /var/lib/mysql/grastate.dat
$ service mysql start

Nota:verifica che l'utente utilizzato da XtraBackup sia stato creato nel nostro nodo inizializzato e sia lo stesso in ogni nodo.

mysqldump

In generale, non consigliamo di farlo con mysqldump, perché può essere piuttosto lento con un grande volume di dati. Ma è un'alternativa per eseguire l'attività.

Generiamo il backup nel nuovo master (mysql1):

$ mysqldump -uroot -p --single-transaction --skip-add-locks --triggers --routines --events --databases sakila > /root/backup/sakila_dump.sql

Lo comprimiamo e lo inviamo al nostro nodo slave (galera1):

$ gzip /root/backup/sakila_dump.sql
$ scp /root/backup/sakila_dump.sql.gz galera1:/root/backup/

Carichiamo il dump in galera1.

$ gunzip /root/backup/sakila_dump.sql.gz
$ mysql -p < /root/backup/sakila_dump.sql

Quando il dump viene caricato in galera1, dobbiamo riavviare il servizio MySQL sui nodi rimanenti, rimuovendo il file grastate.dat, e verificare di avere i nostri dati aggiornati.

$ rm /var/lib/mysql/grastate.dat
$ service mysql start

Avvia replica slave

Indipendentemente dall'opzione che scegliamo, XtraBackup o mysqldump, se tutto è andato bene, in questo passaggio possiamo già attivare la replica nel nodo che sarà il nostro slave (galera1).

$ mysql> CHANGE MASTER TO MASTER_HOST = 'mysql1', MASTER_PORT = 3306, MASTER_USER = 'slave_user', MASTER_PASSWORD = 'slave_password', MASTER_AUTO_POSITION = 1;
$ mysql> START SLAVE;

Verifichiamo che lo slave funzioni:

mysql> SHOW SLAVE STATUS\G
       Slave_IO_Running: Yes
       Slave_SQL_Running: Yes

A questo punto, abbiamo qualcosa di simile al seguente:

Dopo che NewGalera1 è aggiornato, possiamo reindirizzare l'applicazione al nostro nuovo cluster galera e riconfigurare la replica asincrona.

Controllo cluster

Come accennato in precedenza, con ClusterControl possiamo svolgere molte delle attività sopra menzionate in pochi semplici clic. Dispone inoltre di opzioni di ripristino automatico, sia per i nodi che per il cluster. Vediamo alcune attività in cui può essere d'aiuto.

Per eseguire una distribuzione, seleziona semplicemente l'opzione "Distribuisci cluster di database" e segui le istruzioni visualizzate.

Possiamo scegliere tra diversi tipi di tecnologie e fornitori. Dobbiamo specificare Utente, Chiave o Password e la porta per la connessione tramite SSH ai nostri server. Abbiamo anche bisogno del nome per il nostro nuovo cluster e se vogliamo che ClusterControl installi per noi il software e le configurazioni corrispondenti.

Dopo aver impostato le informazioni di accesso SSH, dobbiamo definire i nodi nel nostro cluster. Possiamo anche specificare quale repository utilizzare. Dobbiamo aggiungere i nostri server al cluster che creeremo.

Possiamo monitorare lo stato della creazione del nostro nuovo cluster dal monitor attività ClusterControl.

Inoltre, possiamo eseguire un'importazione del nostro cluster o database corrente seguendo gli stessi passaggi. In questo caso ClusterControl non installerà il software del database, perché esiste già un database in esecuzione.

Per aggiungere uno slave di replica, è necessario fare clic su Azioni cluster, selezionare Aggiungi slave di replica e aggiungere le informazioni di accesso SSH del nuovo server. ClusterControl si connetterà al server per effettuare le configurazioni necessarie per questa azione.

Per trasformare uno o più nodi Galera in server master (come nel senso di produrre binlog), puoi andare su Node Actions e selezionare Enable Binary Logging.

I backup possono essere configurati con XtraBackup (completo o incrementale) e mysqldump e hai altre opzioni come caricare il backup nel cloud, crittografia, compressione, pianificazione e altro.

Per ripristinare il backup, vai alla scheda Backup e scegli l'opzione Ripristina, quindi seleziona in quale server desideri ripristinare.

Se hai uno slave e vuoi cambiare il master o ricostruire la replica, puoi andare su Node Actions e selezionare l'opzione.

Conclusione

Come abbiamo potuto vedere, abbiamo diversi modi per raggiungere il nostro obiettivo, alcuni più complessi, altri più user friendly, ma con ognuno di essi è possibile ricreare un cluster da uno slave asincrono. Xtrabackup ripristinerebbe più velocemente per volumi di dati più grandi. Per evitare errori dell'operatore (ad esempio, un'errata DROP TABLE), potresti anche utilizzare uno slave ritardato in modo da avere il tempo di interrompere la propagazione dell'istruzione.

Ci auguriamo che queste informazioni siano utili e che tu non debba mai usarle in produzione;)