Migrazione della rete zero tempi di inattività con MySQL Galera Cluster utilizzando il nodo di inoltro

Il provisioning automatico dei nodi di Galera Cluster semplifica la complessità della scalabilità orizzontale di un cluster di database con coerenza dei dati garantita. SST e IST migliorano l'usabilità della sincronizzazione dei dati iniziale senza la necessità di eseguire manualmente il backup del database e copiarlo nel nuovo nodo. Combina questo con la capacità di Galera di tollerare diverse configurazioni di rete (ad es. replica WAN), ora possiamo migrare il database tra diverse reti isolate senza interruzioni del servizio.

In questo post del blog, esamineremo come migrare il nostro MySQL Galera Cluster senza tempi di inattività. Sposteremo il database da Amazon Web Service (AWS) EC2 a Google Cloud Platform (GCP) Compute Engine, con l'aiuto di un nodo di inoltro. Tieni presente che in passato abbiamo avuto un post sul blog simile, ma questo utilizza un approccio diverso.

Il diagramma seguente semplifica il nostro piano di migrazione:

Preparazione del vecchio sito

Poiché entrambi i siti non possono comunicare tra loro a causa dell'isolamento del gruppo di sicurezza o del VPC, è necessario disporre di un nodo di inoltro per collegare questi due siti. Questo nodo può essere posizionato su entrambi i siti, ma deve essere in grado di connettersi a uno o più nodi sull'altro lato sulla porta 3306 (MySQL), 4444 (SST), 4567 (gcomm) e 4568 (IST). Ecco cosa abbiamo già e come ridimensioneremo il vecchio sito:

Puoi anche utilizzare un nodo Galera esistente (ad es. il terzo nodo) come nodo di inoltro, purché abbia connettività all'altro lato. Lo svantaggio è che la capacità del cluster verrà ridotta a due, perché un nodo verrà utilizzato per SST e l'inoltro del flusso di replica Galera tra i siti. A seconda delle dimensioni del set di dati e della connessione tra i siti, ciò può introdurre problemi di affidabilità del database nel cluster corrente.

Pertanto, utilizzeremo un quarto nodo, per ridurre il rischio sul cluster di produzione corrente durante la sincronizzazione con l'altro lato. Innanzitutto, crea una nuova istanza in AWS Dashboard con un indirizzo IP pubblico (in modo che possa parlare con il mondo esterno) e consenti le porte di comunicazione Galera richieste (TCP 3306, 4444, 4567-4568).

Distribuire il quarto nodo (nodo di inoltro) sul vecchio sito. Se stai utilizzando ClusterControl, puoi semplicemente utilizzare la funzione "Aggiungi nodo" per ridimensionare il cluster (non dimenticare di configurare in anticipo SSH senza password dal nodo ClusterControl a questo quarto host):

Assicurati che il nodo di inoltro sia sincronizzato con il cluster corrente e sia in grado di comunicare con l'altro lato.

Dal nuovo sito, ci collegheremo al nodo di inoltro poiché questo è l'unico nodo che ha connettività con il mondo esterno.

Nuova distribuzione del sito

Nel nuovo sito, implementeremo una configurazione simile con un nodo ClusterControl e un cluster Galera a tre nodi. Entrambi i siti devono utilizzare la stessa versione di MySQL. Ecco la nostra architettura sul nuovo sito:

Con ClusterControl, la nuova implementazione del cluster è solo un paio di clic e una funzionalità gratuita nell'edizione community. Vai a ClusterControl -> Distribuisci cluster di database -> MySQL Galera e segui la procedura guidata di distribuzione:

Fare clic su Distribuisci e monitorare l'avanzamento in Attività -> Lavori -> Crea cluster. Una volta terminato, dovresti avere quanto segue sulla dashboard:

A questo punto, hai due cluster Galera separati:4 nodi nel vecchio sito e 3 nodi nel nuovo sito.

Collegamento di entrambi i siti

Nel nuovo sito (GCP), seleziona un nodo per comunicare con il nodo di inoltro nel vecchio sito. Sceglieremo galera-gcp1 come connettore per il nodo di inoltro (galera-aws4). Il diagramma seguente illustra il nostro piano di transizione:

Le cose importanti da configurare sono i seguenti parametri:

wsrep_sst_donar :Il wsrep_node_name del nodo donatore. In galera-gcp1, imposta il donatore su galera-aws4.
wsrep_sst_auth :le credenziali utente SST in formato nome utente:password devono seguire il vecchio sito (AWS).
wsrep_sst_receive_address :l'indirizzo IP che riceverà l'SST sul nodo joiner. Su galera-gcp1, impostalo sull'indirizzo IP pubblico di questo nodo.
wsrep_cluster_address :Stringa di connessione Galera. Su galera-gcp1, aggiungi l'indirizzo IP pubblico di galera-aws4.
wsrep_provider_options :
- gmcast.segment:il valore predefinito è 0. Imposta un numero intero diverso su tutti i nodi in GCP.

Sul nodo di inoltro (galera-aws4), recupera wsrep_node_name:

$ mysql -uroot -p -e 'SELECT @@wsrep_node_name'
Enter password:
+-------------------+
| @@wsrep_node_name |
+-------------------+
| 10.0.0.13         |
+-------------------+

Su my.cnf di galera-gcp1, imposta wsrep_sst_donor valore al wsrep_node_name del nodo di inoltro e wsrep_sst_receive_address all'indirizzo IP pubblico di galera-gcp1:
```
wsrep_sst_donor=10.0.0.13
wsrep_sst_receive_address=35.197.136.232
```
Su tutti i nodi su GCP, assicurati di wsrep_sst_auth il valore è identico in base al vecchio sito (AWS) e cambia il segmento Galera in 1 (quindi Galera sa che entrambi i siti sono in reti diverse):
```
wsrep_sst_auth=backupuser:mysecretP4ssW0rd
wsrep_provider_options="base_port=4567; gcache.size=512M; gmcast.segment=1"
```
In galera-gcp1, imposta wsrep_cluster_address per includere l'indirizzo IP pubblico del nodo di inoltro:
```
wsrep_cluster_address=gcomm://10.148.0.2,10.148.0.3,10.148.0.4,13.229.247.149
```
**Modifica solo wsrep_cluster_address su galera-gcp1. Non modificare questo parametro su galera-gcp2 e galera-gcp3.
Arresta tutti i nodi su GCP. Se stai usando ClusterControl, vai al menu a tendina Cluster Actions -> Stop Cluster. È inoltre necessario disattivare il ripristino automatico sia a livello di cluster che di nodo, in modo che ClusterControl non tenti di ripristinare i nodi guasti.

Ora la parte di sincronizzazione. Avvia galera-gcp1. Puoi vedere dal log degli errori MySQL sul nodo donatore che SST viene avviato tra il nodo di inoltro (10.0.0.13) utilizzando un indirizzo pubblico su galera-gcp1 (35.197.136.232):

2017-12-19T13:58:04.765238Z 0 [Note] WSREP: Initiating SST/IST transfer on DONOR side (wsrep_sst_xtrabackup-v2 --role 'donor' --address '35.197.136.232:4444/xtrabackup_sst//1' --socket '/var/lib/mysql/m
ysql.sock' --datadir '/var/lib/mysql/' --defaults-file '/etc/my.cnf' --defaults-group-suffix ''   '' --gtid 'df23adb8-b567-11e7-8c50-a386c8cc7711:151181')
2017-12-19T13:58:04.765468Z 5 [Note] WSREP: DONOR thread signaled with 0
        2017-12-19T13:58:15.158757Z WSREP_SST: [INFO] Streaming the backup to joiner at 35.197.136.232 4444
2017-12-19T13:58:52.512143Z 0 [Note] WSREP: 1.0 (10.0.0.13): State transfer to 0.0 (10.148.0.2) complete.

Tieni presente che, a questo punto, galera-gcp1 verrà inondato dalle seguenti righe:

2017-12-19T13:32:47.111002Z 0 [Note] WSREP: (ed66842b, 'tcp://0.0.0.0:4567') connection to peer 00000000 with addr tcp://10.0.0.118:4567 timed out, no messages seen in PT3S
2017-12-19T13:32:48.111123Z 0 [Note] WSREP: (ed66842b, 'tcp://0.0.0.0:4567') connection to peer 00000000 with addr tcp://10.0.0.90:4567 timed out, no messages seen in PT3S
2017-12-19T13:32:50.611462Z 0 [Note] WSREP: (ed66842b, 'tcp://0.0.0.0:4567') connection to peer 00000000 with addr tcp://10.0.0.25:4567 timed out, no messages seen in PT3S

Puoi tranquillamente ignorare questo avviso poiché galera-gcp1 continua a provare a vedere i nodi rimanenti oltre il nodo di inoltro su AWS.

Una volta completato l'SST su galera-gcp1, ClusterControl su GCE non sarà in grado di connettere i nodi del database, a causa di GRANT mancanti (le GRANT esistenti sono state sovrascritte dopo la sincronizzazione da AWS). Quindi ecco cosa dobbiamo fare dopo il completamento di SST su galera-gcp1:
```
mysql> GRANT ALL PRIVILEGES ON *.* TO [email protected]'10.148.0.5' IDENTIFIED BY 'cmon' WITH GRANT OPTION;
```
Fatto ciò, ClusterControl riporterà correttamente lo stato di galera-gcp1 come evidenziato di seguito:
L'ultima parte consiste nell'avviare i restanti galera-gcp2 e galera-gcp3, un nodo alla volta. Vai a ClusterControl -> Nodi -> scegli il nodo -> Avvia nodo. Una volta sincronizzati tutti i nodi, dovresti ottenere 7 come dimensione del cluster:

Il cluster ora funziona su entrambi i siti e la scalabilità orizzontale è completa.

Disattivazione

Una volta completata la migrazione e sincronizzati tutti i nodi, puoi iniziare a passare la tua applicazione al nuovo cluster su GCP:

A questo punto i dati MySQL vengono replicati su tutti i nodi fino al decommissioning. Le prestazioni di replica saranno le stesse consentite dal nodo più lontano nel cluster. Il nodo di inoltro è fondamentale, poiché trasmette i set di scritture sull'altro lato. Dal punto di vista dell'applicazione, si consiglia di scrivere su un solo sito alla volta, il che significa che dovrai iniziare a reindirizzare letture/scritture da AWS e servirle invece dal cluster GCP.

Per disattivare i vecchi nodi del database e passare al cluster su GCP, dobbiamo eseguire un arresto regolare (un nodo alla volta) su AWS. È importante arrestare i nodi in modo corretto, poiché il sito AWS detiene il maggior numero di nodi (4/7) per questo cluster. L'arresto di tutti in una volta farà sì che il cluster su GCP passi allo stato non primario, costringendo il cluster a rifiutare l'operazione. Assicurati che l'ultimo nodo da chiudere sul lato AWS sia il nodo di inoltro.

Non dimenticare di aggiornare di conseguenza i seguenti parametri su galera-gcp1:

wsrep_cluster_address - Rimuovere l'indirizzo IP pubblico del nodo di inoltro.
wsrep_sst_donar - Commenta questa riga. Lascia che Galera scelga automaticamente il donatore.
wsrep_sst_receive_address - Commenta questa riga. Lascia che Galera scelga automaticamente l'interfaccia di ricezione.

Il tuo Galera Cluster è ora in esecuzione su una piattaforma, host e rete completamente nuovi senza un secondo di inattività del servizio database durante la migrazione. Quanto è bello?