Come configurare la replica asincrona dal cluster Galera al server MySQL autonomo con GTID

La replica ibrida, ovvero la combinazione di Galera e la replica asincrona di MySQL nella stessa configurazione, è diventata molto più semplice da quando GTID è stato introdotto in MySQL 5.6. Sebbene fosse abbastanza semplice replicare da un server MySQL autonomo a un cluster Galera, farlo al contrario (Galera → MySQL autonomo) è stato un po' più impegnativo. Almeno fino all'arrivo di GTID.

Ci sono alcuni buoni motivi per collegare uno slave asincrono a un cluster Galera. Per prima cosa, le query di tipo OLAP/di reporting di lunga durata su un nodo Galera potrebbero rallentare un intero cluster, se il carico di reporting è così intenso che il nodo deve impegnarsi considerevolmente per affrontarlo. Pertanto, le query di report possono essere inviate a un server autonomo, isolando efficacemente Galera dal carico di report. In un approccio con cinture e bretelle, uno slave asincrono può anche fungere da backup live remoto.

In questo post del blog, ti mostreremo come replicare un cluster Galera su un server MySQL con GTID e come eseguire il failover della replica in caso di errore del nodo master.

Replica ibrida in MySQL 5.5

In MySQL 5.5, la ripresa di una replica interrotta richiede di determinare l'ultimo file di registro binario e la posizione, che sono distinti su tutti i nodi Galera se è abilitata la registrazione binaria. Possiamo illustrare questa situazione con la figura seguente:

Se il master MySQL si guasta, la replica si interrompe e lo slave dovrà passare a un altro master. Sarà necessario selezionare un nuovo nodo Galera e determinare manualmente un nuovo file di registro binario e la posizione dell'ultima transazione eseguita dallo slave. Un'altra opzione è scaricare i dati dal nuovo nodo master, ripristinarli sullo slave e avviare la replica con il nuovo nodo master. Queste opzioni sono ovviamente fattibili, ma non molto pratiche nella produzione.

Come GTID risolve il problema

GTID (Global Transaction Identifier) ​​fornisce una migliore mappatura delle transazioni tra i nodi ed è supportato in MySQL 5.6. In Galera Cluster, tutti i nodi genereranno file binlog diversi. Gli eventi binlog sono gli stessi e nello stesso ordine, ma i nomi e gli offset dei file binlog possono variare. Con GTID, gli slave possono vedere una transazione univoca in arrivo da diversi master e questo potrebbe essere facilmente mappato nell'elenco di esecuzione degli slave se è necessario riavviare o riprendere la replica.

Tutte le informazioni necessarie per la sincronizzazione con il master sono ottenute direttamente dal flusso di replica. Ciò significa che quando si utilizzano GTID per la replica, non è necessario includere le opzioni MASTER_LOG_FILE o MASTER_LOG_POS nell'istruzione CHANGE MASTER TO. Occorre invece solo abilitare l'opzione MASTER_AUTO_POSITION. Puoi trovare maggiori dettagli sul GTID nella pagina della documentazione MySQL.

Impostazione manuale della replica ibrida

Assicurati che i nodi Galera (master) e gli slave siano in esecuzione su MySQL 5.6 prima di procedere con questa configurazione. Abbiamo un database chiamato sbtest in Galera, che replicheremo sul nodo slave.

1. Abilita le opzioni di replica richieste specificando le seguenti righe all'interno di my.cnf di ciascun nodo DB (incluso il nodo slave):

Per i nodi master (Galera):

gtid_mode=ON
log_bin=binlog
log_slave_updates=1
enforce_gtid_consistency
expire_logs_days=7
server_id=1         # 1 for master1, 2 for master2, 3 for master3
binlog_format=ROW

Per nodo slave:

gtid_mode=ON
log_bin=binlog
log_slave_updates=1
enforce_gtid_consistency
expire_logs_days=7
server_id=101         # 101 for slave
binlog_format=ROW
replicate_do_db=sbtest
slave_net_timeout=60

2. Eseguire un riavvio in sequenza del cluster del cluster Galera (da ClusterControl UI> Manage> Upgrade> Rolling Restart). Questo ricaricherà ogni nodo con le nuove configurazioni e abiliterà GTID. Riavvia anche lo slave.

3. Crea un utente di replica slave ed esegui la seguente istruzione su uno dei nodi Galera:

mysql> GRANT REPLICATION SLAVE ON *.* TO 'slave'@'%' IDENTIFIED BY 'slavepassword';

4. Accedi allo slave e scarica il database sbtest da uno dei nodi Galera:

$ mysqldump -uroot -p -h192.168.0.201 --single-transaction --skip-add-locks --triggers --routines --events sbtest > sbtest.sql

5. Ripristinare il file dump sul server slave:

$ mysql -uroot -p < sbtest.sql

6. Avvia la replica sul nodo slave:

mysql> STOP SLAVE;
mysql> CHANGE MASTER TO MASTER_HOST = '192.168.0.201', MASTER_PORT = 3306, MASTER_USER = 'slave', MASTER_PASSWORD = 'slavepassword', MASTER_AUTO_POSITION = 1;
mysql> START SLAVE;

Per verificare che la replica funzioni correttamente, esaminare l'output dello stato slave:

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

Configurazione della replica ibrida mediante ClusterControl

Nel paragrafo precedente abbiamo descritto tutti i passaggi necessari per abilitare i log binari, riavviare il cluster nodo per nodo, copiare i dati e quindi impostare la replica. La procedura è un compito noioso e puoi facilmente commettere errori in uno di questi passaggi. In ClusterControl abbiamo automatizzato tutti i passaggi necessari.

1. Per gli utenti ClusterControl, puoi accedere ai nodi nella pagina Nodi e abilitare la registrazione binaria.

Si aprirà una finestra di dialogo che ti consentirà di impostare la scadenza del log binario, abilitare il GTID e il riavvio automatico.

Questo avvia un processo, che scriverà in modo sicuro queste modifiche nella configurazione, creerà utenti di replica con le autorizzazioni appropriate e riavvierà il nodo in modo sicuro.

Ripeti questo processo per ogni nodo Galera nel cluster, finché tutti i nodi non indicano che sono master.

2. Aggiungi lo slave di replica asincrono al cluster

E questo è tutto ciò che devi fare. L'intero processo descritto nel paragrafo precedente è stato automatizzato da ClusterControl.

Cambia maestro

Se il master designato si interrompe, lo slave tenterà di riconnettersi di nuovo nel valore slave_net_timeout (la nostra configurazione è di 60 secondi - il valore predefinito è 1 ora). Dovresti vedere il seguente errore sullo stato dello slave:

       Last_IO_Errno: 2003
       Last_IO_Error: error reconnecting to master '[email protected]:3306' - retry-time: 60  retries: 1

Poiché utilizziamo Galera con GTID abilitato, il failover principale è supportato tramite ClusterControl quando Recupero automatico di cluster e nodi è stato abilitato. Indipendentemente dal fatto che il master si guasti a causa della connettività di rete o per qualsiasi altro motivo, ClusterControl eseguirà automaticamente il failover sull'altro nodo master più adatto nel cluster.

Se desideri eseguire il failover manualmente, cambia semplicemente il nodo master come segue:

mysql> STOP SLAVE;
mysql> CHANGE MASTER TO MASTER_HOST = '192.168.0.202', MASTER_PORT = 3306, MASTER_USER = 'slave', MASTER_PASSWORD = 'slavepassword', MASTER_AUTO_POSITION = 1;
mysql> START SLAVE;

In alcuni casi, potresti riscontrare un errore "Voce duplicata .. per chiave" dopo la modifica del nodo master:

       Last_Errno: 1062
       Last_Error: Could not execute Write_rows event on table sbtest.sbtest; Duplicate entry '1089775' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysqld-bin.000009, end_log_pos 85789000

Nelle versioni precedenti di MySQL, puoi semplicemente usare SET GLOBAL SQL_SLAVE_SKIP_COUNTER =n per saltare le istruzioni, ma non funziona con GTID. Miguel di Percona ha scritto un ottimo post sul blog su come riparare questo problema iniettando transazioni vuote.

Un altro approccio, per database più piccoli, potrebbe anche essere quello di ottenere un nuovo dump da uno qualsiasi dei nodi Galera disponibili, ripristinarlo e utilizzare l'istruzione RESET MASTER:

mysql> STOP SLAVE;
mysql> RESET MASTER;
mysql> DROP SCHEMA sbtest; CREATE SCHEMA sbtest; USE sbtest;
mysql> SOURCE /root/sbtest_from_galera2.sql; -- repeat step #4 above to get this dump
mysql> CHANGE MASTER TO MASTER_HOST = '192.168.0.202', MASTER_PORT = 3306, MASTER_USER = 'slave', MASTER_PASSWORD = 'slavepassword', MASTER_AUTO_POSITION = 1;
mysql> START SLAVE;

Puoi anche utilizzare pt-table-checksum per verificare l'integrità della replica, maggiori informazioni in questo post del blog.

Nota:poiché nella replica MySQL l'applicatore slave è ancora a thread singolo per impostazione predefinita, non aspettarti che le prestazioni della replica asincrona siano le stesse della replica parallela di Galera. Per MySQL 5.6 e 5.7 ci sono opzioni per eseguire la replica asincrona in parallelo sui nodi slave, ma in linea di principio questa replica dipende ancora dal corretto ordine delle transazioni all'interno dello stesso schema che avvenga. Se il carico di replica è intenso e continuo, lo slave lag continuerà a crescere. Abbiamo visto casi in cui lo schiavo non è mai riuscito a raggiungere il padrone.