Netwerkmigratie zonder uitvaltijd met MySQL Galera-cluster met behulp van Relay Node

De automatische node-provisioning van Galera Cluster vereenvoudigt de complexiteit van het opschalen van een databasecluster met gegarandeerde gegevensconsistentie. SST en IST verbeteren de bruikbaarheid van initiële gegevenssynchronisatie zonder de noodzaak om handmatig een back-up van de database te maken en deze naar het nieuwe knooppunt te kopiëren. Combineer dit met Galera's vermogen om verschillende netwerkconfiguraties te tolereren (bijv. WAN-replicatie), we kunnen nu de database migreren tussen verschillende geïsoleerde netwerken zonder onderbreking van de service.

In deze blogpost gaan we kijken hoe we onze MySQL Galera Cluster kunnen migreren zonder downtime. We zullen de database verplaatsen van Amazon Web Service (AWS) EC2 naar Google Cloud Platform (GCP) Compute Engine, met behulp van een relaisknooppunt. Merk op dat we in het verleden een soortgelijke blogpost hadden, maar deze gebruikt een andere benadering.

Het volgende diagram vereenvoudigt ons migratieplan:

Voorbereiding oude site

Aangezien beide sites niet met elkaar kunnen communiceren vanwege beveiligingsgroep of VPC-isolatie, hebben we een relaisknooppunt nodig om deze twee sites samen te overbruggen. Dit knooppunt kan zich op beide locaties bevinden, maar moet verbinding kunnen maken met een of meer knooppunten aan de andere kant op poort 3306 (MySQL), 4444 (SST), 4567 (gcomm) en 4568 (IST). Dit is wat we al hebben en hoe we de oude site gaan schalen:

U kunt ook een bestaand Galera-knooppunt gebruiken (bijvoorbeeld het derde knooppunt) als het relaisknooppunt, zolang het maar verbinding heeft met de andere kant. Het nadeel is dat de clustercapaciteit wordt teruggebracht tot twee, omdat één knooppunt wordt gebruikt voor SST en het doorgeven van de Galera-replicatiestroom tussen sites. Afhankelijk van de grootte van de dataset en de verbinding tussen sites, kan dit leiden tot problemen met de betrouwbaarheid van de database op het huidige cluster.

We gaan dus een vierde node gebruiken om het risico op het huidige productiecluster te verkleinen bij het synchroniseren met de andere kant. Maak eerst een nieuwe instantie in het AWS-dashboard met een openbaar IP-adres (zodat het met de buitenwereld kan praten) en laat de vereiste Galera-communicatiepoorten toe (TCP 3306, 4444, 4567-4568).

Implementeer het vierde knooppunt (relay-knooppunt) op de oude site. Als u ClusterControl gebruikt, kunt u eenvoudig de functie "Node toevoegen" gebruiken om het cluster uit te schalen (vergeet niet vooraf wachtwoordloze SSH van ClusterControl-knooppunt naar deze vierde host in te stellen):

Zorg ervoor dat het relaisknooppunt gesynchroniseerd is met het huidige cluster en kan communiceren met de andere kant.

Vanaf de nieuwe site gaan we verbinding maken met het relaisknooppunt, omdat dit het enige knooppunt is dat verbinding heeft met de buitenwereld.

Nieuwe site-implementatie

Op de nieuwe site zullen we een vergelijkbare opstelling implementeren met één ClusterControl-knooppunt en Galera-cluster met drie knooppunten. Beide sites moeten dezelfde MySQL-versie gebruiken. Hier is onze architectuur op de nieuwe site:

Met ClusterControl is de nieuwe clusterimplementatie slechts een paar klikken verwijderd en een gratis functie in de community-editie. Ga naar ClusterControl -> Databasecluster implementeren -> MySQL Galera en volg de implementatiewizard:

Klik op Implementeren en volg de voortgang onder Activiteit -> Taken -> Cluster maken. Als u klaar bent, zou u het volgende op het dashboard moeten hebben:

Op dit moment heeft u twee afzonderlijke Galera-clusters - 4 knooppunten op de oude site en 3 knooppunten op de nieuwe site.

Beide sites verbinden

Kies op de nieuwe site (GCP) één knooppunt om te communiceren met het relaisknooppunt op de oude site. We gaan galera-gcp1 kiezen als de connector naar het relaisknooppunt (galera-aws4). Het volgende diagram illustreert ons overbruggingsplan:

De belangrijkste dingen om te configureren zijn de volgende parameters:

wsrep_sst_donor :De wsrep_node_name van de donorknoop. Stel op galera-gcp1 de donor in op galera-aws4.
wsrep_sst_auth :SST-gebruikersgegevens in gebruikersnaam:wachtwoord moeten de oude site (AWS) volgen.
wsrep_sst_receive_address :Het IP-adres dat SST zal ontvangen op het joiner-knooppunt. Stel op galera-gcp1 dit in op het openbare IP-adres van dit knooppunt.
wsrep_cluster_address :Galera-verbindingsreeks. Voeg op galera-gcp1 het openbare IP-adres van galera-aws4 toe.
wsrep_provider_options :
- gmcast.segment:standaard is 0. Stel een ander geheel getal in op alle knooppunten in GCP.

Op het relaisknooppunt (galera-aws4) haalt u de wsrep_node_name op:

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

Stel op my.cnf van galera-gcp1 wsrep_sst_donor in waarde toe aan de wsrep_node_name . van het relaisknooppunt en wsrep_sst_receive_address naar het openbare IP-adres van galera-gcp1:
```
wsrep_sst_donor=10.0.0.13
wsrep_sst_receive_address=35.197.136.232
```
Zorg ervoor dat op alle nodes op GCP de wsrep_sst_auth waarde is identiek volgens de oude site (AWS) en verander het Galera-segment in 1 (zodat Galera weet dat beide sites zich in verschillende netwerken bevinden):
```
wsrep_sst_auth=backupuser:mysecretP4ssW0rd
wsrep_provider_options="base_port=4567; gcache.size=512M; gmcast.segment=1"
```
Stel op galera-gcp1 het wsrep_cluster_address in om het openbare IP-adres van het relaisknooppunt op te nemen:
```
wsrep_cluster_address=gcomm://10.148.0.2,10.148.0.3,10.148.0.4,13.229.247.149
```
**Wijzig alleen wsrep_cluster_address op galera-gcp1. Wijzig deze parameter niet op galera-gcp2 en galera-gcp3.
Stop alle nodes op GCP. Als u ClusterControl gebruikt, gaat u naar de vervolgkeuzelijst Clusteracties -> Cluster stoppen. U moet ook automatisch herstel op zowel cluster- als knooppuntniveau uitschakelen, zodat ClusterControl niet zal proberen de mislukte knooppunten te herstellen.

Nu het synchronisatiegedeelte. Start galera-gcp1. U kunt in het MySQL-foutlogboek op het donorknooppunt zien dat SST wordt gestart tussen het relaisknooppunt (10.0.0.13) met behulp van een openbaar adres op 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.

Houd er rekening mee dat galera-gcp1 op dit moment wordt overspoeld met de volgende regels:

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

U kunt deze waarschuwing veilig negeren, aangezien galera-gcp1 blijft proberen de resterende knooppunten voorbij het relaisknooppunt op AWS te zien.

Zodra SST op galera-gcp1 is voltooid, kan ClusterControl op GCE geen verbinding maken met de databaseknooppunten vanwege ontbrekende GRANT's (bestaande GRANT's zijn overschreven na synchronisatie vanaf AWS). Dus dit is wat we moeten doen nadat SST is voltooid op galera-gcp1:
```
mysql> GRANT ALL PRIVILEGES ON *.* TO [email protected]'10.148.0.5' IDENTIFIED BY 'cmon' WITH GRANT OPTION;
```
Zodra dit is gebeurd, zal ClusterControl de status van galera-gcp1 correct rapporteren, zoals hieronder aangegeven:
Het laatste deel is om de resterende galera-gcp2 en galera-gcp3 te starten, één knooppunt tegelijk. Ga naar ClusterControl -> Nodes -> kies de node -> Start Node. Zodra alle knooppunten zijn gesynchroniseerd, zou u 7 moeten krijgen als de clustergrootte:

Het cluster werkt nu op beide sites en het uitschalen is voltooid.

Ontmanteling

Zodra de migratie is voltooid en alle nodes zijn gesynchroniseerd, kunt u beginnen met het overschakelen van uw app naar het nieuwe cluster op GCP:

Op dit punt worden MySQL-gegevens naar alle knooppunten gerepliceerd tot ze buiten gebruik worden gesteld. De replicatieprestaties zijn zo goed als het verste knooppunt in het cluster toestaat. Het relaisknooppunt is van cruciaal belang, omdat het schrijfsets naar de andere kant uitzendt. Vanuit het oogpunt van de applicatie wordt aanbevolen om naar slechts één site tegelijk te schrijven, wat betekent dat u lees- en schrijfbewerkingen van AWS moet omleiden en in plaats daarvan moet dienen vanuit het GCP-cluster.

Om de oude databaseknooppunten buiten gebruik te stellen en naar het cluster op GCP te verplaatsen, moeten we een elegante afsluiting uitvoeren (één knooppunt tegelijk) op AWS. Het is belangrijk om de nodes netjes af te sluiten, aangezien de AWS-site het grootste aantal nodes (4/7) voor dit cluster bevat. Als u ze allemaal tegelijk afsluit, gaat het cluster op GCP naar de niet-primaire status, waardoor het cluster gedwongen wordt de bewerking te weigeren. Zorg ervoor dat het laatste knooppunt aan de AWS-kant het relaisknooppunt is.

Vergeet niet de volgende parameters op galera-gcp1 dienovereenkomstig bij te werken:

wsrep_cluster_address - Verwijder het openbare IP-adres van het relaisknooppunt.
wsrep_sst_donor - Reageer op deze regel. Laat Galera automatisch de donor kiezen.
wsrep_sst_receive_address - Reageer op deze regel. Laat Galera automatisch de ontvangende interface kiezen.

Uw Galera Cluster draait nu op een volledig nieuw platform, hosts en netwerk zonder een seconde downtime naar uw databaseservice tijdens de migratie. Hoe cool is dat?