Netzwerkmigration ohne Ausfallzeit mit MySQL Galera-Cluster unter Verwendung von Relay-Knoten

Die automatische Knotenbereitstellung von Galera Cluster vereinfacht die Komplexität der Skalierung eines Datenbankclusters mit garantierter Datenkonsistenz. SST und IST verbessern die Benutzerfreundlichkeit der anfänglichen Datensynchronisierung, ohne dass die Datenbank manuell gesichert und auf den neuen Knoten kopiert werden muss. In Kombination mit der Fähigkeit von Galera, verschiedene Netzwerkkonfigurationen (z. B. WAN-Replikation) zu tolerieren, können wir jetzt die Datenbank zwischen verschiedenen isolierten Netzwerken ohne Dienstunterbrechung migrieren.

In diesem Blogbeitrag werden wir untersuchen, wie Sie unseren MySQL Galera-Cluster ohne Ausfallzeiten migrieren können. Wir werden die Datenbank mit Hilfe eines Relay-Knotens von Amazon Web Service (AWS) EC2 auf Google Cloud Platform (GCP) Compute Engine verschieben. Beachten Sie, dass wir in der Vergangenheit einen ähnlichen Blogbeitrag hatten, dieser jedoch einen anderen Ansatz verwendet.

Das folgende Diagramm vereinfacht unseren Migrationsplan:

Alte Standortvorbereitung

Da beide Sites aufgrund der Sicherheitsgruppen- oder VPC-Isolierung nicht miteinander kommunizieren können, benötigen wir einen Relay-Knoten, um diese beiden Sites miteinander zu überbrücken. Dieser Knoten kann sich auf beiden Seiten befinden, muss sich aber mit einem oder mehreren Knoten auf der anderen Seite auf Port 3306 (MySQL), 4444 (SST), 4567 (gcomm) und 4568 (IST) verbinden können. Folgendes haben wir bereits und wie werden wir die alte Website skalieren:

Sie können auch einen vorhandenen Galera-Knoten (z. B. den dritten Knoten) als Relaisknoten verwenden, solange er eine Verbindung zur anderen Seite hat. Der Nachteil ist, dass die Clusterkapazität auf zwei reduziert wird, da ein Knoten für SST und die Weiterleitung des Galera-Replikationsstroms zwischen den Standorten verwendet wird. Abhängig von der Größe des Datensatzes und der Verbindung zwischen Standorten kann dies zu Problemen mit der Datenbankzuverlässigkeit im aktuellen Cluster führen.

Wir werden also einen vierten Knoten verwenden, um das Risiko auf dem aktuellen Produktionscluster bei der Synchronisierung mit der anderen Seite zu verringern. Erstellen Sie zunächst im AWS-Dashboard eine neue Instanz mit einer öffentlichen IP-Adresse (damit sie mit der Außenwelt kommunizieren kann) und lassen Sie die erforderlichen Galera-Kommunikationsports (TCP 3306, 4444, 4567-4568) zu.

Stellen Sie den vierten Knoten (Relay-Knoten) am alten Standort bereit. Wenn Sie ClusterControl verwenden, können Sie einfach die Funktion „Knoten hinzufügen“ verwenden, um den Cluster aufzuskalieren (vergessen Sie nicht, zuvor passwortloses SSH vom ClusterControl-Knoten zu diesem vierten Host einzurichten):

Stellen Sie sicher, dass der Relay-Knoten mit dem aktuellen Cluster synchronisiert ist und mit der anderen Seite kommunizieren kann.

Von der neuen Site aus werden wir uns mit dem Relay-Knoten verbinden, da dies der einzige Knoten ist, der eine Verbindung zur Außenwelt hat.

Neue Site-Bereitstellung

Auf der neuen Website werden wir ein ähnliches Setup mit einem ClusterControl-Knoten und einem Galera-Cluster mit drei Knoten bereitstellen. Beide Sites müssen dieselbe MySQL-Version verwenden. Hier ist unsere Architektur auf der neuen Seite:

Mit ClusterControl ist die neue Cluster-Bereitstellung nur ein paar Klicks entfernt und eine kostenlose Funktion in der Community Edition. Gehen Sie zu ClusterControl -> Deploy Database Cluster -> MySQL Galera und folgen Sie dem Bereitstellungsassistenten:

Klicken Sie auf Bereitstellen und überwachen Sie den Fortschritt unter Aktivität -> Jobs -> Cluster erstellen. Sobald Sie fertig sind, sollten Sie Folgendes auf dem Dashboard haben:

Zu diesem Zeitpunkt haben Sie zwei separate Galera-Cluster – 4 Knoten am alten Standort und 3 Knoten am neuen Standort.

Beide Seiten verbinden

Wählen Sie auf der neuen Site (GCP) einen Knoten aus, um mit dem Relay-Knoten auf der alten Site zu kommunizieren. Wir werden galera-gcp1 als Konnektor zum Relay-Knoten (galera-aws4) auswählen. Das folgende Diagramm veranschaulicht unseren Überbrückungsplan:

Die wichtigsten Dinge, die konfiguriert werden müssen, sind die folgenden Parameter:

wsrep_sst_donor :Der wsrep_node_name des Spenderknotens. Setzen Sie auf galera-gcp1 den Donor auf galera-aws4.
wsrep_sst_auth :SST-Benutzeranmeldeinformationen im Format Benutzername:Passwort müssen der alten Site (AWS) folgen.
wsrep_sst_receive_address :Die IP-Adresse, die SST auf dem Joiner-Knoten empfängt. Setzen Sie dies auf galera-gcp1 auf die öffentliche IP-Adresse dieses Knotens.
wsrep_cluster_address :Galera-Verbindungszeichenfolge. Fügen Sie auf galera-gcp1 die öffentliche IP-Adresse von galera-aws4 hinzu.
wsrep_provider_options :
- gmcast.segment:Standard ist 0. Legen Sie für alle Knoten in GCP eine andere Ganzzahl fest.

Rufen Sie auf dem Relay-Knoten (galera-aws4) den wsrep_node_name:

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

Legen Sie in my.cnf von galera-gcp1 wsrep_sst_donor fest -Wert zum wsrep_node_name des Relay-Knotens und wsrep_sst_receive_address an die öffentliche IP-Adresse von galera-gcp1:
```
wsrep_sst_donor=10.0.0.13
wsrep_sst_receive_address=35.197.136.232
```
Stellen Sie auf allen Knoten auf der GCP sicher, dass wsrep_sst_auth -Wert nach der alten Site (AWS) identisch ist und das Galera-Segment auf 1 ändern (damit Galera weiß, dass sich beide Sites in unterschiedlichen Netzwerken befinden):
```
wsrep_sst_auth=backupuser:mysecretP4ssW0rd
wsrep_provider_options="base_port=4567; gcache.size=512M; gmcast.segment=1"
```
Legen Sie auf galera-gcp1 die wsrep_cluster_address fest um die öffentliche IP-Adresse des Relay-Knotens einzuschließen:
```
wsrep_cluster_address=gcomm://10.148.0.2,10.148.0.3,10.148.0.4,13.229.247.149
```
**Ändern Sie nur wsrep_cluster_address auf galera-gcp1. Ändern Sie diesen Parameter nicht auf galera-gcp2 und galera-gcp3.
Beenden Sie alle Knoten auf der GCP. Wenn Sie ClusterControl verwenden, gehen Sie zur Dropdown-Liste Cluster-Aktionen -> Cluster stoppen. Außerdem müssen Sie die automatische Wiederherstellung sowohl auf Cluster- als auch auf Knotenebene deaktivieren, damit ClusterControl nicht versucht, die ausgefallenen Knoten wiederherzustellen.

Jetzt der Synchronisierungsteil. Starten Sie galera-gcp1. Sie können aus dem MySQL-Fehlerprotokoll auf dem Donor-Knoten ersehen, dass SST zwischen dem Relay-Knoten (10.0.0.13) unter Verwendung einer öffentlichen Adresse auf galera-gcp1 (35.197.136.232) initiiert wird:

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.

Beachten Sie, dass zu diesem Zeitpunkt galera-gcp1 mit folgenden Zeilen überflutet wird:

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

Sie können diese Warnung ignorieren, da galera-gcp1 weiterhin versucht, die verbleibenden Knoten hinter dem Relay-Knoten auf AWS zu sehen.

Sobald SST auf galera-gcp1 abgeschlossen ist, kann ClusterControl auf GCE die Datenbankknoten aufgrund fehlender GRANTs nicht mehr verbinden (vorhandene GRANTs wurden nach der Synchronisierung von AWS überschrieben). Folgendes müssen wir also tun, nachdem SST auf galera-gcp1 abgeschlossen ist:
```
mysql> GRANT ALL PRIVILEGES ON *.* TO [email protected]'10.148.0.5' IDENTIFIED BY 'cmon' WITH GRANT OPTION;
```
Sobald dies erledigt ist, meldet ClusterControl den Status von galera-gcp1 korrekt, wie unten hervorgehoben:
Der letzte Teil besteht darin, die verbleibenden galera-gcp2 und galera-gcp3 zu starten, einen Knoten nach dem anderen. Gehen Sie zu ClusterControl -> Nodes -> wählen Sie den Node -> Start Node. Sobald alle Knoten synchronisiert sind, sollten Sie 7 als Clustergröße erhalten:

Der Cluster wird jetzt an beiden Standorten betrieben und die horizontale Skalierung ist abgeschlossen.

Außerbetriebnahme

Sobald die Migration abgeschlossen ist und alle Knoten synchronisiert sind, können Sie damit beginnen, Ihre Anwendung auf den neuen Cluster auf der GCP umzustellen:

An diesem Punkt werden MySQL-Daten bis zur Außerbetriebnahme auf alle Knoten repliziert. Die Replikationsleistung ist so gut, wie es der am weitesten entfernte Knoten im Cluster zulässt. Der Relaisknoten ist kritisch, da er Writesets an die andere Seite sendet. Aus Sicht der Anwendung wird empfohlen, jeweils nur auf eine Site zu schreiben, was bedeutet, dass Sie beginnen müssen, Lese-/Schreibvorgänge von AWS umzuleiten und sie stattdessen vom GCP-Cluster bereitzustellen.

Um die alten Datenbankknoten außer Betrieb zu nehmen und zum Cluster auf der GCP zu wechseln, müssen wir auf AWS ein ordnungsgemäßes Herunterfahren (einen Knoten nach dem anderen) durchführen. Es ist wichtig, die Knoten ordnungsgemäß herunterzufahren, da die AWS-Site die Mehrheit der Knoten (4/7) für diesen Cluster enthält. Wenn Sie alle auf einmal herunterfahren, wechselt der Cluster auf der GCP in den nicht primären Zustand, wodurch der Cluster gezwungen wird, den Vorgang abzulehnen. Stellen Sie sicher, dass der letzte Knoten, der auf der AWS-Seite heruntergefahren wird, der Relay-Knoten ist.

Vergessen Sie nicht, die folgenden Parameter auf galera-gcp1 entsprechend zu aktualisieren:

wsrep_cluster_address - Entfernen Sie die öffentliche IP-Adresse des Relay-Knotens.
wsrep_sst_donor - Kommentieren Sie diese Zeile. Lassen Sie Galera den Spender automatisch auswählen.
wsrep_sst_receive_address - Kommentieren Sie diese Zeile. Lassen Sie Galera die Empfangsschnittstelle automatisch auswählen.

Ihr Galera-Cluster läuft jetzt auf einer völlig neuen Plattform, Hosts und einem neuen Netzwerk ohne eine Sekunde Ausfallzeit Ihres Datenbankdienstes während der Migration. Wie cool ist das?