Nätverksmigrering utan driftstopp med MySQL Galera Cluster med hjälp av relänod

Galera Clusters automatiska nodprovisionering förenklar komplexiteten i att skala ut ett databaskluster med garanterad datakonsistens. SST och IST förbättrar användbarheten av initial datasynkronisering utan att behöva manuellt säkerhetskopiera databasen och kopiera den till den nya noden. Kombinera detta med Galeras förmåga att tolerera olika nätverksinställningar (t.ex. WAN-replikering) så kan vi nu migrera databasen mellan olika isolerade nätverk utan avbrott i tjänsten.

I det här blogginlägget kommer vi att undersöka hur vi migrerar vårt MySQL Galera Cluster utan driftstopp. Vi kommer att flytta databasen från Amazon Web Service (AWS) EC2 till Google Cloud Platform (GCP) Compute Engine, med hjälp av en relänod. Observera att vi hade ett liknande blogginlägg tidigare, men det här använder ett annat tillvägagångssätt.

Följande diagram förenklar vår migreringsplan:

Förberedelse av den gamla webbplatsen

Eftersom båda platserna inte kan kommunicera med varandra på grund av säkerhetsgrupp- eller VPC-isolering måste vi ha en relänod för att överbrygga dessa två platser. Denna nod kan vara placerad på vilken plats som helst, men måste kunna ansluta till en eller flera noder på andra sidan på port 3306 (MySQL), 4444 (SST), 4567 (gcomm) och 4568 (IST). Här är vad vi redan har och hur vi kommer att skala den gamla webbplatsen:

Du kan också använda en befintlig Galera-nod (t.ex. den tredje noden) som relänod, så länge den har anslutning till andra sidan. Nackdelen är att klusterkapaciteten kommer att reduceras till två, eftersom en nod kommer att användas för SST och vidarebefordra Galera-replikeringsströmmen mellan platser. Beroende på datauppsättningens storlek och anslutningen mellan webbplatser kan detta leda till problem med databasens tillförlitlighet i det aktuella klustret.

Så vi kommer att använda en fjärde nod för att minska risken på det nuvarande produktionsklustret när vi synkroniserar till andra sidan. Skapa först en ny instans i AWS Dashboard med en offentlig IP-adress (så att den kan prata med omvärlden) och tillåt de nödvändiga Galera-kommunikationsportarna (TCP 3306, 4444, 4567-4568).

Distribuera den fjärde noden (relänoden) på den gamla platsen. Om du använder ClusterControl kan du helt enkelt använda "Lägg till nod"-funktionen för att skala ut klustret (glöm inte att ställa in lösenordslös SSH från ClusterControl-noden till denna fjärde värd i förväg):

Se till att relänoden är synkroniserad med det aktuella klustret och kan kommunicera till andra sidan.

Från den nya platsen kommer vi att ansluta till relänoden eftersom detta är den enda noden som har anslutning till omvärlden.

Ny webbplatsimplementering

På den nya webbplatsen kommer vi att distribuera en liknande installation med en ClusterControl-nod och tre-nods Galera Cluster. Båda webbplatserna måste använda samma MySQL-version. Här är vår arkitektur på den nya webbplatsen:

Med ClusterControl är den nya klusterimplementeringen bara ett par klick bort och en gratis funktion i community-utgåvan. Gå till ClusterControl -> Deploy Database Cluster -> MySQL Galera och följ distributionsguiden:

Klicka på Distribuera och övervaka framstegen under Aktivitet -> Jobb -> Skapa kluster. När du är klar bör du ha följande på instrumentpanelen:

Vid det här laget har du två separata Galera-kluster - 4 noder på den gamla platsen och 3 noder på den nya platsen.

Ansluter båda webbplatserna

På den nya platsen (GCP), välj en nod för att kommunicera med relänoden på den gamla platsen. Vi kommer att välja galera-gcp1 som kontakten till relänoden (galera-aws4). Följande diagram illustrerar vår överbryggningsplan:

De viktiga sakerna att konfigurera är följande parametrar:

wsrep_sst_donor :wsrep_node_name av donatornoden. På galera-gcp1 ställer du in donatorn på galera-aws4.
wsrep_sst_auth :SST-användaruppgifter i formatet användarnamn:lösenord måste följa den gamla webbplatsen (AWS).
wsrep_sst_receive_address :IP-adressen som kommer att ta emot SST på joinernoden. På galera-gcp1, ställ in detta till den offentliga IP-adressen för denna nod.
wsrep_cluster_address :Galera anslutningssträng. På galera-gcp1 lägger du till den offentliga IP-adressen för galera-aws4.
wsrep_provider_options :
- gmcast.segment:Standard är 0. Ställ in ett annat heltal på alla noder i GCP.

På relänoden (galera-aws4), hämta wsrep_node_name:

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

På galera-gcp1:s my.cnf, ställ in wsrep_sst_donor värde till relänodens wsrep_node_name och wsrep_sst_receive_address till den offentliga IP-adressen för galera-gcp1:
```
wsrep_sst_donor=10.0.0.13
wsrep_sst_receive_address=35.197.136.232
```
Se till att wsrep_sst_auth är på alla noder på GCP värdet är identiskt efter den gamla webbplatsen (AWS) och ändra Galera-segmentet till 1 (så att Galera vet att båda webbplatserna finns i olika nätverk):
```
wsrep_sst_auth=backupuser:mysecretP4ssW0rd
wsrep_provider_options="base_port=4567; gcache.size=512M; gmcast.segment=1"
```
På galera-gcp1, ställ in wsrep_cluster_address för att inkludera relänodens offentliga IP-adress:
```
wsrep_cluster_address=gcomm://10.148.0.2,10.148.0.3,10.148.0.4,13.229.247.149
```
**Ändra bara wsrep_cluster_address på galera-gcp1. Ändra inte denna parameter på galera-gcp2 och galera-gcp3.
Stoppa alla noder på GCP. Om du använder ClusterControl, gå till rullgardinsmenyn Cluster Actions -> Stop Cluster. Du måste också stänga av automatisk återställning på både kluster- och nodnivå, så ClusterControl kommer inte att försöka återställa de misslyckade noderna.

Nu synkroniseringsdelen. Starta galera-gcp1. Du kan se från MySQL-felloggen på donatornoden att SST initieras mellan relänoden (10.0.0.13) med en offentlig adress på 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.

Observera att galera-gcp1 vid denna tidpunkt kommer att översvämmas av följande rader:

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

Du kan lugnt ignorera denna varning eftersom galera-gcp1 fortsätter att försöka se de återstående noderna bortom relänoden på AWS.

När SST på galera-gcp1 är klar kommer ClusterControl på GCE inte att kunna ansluta databasnoderna på grund av saknade GRANTs (befintliga GRANTs har åsidosatts efter synkronisering från AWS). Så här är vad vi behöver göra efter att SST har slutförts på galera-gcp1:
```
mysql> GRANT ALL PRIVILEGES ON *.* TO [email protected]'10.148.0.5' IDENTIFIED BY 'cmon' WITH GRANT OPTION;
```
När detta är gjort kommer ClusterControl korrekt att rapportera tillståndet för galera-gcp1 som markerats nedan:
Den sista delen är att starta de återstående galera-gcp2 och galera-gcp3, en nod i taget. Gå till ClusterControl -> Noder -> välj noden -> Start Node. När alla noder är synkroniserade bör du få 7 som klusterstorlek:

Klustret fungerar nu på båda platserna och utskalningen är klar.

Avveckling

När migreringen är klar och alla noder är synkroniserade kan du börja byta din applikation till det nya klustret på GCP:

Vid denna tidpunkt replikeras MySQL-data till alla noder fram till avvecklingen. Replikeringsprestandan kommer att vara så bra som den längsta noden i klustret tillåter. Relänoden är kritisk, eftersom den sänder skrivuppsättningar till andra sidan. Ur applikationssynpunkt rekommenderas det att du bara skriver till en webbplats åt gången, vilket innebär att du måste börja omdirigera läser/skrivningar från AWS och servera dem från GCP-kluster istället.

För att avveckla de gamla databasnoderna och flytta till klustret på GCP, måste vi utföra en graciös avstängning (en nod i taget) på AWS. Det är viktigt att stänga av noderna på ett elegant sätt, eftersom AWS-webbplatsen har majoriteten av antalet noder (4/7) för detta kluster. Om du stänger av dem alla på en gång kommer klustret på GCP att gå till icke-primärt tillstånd, vilket tvingar klustret att vägra drift. Se till att den sista noden som ska stängas av på AWS-sidan är relänoden.

Glöm inte att uppdatera följande parametrar på galera-gcp1 i enlighet med detta:

wsrep_cluster_address - Ta bort relänodens offentliga IP-adress.
wsrep_sst_donor - Kommentera den här raden. Låt Galera automatiskt välja donatorn.
wsrep_sst_receive_address - Kommentera den här raden. Låt Galera automatiskt välja mottagningsgränssnittet.

Ditt Galera-kluster körs nu på en helt ny plattform, värdar och nätverk utan en sekunds driftstopp för din databastjänst under migreringen. Hur coolt är det?