In unserem vorherigen Blog haben wir gesehen, wie einfach der Einstieg in RDS für MySQL ist. Es ist eine bequeme Möglichkeit, MySQL bereitzustellen und zu verwenden, ohne sich Gedanken über den Betriebsaufwand machen zu müssen. Der Kompromiss ist jedoch eine reduzierte Kontrolle, da die Benutzer im Falle einer schlechten Leistung oder von Betriebsanomalien vollständig auf die Mitarbeiter von Amazon angewiesen sind. Kein Zugriff auf das Datenverzeichnis oder physische Sicherungen erschwert das Verschieben von Daten aus RDS. Dies kann ein großes Problem darstellen, wenn Ihre Datenbank über RDS hinauswächst und Sie sich entscheiden, auf eine andere Plattform zu migrieren. Dieser zweiteilige Blog zeigt Ihnen, wie Sie eine Online-Migration von RDS auf Ihren eigenen MySQL-Server durchführen.
Wir werden EC2 verwenden, um unseren eigenen MySQL-Server auszuführen. Dies kann ein erster Schritt für komplexere Migrationen zu Ihren eigenen privaten Rechenzentren sein. EC2 gibt Ihnen Zugriff auf Ihre Daten, sodass xtrabackup verwendet werden kann. EC2 ermöglicht Ihnen auch die Einrichtung von SSH-Tunneln und macht die Einrichtung von Hardware-VPN-Verbindungen zwischen Ihrer lokalen Infrastruktur und VPC überflüssig.
Annahmen
Bevor wir beginnen, müssen wir einige Annahmen treffen – insbesondere in Bezug auf die Sicherheit. In erster Linie gehen wir davon aus, dass die RDS-Instanz nicht von außerhalb von AWS zugänglich ist. Wir gehen auch davon aus, dass Sie eine Anwendung in EC2 haben. Dies impliziert, dass entweder die RDS-Instanz und der Rest Ihrer Infrastruktur eine VPC gemeinsam nutzen oder der Zugriff zwischen ihnen auf die eine oder andere Weise konfiguriert ist. Kurz gesagt, wir gehen davon aus, dass Sie eine neue EC2-Instanz erstellen können und diese Zugriff auf Ihre MySQL-RDS-Instanz hat (oder so konfiguriert werden kann, dass sie Zugriff hat).
Wir haben ClusterControl auf dem Anwendungshost konfiguriert. Wir verwenden es, um unsere EC2-MySQL-Instanz zu verwalten.
Erste Einrichtung
In unserem Fall teilt sich die RDS-Instanz dieselbe VPC mit unserer „Anwendung“ (EC2-Instanz mit IP 172.30.4.228) und dem Host, der ein Ziel für den Migrationsprozess sein wird (EC2-Instanz mit IP 172.30.4.238). Als Anwendung verwenden wir den tpcc-MySQL-Benchmark, der folgendermaßen ausgeführt wird:
./tpcc_start -h rds2.cvsw8xpajw2b.us-east-1.rds.amazonaws.com -d tpcc1000 -u tpcc -p tpccpass -w 20 -r 60 -l 600 -i 10 -c 4Erster Plan
Wir werden eine Migration mit den folgenden Schritten durchführen:
- Richten Sie unsere Zielumgebung mit ClusterControl ein - installieren Sie MySQL auf 172.30.4.238
- Installieren Sie dann ProxySQL, mit dem wir unseren Datenverkehr zum Zeitpunkt des Failovers verwalten
- Speichern Sie die Daten von der RDS-Instanz
- Laden Sie die Daten in unseren Zielhost
- Replikation zwischen RDS-Instanz und Zielhost einrichten
- Wechselverkehr von RDS zum Zielhost
Umgebung mit ClusterControl vorbereiten
Angenommen, wir haben ClusterControl installiert (wenn nicht, können Sie es von https://severalnines.com/download-clustercontrol-database-management-system herunterladen), müssen wir unseren Zielhost einrichten. Dazu verwenden wir den Bereitstellungsassistenten von ClusterControl:
Bereitstellen eines Datenbankclusters in ClusterControl 
Bereitstellen eines Datenbankclusters in ClusterControl 
Bereitstellen eines Datenbankclusters in ClusterControl Sobald dies erledigt ist, sehen Sie einen neuen Cluster (in diesem Fall nur Ihren einzelnen Server) in der Cluster-Liste:
Datenbank-Cluster in ClusterControl Der nächste Schritt wird die Installation von ProxySQL sein - ab ClusterControl 1.4 können Sie dies ganz einfach über die Benutzeroberfläche tun. Wir haben diesen Prozess in diesem Blogbeitrag ausführlich behandelt. Bei der Installation haben wir unseren Anwendungshost (172.30.4.228) als Host ausgewählt, auf dem ProxySQL installiert werden soll. Bei der Installation müssen Sie auch einen Host auswählen, an den Ihr Datenverkehr weitergeleitet werden soll. Da wir nur unseren „Ziel“-Host im Cluster haben, können Sie ihn einschließen, aber dann sind einige Änderungen erforderlich, um den Datenverkehr an die RDS-Instanz umzuleiten.
Wenn Sie sich entschieden haben, den Zielhost (in unserem Fall war es 172.30.4.238) in das ProxySQL-Setup aufzunehmen, sehen Sie die folgenden Einträge in der mysql_servers-Tabelle:
mysql> select * from mysql_servers\G
*************************** 1. row ***************************
hostgroup_id: 20
hostname: 172.30.4.238
port: 3306
status: ONLINE
weight: 1
compression: 0
max_connections: 100
max_replication_lag: 10
use_ssl: 0
max_latency_ms: 0
comment: read server
*************************** 2. row ***************************
hostgroup_id: 10
hostname: 172.30.4.238
port: 3306
status: ONLINE
weight: 1
compression: 0
max_connections: 100
max_replication_lag: 10
use_ssl: 0
max_latency_ms: 0
comment: read and write server
2 rows in set (0.00 sec)ClusterControl hat ProxySQL so konfiguriert, dass die Hostgruppen 10 und 20 zum Weiterleiten von Schreib- und Lesevorgängen an die Back-End-Server verwendet werden. Wir müssen den aktuell konfigurierten Host aus diesen Hostgruppen entfernen und die RDS-Instanz dort hinzufügen. Zunächst müssen wir jedoch sicherstellen, dass der Monitor-Benutzer von ProxySQL auf die RDS-Instanz zugreifen kann.
mysql> SHOW VARIABLES LIKE 'mysql-monitor_username';
+------------------------+------------------+
| Variable_name | Value |
+------------------------+------------------+
| mysql-monitor_username | proxysql-monitor |
+------------------------+------------------+
1 row in set (0.00 sec)mysql> SHOW VARIABLES LIKE 'mysql-monitor_password';
+------------------------+---------+
| Variable_name | Value |
+------------------------+---------+
| mysql-monitor_password | monpass |
+------------------------+---------+
1 row in set (0.00 sec)Wir müssen diesem Benutzer Zugriff auf RDS gewähren. Wenn wir es brauchen, um die Replikationsverzögerung zu verfolgen, müsste der Benutzer die Berechtigung „REPLICATION CLIENT“ haben. In unserem Fall wird es nicht benötigt, da wir keine Slave-RDS-Instanz haben – „USAGE“ wird ausreichen.
[email protected]:~# mysql -ppassword -h rds2.cvsw8xpajw2b.us-east-1.rds.amazonaws.com
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 210
Server version: 5.7.16-log MySQL Community Server (GPL)
Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.mysql> CREATE USER 'proxysql-monitor'@172.30.4.228 IDENTIFIED BY 'monpass';
Query OK, 0 rows affected (0.06 sec)Jetzt ist es an der Zeit, ProxySQL neu zu konfigurieren. Wir werden die RDS-Instanz sowohl der Writer- (10) als auch der Reader-Hostgruppe (20) hinzufügen. Wir werden auch 172.30.4.238 aus diesen Hostgruppen entfernen – wir werden sie einfach bearbeiten und jeder Hostgruppe 100 hinzufügen.
mysql> INSERT INTO mysql_servers (hostgroup_id, hostname, max_connections, max_replication_lag) VALUES (10, 'rds2.cvsw8xpajw2b.us-east-1.rds.amazonaws.com', 100, 10);
Query OK, 1 row affected (0.00 sec)mysql> INSERT INTO mysql_servers (hostgroup_id, hostname, max_connections, max_replication_lag) VALUES (20, 'rds2.cvsw8xpajw2b.us-east-1.rds.amazonaws.com', 100, 10);
Query OK, 1 row affected (0.00 sec)mysql> UPDATE mysql_servers SET hostgroup_id=110 WHERE hostname='172.30.4.238' AND hostgroup_id=10;
Query OK, 1 row affected (0.00 sec)mysql> UPDATE mysql_servers SET hostgroup_id=120 WHERE hostname='172.30.4.238' AND hostgroup_id=20;
Query OK, 1 row affected (0.00 sec)mysql> LOAD MYSQL SERVERS TO RUNTIME;
Query OK, 0 rows affected (0.01 sec)mysql> SAVE MYSQL SERVERS TO DISK;
Query OK, 0 rows affected (0.07 sec)Der letzte erforderliche Schritt, bevor wir ProxySQL verwenden können, um unseren Datenverkehr umzuleiten, besteht darin, unseren Anwendungsbenutzer zu ProxySQL hinzuzufügen.
mysql> INSERT INTO mysql_users (username, password, active, default_hostgroup) VALUES ('tpcc', 'tpccpass', 1, 10);
Query OK, 1 row affected (0.00 sec)mysql> LOAD MYSQL USERS TO RUNTIME; SAVE MYSQL USERS TO DISK; SAVE MYSQL USERS TO MEMORY;
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.05 sec)
Query OK, 0 rows affected (0.00 sec)mysql> SELECT username, password FROM mysql_users WHERE username='tpcc';
+----------+-------------------------------------------+
| username | password |
+----------+-------------------------------------------+
| tpcc | *8C446904FFE784865DF49B29DABEF3B2A6D232FC |
+----------+-------------------------------------------+
1 row in set (0.00 sec)Kurzer Hinweis – wir haben „MYSQL-BENUTZER IM SPEICHER SPEICHERN“ ausgeführt; nur um das Passwort nicht nur zur RUNTIME, sondern auch im Arbeitsspeicherpuffer gehasht zu haben. Weitere Details zum Passwort-Hashing-Mechanismus von ProxySQL finden Sie in der zugehörigen Dokumentation.
Wir können unseren Datenverkehr jetzt zu ProxySQL umleiten. Wie das geht, hängt von Ihrem Setup ab, wir haben gerade tpcc neu gestartet und auf ProxySQL verwiesen.
Umleitung des Datenverkehrs mit ProxySQL An diesem Punkt haben wir eine Zielumgebung erstellt, zu der wir migrieren werden. Wir haben auch ProxySQL vorbereitet und für unsere Anwendung konfiguriert. Wir haben jetzt eine gute Grundlage für den nächsten Schritt, die eigentliche Datenmigration. Im nächsten Beitrag zeigen wir Ihnen, wie Sie die Daten aus RDS in unsere eigene MySQL-Instanz (die auf EC2 läuft) kopieren. Wir zeigen Ihnen auch, wie Sie den Datenverkehr auf Ihre eigene Instanz umleiten, während Anwendungen die Benutzer weiterhin ohne Ausfallzeiten bedienen.
