Migrieren der MySQL-Datenbank von Amazon RDS zu DigitalOcean

In früheren Blogs (Teil 1 und Teil 2) haben wir besprochen, wie Sie Ihre RDS-Daten in eine EC2-Instance migrieren. Dabei haben wir es geschafft, unsere Daten aus RDS zu verschieben, aber wir laufen immer noch auf AWS. Wenn Sie Ihre Daten vollständig aus Amazon Web Services herausziehen möchten, gibt es noch etwas mehr Arbeit zu tun. Im heutigen Blogbeitrag zeigen wir Ihnen, wie es geht.

Einführung in die Umgebung

Die Umgebung, in der wir arbeiten werden, ist ziemlich ähnlich wie bei unserem letzten Beitrag in der Serie. Der einzige Unterschied besteht darin, dass keine Umstellung stattgefunden hat, da wir die EC2-Instance als Zwischenschritt im Prozess des Ausstiegs aus AWS verwenden werden.

Der Aktionsplan

Im vorherigen Blog haben wir unsere Daten zunächst von RDS auf eine EC2-Instanz migriert, auf die wir vollen Zugriff haben. Da MySQL bereits auf unserer EC2-Instanz läuft, haben wir mehr Optionen zur Auswahl, wie wir unsere Daten in eine andere Cloud kopieren können. DigitalOcean wird hier nur zu Demozwecken verwendet, der unten beschriebene Prozess kann verwendet werden, um zu jedem anderen Hosting- oder Cloud-Anbieter zu migrieren. Sie benötigen direkten Zugriff auf die VPS-Instanzen. In diesem Prozess verwenden wir xtrabackup, um die Daten zu kopieren (obwohl es völlig in Ordnung ist, jede andere Methode der binären Übertragung zu verwenden). Wir müssten eine sichere Verbindung zwischen AWS und DigitalOcean vorbereiten. Sobald wir das getan haben, richten wir die Replikation von der EC2-Instance in ein DigitalOcean-Droplet ein. Der nächste Schritt wäre, eine Umstellung durchzuführen und Anwendungen zu verschieben, aber wir werden hier nicht darauf eingehen.

Entscheidung über die Konnektivitätsmethode

Mit Amazon Web Services können Sie aus vielen verschiedenen Möglichkeiten wählen, um eine Verbindung zu externen Netzwerken herzustellen. Wenn Sie über eine Hardware-Appliance verfügen, die VPN-Verbindungen unterstützt, können Sie damit eine VPN-Verbindung zwischen Ihrer VPC in AWS und Ihrer lokalen Infrastruktur herstellen. Wenn Ihr Netzwerkanbieter Ihnen eine Peering-Verbindung mit dem AWS-Netzwerk anbietet und Sie einen BGP-Router haben, können Sie über AWS Direct Connect eine direkte VLAN-Verbindung zwischen Ihrem Netzwerk und AWS herstellen. Wenn Sie über mehrere isolierte Netzwerke verfügen, können Sie diese mithilfe von AWS VPN CloudHub mit Amazon verbinden. Da die EC2-Instanzen schließlich von Ihnen verwaltet werden, können Sie mithilfe von Softwarelösungen wie OpenVPN auch ein VPN zwischen dieser EC2-Instanz und Ihrem lokalen Netzwerk einrichten.

Da wir über Datenbanken sprechen, können Sie sich auch dafür entscheiden, eine SSL-Replikation zwischen MySQL auf EC2 (dem Master) und dem Slave einzurichten, der auf DigitalOcean läuft. - Wir müssen noch herausfinden, wie wir eine anfängliche Datenübertragung zum Slave durchführen - eine Lösung könnte darin bestehen, die Ausgabe von xtrabackup zu taren, diese Datei zu verschlüsseln und sie entweder über WAN (rsync) zu senden oder in den S3-Bucket hochzuladen und dann herunterzuladen von dort. Sie können sich auch auf die SSH-Verschlüsselung verlassen und die Daten einfach per scp (oder sogar rsync mit SSH) an den neuen Speicherort senden.

Es stehen viele Optionen zur Auswahl. Wir werden jedoch eine andere Lösung verwenden – wir werden einen SSH-Tunnel zwischen der EC2-Instanz und unserem DigitalOcean-Droplet einrichten, um einen sicheren Kanal zu bilden, den wir zum Replizieren von Daten verwenden werden. Die anfängliche Übertragung erfolgt mit rsync über die SSH-Verbindung.

Kopieren von Daten nach DigitalOcean

Sobald wir MySQL 5.7 auf der DigitalOcean-Instanz eingerichtet und ausgeführt haben, müssen wir ein Backup der EC2-Instanz durchführen und es dann auf DO übertragen. Technisch sollte es möglich sein, ein direktes Streaming von xtrabackup-Daten zwischen den Knoten durchzuführen, aber wir können es nicht wirklich empfehlen. WAN-Verbindungen können unzuverlässig sein, und es wäre besser, lokal ein Backup zu erstellen und dann rsync mit seiner Fähigkeit zu verwenden, die Übertragung zu wiederholen, wenn etwas nicht stimmt.

Lassen Sie uns zuerst ein Backup auf unserer EC2-Instanz erstellen:

[email protected]:~# innobackupex --user=tpcc --password=tpccpass /tmp/backup

Sobald es fertig ist, müssen wir es in das DigitalOcean-Netzwerk übertragen. Um dies auf sichere Weise zu tun, erstellen wir einen neuen Benutzer auf dem DO-Droplet, generieren einen SSH-Schlüssel und verwenden diesen Benutzer zum Kopieren der Daten. Natürlich können Sie auch einen vorhandenen Benutzer verwenden, es ist nicht erforderlich, einen neuen zu erstellen. Fügen wir also einen neuen Benutzer hinzu. Es gibt viele Möglichkeiten, dies zu tun, wir verwenden den Befehl „adduser“.

[email protected]:~# adduser rdscopy
Adding user `rdscopy' ...
Adding new group `rdscopy' (1001) ...
Adding new user `rdscopy' (1001) with group `rdscopy' ...
Creating home directory `/home/rdscopy' ...
Copying files from `/etc/skel' ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for rdscopy
Enter the new value, or press ENTER for the default
    Full Name []:
    Room Number []:
    Work Phone []:
    Home Phone []:
    Other []:
Is the information correct? [Y/n] y

Jetzt ist es an der Zeit, ein Paar SSH-Schlüssel für die Konnektivität zu generieren:

[email protected]:~# ssh-keygen -C 'rdscopy' -f id_rsa_rdscopy -t rsa -b 4096
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in id_rsa_rdscopy.
Your public key has been saved in id_rsa_rdscopy.pub.
The key fingerprint is:
3a:b0:d2:80:5b:b8:60:1b:17:58:bd:8e:74:c9:56:b3 rdscopy
The key's randomart image is:
+--[ RSA 4096]----+
|   ..            |
|  o  . o         |
| . .. + o        |
| o ..* E         |
|+o+.*   S        |
|o+++ + .         |
|o.. o o          |
|   .   .         |
|                 |
+-----------------+

Nachdem wir den SSH-Schlüssel haben, müssen wir ihn in unserem Digital Ocean-Droplet einrichten. Wir müssen ein .ssh-Verzeichnis erstellen und eine authorisierte_keys-Datei mit den richtigen Zugriffsberechtigungen erstellen.

[email protected]:~# mkdir /home/rdscopy/.ssh
[email protected]:~# cat id_rsa_rdscopy.pub > /home/rdscopy/.ssh/authorized_keys
[email protected]:~# chown rdscopy.rdscopy /home/rdscopy/.ssh/authorized_keys
[email protected]:~# chmod 600 /home/rdscopy/.ssh/authorized_keys

Dann müssen wir unseren privaten Schlüssel in die EC2-Instanz kopieren. Wenn wir damit fertig sind, können wir unsere Daten kopieren. Wie bereits erwähnt, verwenden wir dafür rsync - damit können wir die Übertragung neu starten, wenn der Vorgang aus irgendeinem Grund unterbrochen wird. In Kombination mit SSH haben wir eine sichere und robuste Methode zum Kopieren der Daten über WAN geschaffen. Lassen Sie uns rsync auf dem EC2-Host starten:

[email protected]:~# rsync -avz -e "ssh -i id_rsa_rdscopy -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" --progress /tmp/backup/2017-02-20_16-34-18/ [email protected]:/home/rdscopy

Nach einer Weile, die von der Datenmenge und der Übertragungsgeschwindigkeit abhängt, sollten unsere Sicherungsdaten auf dem DigitalOcean-Droplet verfügbar sein. Dies bedeutet, dass es an der Zeit ist, es vorzubereiten, indem Sie InnoDB-Redo-Protokolle anwenden und es dann zurück in das MySQL-Datenverzeichnis kopieren. Dazu müssen wir MySQL stoppen, das aktuelle Datenverzeichnis entfernen, die Dateien entweder mit innobackupex oder manuell zurückkopieren und  zu guter Letzt überprüfen, ob Besitzer und Gruppe für neue Dateien auf mysql eingestellt sind:

[email protected]:~# innobackupex --apply-log /home/rdscopy/
[email protected]:~# service mysql stop
[email protected]:~# rm -rf /var/lib/mysql/*
[email protected]:~# innobackupex --copy-back /home/rdscopy/
[email protected]:~# chown -R mysql.mysql /var/lib/mysql

Bevor wir MySQL starten, müssen wir außerdem sicherstellen, dass sowohl server_id als auch UUIDs unterschiedlich sind. Ersteres kann in my.cnf bearbeitet werden, letzteres kann sichergestellt werden durch:

[email protected]:~# rm /var/lib/mysql/auto.cnf

Jetzt können wir MySQL starten:

[email protected]:~# service mysql start

Replikation einrichten

Wir sind bereit, die Replikation zwischen EC2 und DO einzurichten, aber zuerst müssen wir einen SSH-Tunnel einrichten – wir erstellen einen zusätzlichen SSH-Schlüssel für Ubuntu-Benutzer auf der EC2-Instanz und kopieren ihn in die DO-Instanz. Dann verwenden wir den Ubuntu-Benutzer, um einen Tunnel zu erstellen, den wir für die Replikation verwenden werden.

Beginnen wir mit der Erstellung des neuen SSH-Schlüssels:

[email protected]:~# ssh-keygen -C 'tunnel' -f id_rsa_tunnel -t rsa -b 4096
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in id_rsa_tunnel.
Your public key has been saved in id_rsa_tunnel.pub.
The key fingerprint is:
c4:44:79:39:9c:c6:ce:45:bb:13:e5:6f:c5:d9:8c:14 tunnel
The key's randomart image is:
+--[ RSA 4096]----+
|       .o+ +. E. |
|       o. O .= +o|
|        o= oo o.=|
|       .  o  o ..|
|        S   o   o|
|             . . |
|                 |
|                 |
|                 |
+-----------------+

Nächster Schritt:Wir müssen unseren öffentlichen Schlüssel zur Datei „authorized_keys“ auf der EC2-Instanz hinzufügen, mit der wir uns von DigitalOcean verbinden, um einen Tunnel zu erstellen.

[email protected]:~# cat id_rsa_tunnel.pub >> /home/ubuntu/.ssh/authorized_keys

Wir benötigen auch einen privaten Schlüssel, der an das DO-Tröpfchen übertragen werden soll. Dies kann auf viele Arten erfolgen, aber wir verwenden sicheres scp mit rdscopy-Benutzer und -Schlüssel, die wir zuvor erstellt haben:

[email protected]:~# scp -i id_rsa_rdscopy id_rsa_tunnel [email protected]:/home/rdscopy
id_rsa_tunnel                                                                                                                                                                    100% 3247     3.2KB/s   00:00

Das ist alles, was wir brauchen – jetzt können wir den SSH-Tunnel erstellen. Wir möchten, dass es die ganze Zeit verfügbar ist, also verwenden wir die Bildschirmsitzung dafür.

[email protected]:~# screen -S tunnel
[email protected]:~# ssh -L 3307:localhost:3306 [email protected] -i /home/rdscopy/id_rsa_tunnel

Was wir hier getan haben, war das Öffnen eines SSH-Tunnels zwischen localhost, Port 3307 und Remote-Host, 54.224.107.6, Port 3306, unter Verwendung des „ubuntu“-Benutzers und eines Schlüssels, der sich in /home/rdscopy/id_rsa_tunnel befindet. Trennen Sie die Bildschirmsitzung und der Remote-Host sollte über 127.0.0.1:3307 verfügbar sein.

Um die Replikation einzurichten, müssen wir noch n Benutzer hinzufügen, den wir verwenden, um eine Verbindung zu MySQL auf EC2 herzustellen. Wir erstellen es auf dem EC2-Host und verwenden „127.0.0.1“ als Host – Verbindungen über den SSH-Tunnel sehen so aus, als kämen sie von localhost:

mysql> CREATE USER [email protected] IDENTIFIED BY 'rds_rpl_pass';
Query OK, 0 rows affected (0.00 sec)

mysql> GRANT REPLICATION SLAVE ON *.* TO [email protected];
Query OK, 0 rows affected (0.00 sec)

Alles ist bereit, die Replikation einzurichten, es ist jetzt an der Zeit, einem traditionellen Prozess zum Erstellen eines Slaves auf der Grundlage von xtrabackup-Daten zu folgen. Wir müssen Daten von xtrabackup_binlog_info verwenden, um die Master-Position zum Zeitpunkt der Sicherung zu identifizieren. Diese Position wollen wir in unserem CHANGE MASTER TO … Befehl verwenden. Werfen wir einen Blick auf den Inhalt der Datei xtrabackup_binlog_info:

[email protected]:~# cat /home/rdscopy/xtrabackup_binlog_info
binlog.000052    896957365

Dies ist die binäre Protokolldatei und Position, die wir in unserem CHANGE MASTER TO:

[email protected]:~# mysql -u root -ppass

mysql> CHANGE MASTER TO MASTER_HOST='127.0.0.1', MASTER_PORT=3307, MASTER_USER='rds_rpl', MASTER_PASSWORD='rds_rpl_pass', MASTER_LOG_FILE='binlog.000052', MASTER_LOG_POS=896957365; START SLAVE;

Das ist es – die Replikation sollte jetzt laufen und unser DigitalOcean-Slave sollte die Replikation nachholen. Sobald es aufgeholt hat, ist unsere Datenbankschicht bereit für die Umstellung. Natürlich ist es normalerweise mehr als nur ein einzelner Knoten – Sie müssen höchstwahrscheinlich mehrere Slaves auf DO einrichten, bevor die Infrastruktur bereit ist, den Produktionsdatenverkehr zu verarbeiten.

Die Umstellung selbst ist ein anderes Thema – Sie müssen einen Plan zur Minimierung der Ausfallzeiten entwickeln. Im Allgemeinen sollte der Datenverkehr vom alten zum neuen Standort verschoben werden, aber wie dies geschehen sollte, hängt hauptsächlich von Ihrer Umgebung ab. Dies kann alles sein, von einer einfachen Änderung des DNS-Eintrags bis hin zu komplexen Skripten, die alle Trigger in der richtigen Reihenfolge auslösen, um den Datenverkehr umzuleiten. Egal was passiert, Ihre Datenbank befindet sich jetzt bereits am neuen Standort und ist bereit, Anfragen zu bedienen.