Dans notre blog précédent, nous avons vu à quel point il est facile de démarrer avec RDS pour MySQL. C'est un moyen pratique de déployer et d'utiliser MySQL, sans se soucier des frais généraux opérationnels. Le compromis est cependant un contrôle réduit, car les utilisateurs dépendent entièrement du personnel d'Amazon en cas de mauvaises performances ou d'anomalies opérationnelles. L'absence d'accès au répertoire de données ou aux sauvegardes physiques rend difficile le déplacement des données hors du RDS. Cela peut être un problème majeur si votre base de données dépasse RDS et que vous décidez de migrer vers une autre plate-forme. Ce blog en deux parties vous montre comment effectuer une migration en ligne de RDS vers votre propre serveur MySQL.
Nous utiliserons EC2 pour exécuter notre propre serveur MySQL. Cela peut être une première étape pour des migrations plus complexes vers vos propres centres de données privés. EC2 vous donne accès à vos données afin que xtrabackup puisse être utilisé. EC2 vous permet également de configurer des tunnels SSH et supprime l'obligation de configurer des connexions VPN matérielles entre votre infrastructure sur site et le VPC.
Hypothèses
Avant de commencer, nous devons faire quelques hypothèses, en particulier en matière de sécurité. Tout d'abord, nous supposons que l'instance RDS n'est pas accessible depuis l'extérieur d'AWS. Nous supposons également que vous avez une application dans EC2. Cela implique que soit l'instance RDS et le reste de votre infrastructure partagent un VPC, soit un accès est configuré entre eux, d'une manière ou d'une autre. En bref, nous supposons que vous pouvez créer une nouvelle instance EC2 et qu'elle aura accès (ou qu'elle peut être configurée pour avoir accès) à votre instance MySQL RDS.
Nous avons configuré ClusterControl sur l'hôte de l'application. Nous l'utiliserons pour gérer notre instance MySQL EC2.
Configuration initiale
Dans notre cas, l'instance RDS partage le même VPC avec notre "application" (instance EC2 avec IP 172.30.4.228) et l'hôte qui sera une cible pour le processus de migration (instance EC2 avec IP 172.30.4.238). En tant qu'application, nous allons utiliser le benchmark tpcc-MySQL exécuté de la manière suivante :
./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 4Plan initial
Nous allons effectuer une migration en suivant les étapes suivantes :
- Configurez notre environnement cible à l'aide de ClusterControl - installez MySQL sur 172.30.4.238
- Ensuite, installez ProxySQL, que nous utiliserons pour gérer notre trafic au moment du basculement
- Vider les données de l'instance RDS
- Charger les données dans notre hôte cible
- Configurer la réplication entre l'instance RDS et l'hôte cible
- Basculer le trafic du RDS vers l'hôte cible
Préparer l'environnement à l'aide de ClusterControl
En supposant que ClusterControl soit installé (si vous ne le faites pas, vous pouvez le récupérer à partir de :https://severalnines.com/download-clustercontrol-database-management-system), nous devons configurer notre hôte cible. Nous utiliserons pour cela l'assistant de déploiement de ClusterControl :
Déploiement d'un cluster de bases de données dans ClusterControl 
Déploiement d'un cluster de bases de données dans ClusterControl 
Déploiement d'un cluster de bases de données dans ClusterControl Une fois cela fait, vous verrez un nouveau cluster (dans ce cas, juste votre serveur unique) dans la liste des clusters :
Cluster de base de données dans ClusterControl La prochaine étape consistera à installer ProxySQL - à partir de ClusterControl 1.4, vous pouvez le faire facilement à partir de l'interface utilisateur. Nous avons couvert ce processus en détail dans cet article de blog. Lors de son installation, nous avons choisi notre hôte d'application (172.30.4.228) comme hôte sur lequel installer ProxySQL. Lors de l'installation, vous devez également choisir un hôte vers lequel acheminer votre trafic. Comme nous n'avons que notre hôte "destination" dans le cluster, vous pouvez l'inclure, mais quelques modifications sont nécessaires pour rediriger le trafic vers l'instance RDS.
Si vous avez choisi d'inclure l'hôte de destination (dans notre cas, il s'agissait de 172.30.4.238) dans la configuration de ProxySQL, vous verrez les entrées suivantes dans la table mysql_servers :
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 a configuré ProxySQL pour utiliser les groupes d'hôtes 10 et 20 pour acheminer les écritures et les lectures vers les serveurs principaux. Nous devrons supprimer l'hôte actuellement configuré de ces groupes d'hôtes et y ajouter l'instance RDS. Cependant, nous devons d'abord nous assurer que l'utilisateur du moniteur de ProxySQL peut accéder à l'instance RDS.
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)Nous devons accorder à cet utilisateur l'accès au RDS. Si nous en avons besoin pour suivre le décalage de réplication, l'utilisateur devra alors disposer du privilège « CLIENT DE RÉPLICATION ». Dans notre cas, ce n'est pas nécessaire car nous n'avons pas d'instance RDS esclave - "USAGE" suffira.
[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)Il est maintenant temps de reconfigurer ProxySQL. Nous allons ajouter l'instance RDS aux groupes d'hôtes écrivain (10) et lecteur (20). Nous supprimerons également 172.30.4.238 de ces groupes d'hôtes - nous allons simplement les modifier et ajouter 100 à chaque groupe d'hôtes.
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)La dernière étape requise avant de pouvoir utiliser ProxySQL pour rediriger notre trafic consiste à ajouter l'utilisateur de notre application à ProxySQL.
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)Remarque rapide - nous avons exécuté "SAVE MYSQL USERS TO MEMORY ;" seulement pour avoir le mot de passe haché non seulement dans RUNTIME mais aussi dans la mémoire tampon de travail. Vous pouvez trouver plus de détails sur le mécanisme de hachage de mot de passe de ProxySQL dans leur documentation.
Nous pouvons maintenant rediriger notre trafic vers ProxySQL. La façon de procéder dépend de votre configuration, nous avons juste redémarré tpcc et l'avons pointé vers ProxySQL.
Redirection du trafic avec ProxySQL À ce stade, nous avons construit un environnement cible vers lequel nous allons migrer. Nous avons également préparé ProxySQL et l'avons configuré pour que notre application l'utilise. Nous avons maintenant une bonne base pour la prochaine étape, qui est la migration des données proprement dite. Dans le prochain article, nous vous montrerons comment copier les données de RDS dans notre propre instance MySQL (fonctionnant sur EC2). Nous vous montrerons également comment transférer le trafic vers votre propre instance pendant que les applications continuent de servir les utilisateurs, sans temps d'arrêt.
