Nul nedetid netværksmigrering med MySQL Galera Cluster ved hjælp af relay node

Galera Clusters automatiske node-provisionering forenkler kompleksiteten ved at udskalere en databaseklynge med garanteret datakonsistens. SST og IST forbedrer anvendeligheden af indledende datasynkronisering uden behov for manuelt at sikkerhedskopiere databasen og kopiere den til den nye node. Kombiner dette med Galeras evne til at tolerere forskellige netværksopsætninger (f.eks. WAN-replikering), så kan vi nu migrere databasen mellem forskellige isolerede netværk uden serviceafbrydelser.

I dette blogindlæg skal vi se på, hvordan vi migrerer vores MySQL Galera Cluster uden nedetid. Vi vil flytte databasen fra Amazon Web Service (AWS) EC2 til Google Cloud Platform (GCP) Compute Engine ved hjælp af en relæknude. Bemærk, at vi havde et lignende blogindlæg tidligere, men dette bruger en anden tilgang.

Følgende diagram forenkler vores migreringsplan:

Forberedelse af gammelt websted

Da begge steder ikke kan kommunikere med hinanden på grund af sikkerhedsgruppe- eller VPC-isolation, skal vi have en relæknude til at bygge bro mellem disse to steder. Denne node kan være placeret på begge steder, men skal kunne oprette forbindelse til en eller flere noder på den anden side på port 3306 (MySQL), 4444 (SST), 4567 (gcomm) og 4568 (IST). Her er, hvad vi allerede har, og hvordan vi vil skalere det gamle websted:

Du kan også bruge en eksisterende Galera-knude (f.eks. den tredje knude) som relæknude, så længe den har forbindelse til den anden side. Ulempen er, at klyngekapaciteten vil blive reduceret til to, fordi en node vil blive brugt til SST og videresende Galera-replikationsstrømmen mellem steder. Afhængigt af datasættets størrelse og forbindelsen mellem websteder kan dette medføre problemer med databasepålidelighed på den aktuelle klynge.

Så vi vil bruge en fjerde node for at reducere risikoen på den nuværende produktionsklynge, når vi synkroniserer til den anden side. Først skal du oprette en ny instans i AWS Dashboard med en offentlig IP-adresse (så den kan tale med omverdenen) og tillade de nødvendige Galera-kommunikationsporte (TCP 3306, 4444, 4567-4568).

Implementer den fjerde knude (relæknude) på det gamle websted. Hvis du bruger ClusterControl, kan du blot bruge "Add Node"-funktionen til at skalere klyngen ud (glem ikke at konfigurere adgangskodefri SSH fra ClusterControl-knude til denne fjerde vært på forhånd):

Sørg for, at relæknuden er synkroniseret med den aktuelle klynge og er i stand til at kommunikere til den anden side.

Fra det nye websted vil vi oprette forbindelse til relæknuden, da dette er den eneste knude, der har forbindelse til omverdenen.

Ny webstedsimplementering

På det nye websted vil vi implementere en lignende opsætning med én ClusterControl-node og tre-node Galera Cluster. Begge sider skal bruge den samme MySQL-version. Her er vores arkitektur på det nye websted:

Med ClusterControl er den nye klyngeimplementering kun et par klik væk og en gratis funktion i community-udgaven. Gå til ClusterControl -> Deploy Database Cluster -> MySQL Galera, og følg implementeringsguiden:

Klik på Implementer og overvåg fremskridtene under Aktivitet -> Jobs -> Opret klynge. Når du er færdig, bør du have følgende på dashboardet:

På dette tidspunkt har du to separate Galera-klynger - 4 noder på det gamle sted og 3 noder på det nye sted.

Forbinder begge websteder

På det nye websted (GCP) skal du vælge en knude til at kommunikere med relæknuden på det gamle websted. Vi vil vælge galera-gcp1 som forbindelsen til relæknuden (galera-aws4). Følgende diagram illustrerer vores brobygningsplan:

De vigtige ting at konfigurere er følgende parametre:

wsrep_sst_donor :wsrep_node_name af donorknuden. På galera-gcp1 skal du indstille donoren til galera-aws4.
wsrep_sst_auth :SST-brugeroplysninger i formatet brugernavn:adgangskode skal følge det gamle websted (AWS).
wsrep_sst_receive_address :IP-adressen, der vil modtage SST på joiner-noden. På galera-gcp1 skal du indstille dette til den offentlige IP-adresse for denne node.
wsrep_cluster_address :Galera forbindelsesstreng. På galera-gcp1 skal du tilføje den offentlige IP-adresse for galera-aws4.
wsrep_provider_options :
- gmcast.segment:Standard er 0. Indstil et andet heltal på alle noder i GCP.

På relæknuden (galera-aws4) skal du hente 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 skal du indstille wsrep_sst_donor værdi til relæknudepunktets wsrep_node_name og wsrep_sst_receive_address til den offentlige IP-adresse for galera-gcp1:
```
wsrep_sst_donor=10.0.0.13
wsrep_sst_receive_address=35.197.136.232
```
På alle noder på GCP skal du sikre dig wsrep_sst_auth værdien er identisk efter det gamle websted (AWS) og ændre Galera-segmentet til 1 (så Galera ved, at begge websteder er i forskellige netværk):
```
wsrep_sst_auth=backupuser:mysecretP4ssW0rd
wsrep_provider_options="base_port=4567; gcache.size=512M; gmcast.segment=1"
```
På galera-gcp1 skal du indstille wsrep_cluster_address for at inkludere relæknudepunktets offentlige IP-adresse:
```
wsrep_cluster_address=gcomm://10.148.0.2,10.148.0.3,10.148.0.4,13.229.247.149
```
**Rediger kun wsrep_cluster_address på galera-gcp1. Rediger ikke denne parameter på galera-gcp2 og galera-gcp3.
Stop alle noder på GCP. Hvis du bruger ClusterControl, skal du gå til Cluster Actions dropdown -> Stop Cluster. Du er også forpligtet til at slå automatisk gendannelse fra på både klynge- og nodeniveau, så ClusterControl vil ikke forsøge at gendanne de mislykkede noder.

Nu synkroniseringsdelen. Start galera-gcp1. Du kan se fra MySQL-fejlloggen på donornoden, at SST initieres mellem relæknuden (10.0.0.13) ved hjælp af en offentlig adresse 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.

Vær opmærksom på, at galera-gcp1 på dette tidspunkt vil blive oversvømmet med følgende linjer:

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 roligt ignorere denne advarsel, da galera-gcp1 bliver ved med at prøve at se de resterende noder ud over relæknuden på AWS.

Når først SST på galera-gcp1 er fuldført, vil ClusterControl på GCE ikke være i stand til at forbinde databasenoderne på grund af manglende GRANT'er (eksisterende GRANT'er er blevet tilsidesat efter synkronisering fra AWS). Så her er hvad vi skal gøre efter SST er fuldført på galera-gcp1:
```
mysql> GRANT ALL PRIVILEGES ON *.* TO [email protected]'10.148.0.5' IDENTIFIED BY 'cmon' WITH GRANT OPTION;
```
Når dette er gjort, vil ClusterControl korrekt rapportere status for galera-gcp1 som fremhævet nedenfor:
Den sidste del er at starte de resterende galera-gcp2 og galera-gcp3, en node ad gangen. Gå til ClusterControl -> Noder -> vælg noden -> Start Node. Når alle noder er synkroniseret, bør du få 7 som klyngestørrelse:

Klyngen fungerer nu på begge steder, og udskaleringen er fuldført.

Nedlæggelse

Når migreringen er fuldført, og alle noder er synkroniseret, kan du begynde at skifte din applikation til den nye klynge på GCP:

På dette tidspunkt replikeres MySQL-data til alle noder indtil dekommissionering. Replikeringsydelsen vil være så god, som den fjerneste node i klyngen tillader. Relæknudepunktet er kritisk, da det udsender skrivesæt til den anden side. Fra et applikationssynspunkt anbefales det kun at skrive til ét websted ad gangen, hvilket betyder, at du bliver nødt til at begynde at omdirigere læsninger/skrivninger fra AWS og betjene dem fra GCP-klyngen i stedet.

For at afvikle de gamle databasenoder og flytte til klyngen på GCP, skal vi udføre en yndefuld nedlukning (en node ad gangen) på AWS. Det er vigtigt at lukke knudepunkterne elegant ned, da AWS-stedet har størstedelen af antallet af noder (4/7) for denne klynge. Lukning af dem alle på én gang vil få klyngen på GCP til at gå i ikke-primær tilstand, hvilket tvinger klyngen til at nægte drift. Sørg for, at den sidste knude, der skal lukkes ned på AWS-siden, er relæknuden.

Glem ikke at opdatere følgende parametre på galera-gcp1 i overensstemmelse hermed:

wsrep_cluster_address - Fjern den offentlige IP-adresse for relæknuden.
wsrep_sst_donor - Kommenter denne linje. Lad Galera automatisk vælge donoren.
wsrep_sst_receive_address - Kommenter denne linje. Lad Galera automatisk vælge den modtagende grænseflade.

Din Galera Cluster kører nu på en helt ny platform, værter og netværk uden et sekunds nedetid til din databasetjeneste under migreringen. Hvor fedt er det?