Migration de la base de données MySQL d'Amazon RDS vers DigitalOcean

Dans les blogs précédents (partie 1 et partie 2), nous avons expliqué comment migrer vos données RDS vers une instance EC2. Dans le processus, nous avons réussi à déplacer nos données hors de RDS, mais nous fonctionnons toujours sur AWS. Si vous souhaitez déplacer complètement vos données hors d'Amazon Web Services, il reste un peu de travail à faire. Dans l'article de blog d'aujourd'hui, nous allons vous montrer comment cela peut être fait.

Présentation de l'environnement

L'environnement avec lequel nous allons travailler est assez similaire à celui avec lequel nous nous sommes retrouvés lors de notre dernier article de la série. La seule différence est qu'aucune transition ne s'est produite, car nous utiliserons l'instance EC2 comme étape intermédiaire dans le processus de sortie d'AWS.

Le plan d'action

Dans le blog précédent, nous avons d'abord migré nos données de RDS vers une instance EC2 à laquelle nous avons un accès complet. Comme nous avons déjà MySQL en cours d'exécution sur notre instance EC2, nous avons plus d'options parmi lesquelles choisir concernant la façon de copier nos données vers un autre cloud. DigitalOcean est uniquement utilisé à des fins de démonstration ici, le processus que nous décrivons ci-dessous peut être utilisé pour migrer vers tout autre fournisseur d'hébergement ou de cloud. Vous auriez besoin d'un accès direct aux instances VPS. Dans ce processus, nous utiliserons xtrabackup pour copier les données (bien qu'il soit parfaitement acceptable d'utiliser toute autre méthode de transfert binaire). Nous aurions besoin de préparer une connexion sécurisée entre AWS et DigitalOcean. Une fois que nous aurons fait cela, nous configurerons la réplication de l'instance EC2 dans une gouttelette DigitalOcean. La prochaine étape serait d'effectuer un basculement et de déplacer des applications, mais nous n'en parlerons pas ici.

Déterminer la méthode de connectivité

Amazon Web Services vous permet de choisir parmi de nombreuses façons différentes de créer une connexion à des réseaux externes. Si vous disposez d'une appliance matérielle qui prend en charge les connexions VPN, vous pouvez l'utiliser pour établir une connexion VPN entre votre VPC dans AWS et votre infrastructure locale. Si votre fournisseur de réseau vous propose une connexion d'appairage avec le réseau AWS et que vous disposez d'un routeur BGP, vous pouvez obtenir une connexion VLAN directe entre votre réseau et AWS via AWS Direct Connect. Si vous disposez de plusieurs réseaux isolés, vous pouvez les relier à Amazon à l'aide d'AWS VPN CloudHub. Enfin, comme les instances EC2 sont à votre charge, vous pouvez également configurer un VPN entre cette instance EC2 et votre réseau local à l'aide de solutions logicielles comme OpenVPN.

Comme nous parlons de bases de données, vous pouvez également décider de configurer la réplication SSL entre MySQL sur EC2 (le maître) et l'esclave fonctionnant sur DigitalOcean. - Nous devons encore trouver comment effectuer un transfert de données initial vers l'esclave - une solution pourrait être de tarer la sortie de xtrabackup, de chiffrer ce fichier et de l'envoyer via WAN (rsync) ou de le télécharger sur le compartiment S3, puis de le télécharger De là. Vous pouvez également compter sur le cryptage SSH et simplement scp (ou même rsync, en utilisant SSH) les données vers le nouvel emplacement.

Vous avez le choix entre de nombreuses options. Nous utiliserons cependant une autre solution - nous allons établir un tunnel SSH entre l'instance EC2 et notre droplet DigitalOcean pour former un canal sécurisé que nous utiliserons pour répliquer les données. Le transfert initial sera effectué à l'aide de rsync sur la connexion SSH.

Copier des données vers DigitalOcean

Une fois que MySQL 5.7 est opérationnel sur l'instance DigitalOcean, nous devons effectuer une sauvegarde de l'instance EC2, puis la transférer vers DO. Techniquement, il devrait être possible d'effectuer un streaming direct des données xtrabackup entre les nœuds mais nous ne pouvons pas vraiment le recommander. Les liaisons WAN peuvent ne pas être fiables, et il serait préférable d'effectuer une sauvegarde localement, puis d'utiliser rsync avec sa capacité à réessayer le transfert chaque fois que quelque chose ne va pas.

Commençons par effectuer une sauvegarde sur notre instance EC2 :

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

Une fois prêt, nous devons le transférer sur le réseau DigitalOcean. Pour le faire en toute sécurité, nous allons créer un nouvel utilisateur sur le droplet DO, générer une clé SSH et utiliser cet utilisateur pour copier les données. Bien sûr, vous pouvez également utiliser n'importe lequel des utilisateurs existants, il n'est pas nécessaire d'en créer un nouveau. Alors, ajoutons un nouvel utilisateur. Il existe de nombreuses façons de le faire, nous utiliserons la commande "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

Il est maintenant temps de générer une paire de clés ssh à utiliser pour la connectivité :

[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          |
|   .   .         |
|                 |
+-----------------+

Ayant la clé SSH, nous devons la configurer sur notre droplet Digital Ocean. Nous devons créer un répertoire .ssh et créer un fichier authorized_keys avec les autorisations d'accès appropriées.

[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

Ensuite, nous devons copier notre clé privée sur l'instance EC2. Lorsque nous sommes prêts, nous pouvons copier nos données. Comme nous l'avons mentionné précédemment, nous utiliserons rsync pour cela - cela nous permettra de redémarrer le transfert si, pour une raison quelconque, le processus est interrompu. Combiné avec SSH, nous avons créé une méthode sûre et robuste de copie des données sur le WAN. Commençons rsync sur l'hôte EC2 :

[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

Après un certain temps, qui dépendra de la quantité de données et de la vitesse de transfert, nos données de sauvegarde devraient devenir disponibles sur le droplet DigitalOcean. Cela signifie qu'il est temps de le préparer en appliquant les journaux redo InnoDB, puis en le copiant dans le répertoire de données MySQL. Pour cela, nous devons arrêter MySQL, supprimer le répertoire de données actuel, recopier les fichiers à l'aide d'innobackupex ou manuellement, et enfin, vérifier que le propriétaire et le groupe des nouveaux fichiers sont définis sur mysql :

[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

Avant de démarrer MySQL, nous devons également nous assurer que server_id et UUID sont différents. Le premier peut être édité dans my.cnf, le second peut être assuré par :

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

Maintenant, nous pouvons démarrer MySQL :

[email protected]:~# service mysql start

Configuration de la réplication

Nous sommes prêts à configurer la réplication entre EC2 et DO, mais nous devons d'abord configurer un tunnel ssh - nous allons créer une clé ssh supplémentaire pour l'utilisateur ubuntu sur l'instance EC2 et la copier sur l'instance DO. Ensuite, nous utiliserons l'utilisateur Ubuntu pour créer un tunnel que nous utiliserons pour la réplication.

Commençons par créer la nouvelle clé ssh :

[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|
|             . . |
|                 |
|                 |
|                 |
+-----------------+

Prochaine étape - nous devons ajouter notre clé publique au fichier authorized_keys sur l'instance EC2, à laquelle nous nous connecterons depuis DigitalOcean pour créer un tunnel.

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

Nous avons également besoin d'une clé privée à transférer au droplet DO. Cela peut être fait de plusieurs façons, mais nous utiliserons scp sécurisé en utilisant l'utilisateur et la clé rdscopy que nous avons créés précédemment :

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

C'est tout ce dont nous avons besoin - nous pouvons maintenant créer le tunnel SSH. Nous voulons qu'il soit disponible tout le temps, nous utiliserons donc une session d'écran pour cela.

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

Ce que nous avons fait ici était d'ouvrir un tunnel SSH entre localhost, port 3307 et hôte distant, 54.224.107.6, port 3306 en utilisant l'utilisateur "ubuntu" et une clé située dans /home/rdscopy/id_rsa_tunnel. Détachez la session d'écran et l'hôte distant doit être disponible via 127.0.0.1:3307.

Pour configurer la réplication, nous devons encore ajouter n utilisateur que nous utiliserons pour nous connecter à MySQL sur EC2. Nous allons le créer sur l'hôte EC2 et nous utiliserons "127.0.0.1" comme hôte - les connexions via le tunnel SSH sembleront provenir de 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)

Tout est prêt pour configurer la réplication, il est maintenant temps de suivre un processus traditionnel de création d'un esclave basé sur les données xtrabackup. Nous devons utiliser les données de xtrabackup_binlog_info pour identifier la position du maître au moment de la sauvegarde. Cette position est ce que nous voulons utiliser dans notre commande CHANGE MASTER TO …. Examinons le contenu du fichier xtrabackup_binlog_info :

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

Il s'agit du fichier journal binaire et de la position que nous utiliserons dans notre 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;

Ça y est - la réplication devrait maintenant être opérationnelle et notre esclave DigitalOcean devrait rattraper son retard sur la réplication. Une fois qu'il a rattrapé son retard, notre niveau de base de données est prêt pour le basculement. Bien sûr, il s'agit généralement de plus qu'un seul nœud - vous devrez très probablement configurer plusieurs esclaves sur DO avant que l'infrastructure ne soit prête à gérer le trafic de production.

Le basculement lui-même est un sujet différent - vous devrez concevoir un plan pour minimiser les temps d'arrêt. En général, le trafic doit être déplacé de l'ancien vers le nouvel emplacement, mais la manière dont cela doit être fait dépend principalement de votre environnement. Cela peut aller d'un simple changement d'entrée DNS à des scripts complexes qui déclencheront tous les déclencheurs dans le bon ordre pour rediriger le trafic. Quoi qu'il en soit, votre base de données se trouve désormais déjà dans le nouvel emplacement, prête à répondre aux demandes.