MySQL en la nube:migración en línea de Amazon RDS a la instancia EC2:primera parte

En nuestro blog anterior, vimos lo fácil que es comenzar con RDS para MySQL. Es una forma conveniente de implementar y usar MySQL, sin preocuparse por la sobrecarga operativa. Sin embargo, la compensación es un control reducido, ya que los usuarios dependen completamente del personal de Amazon en caso de bajo rendimiento o anomalías operativas. La ausencia de acceso al directorio de datos o a las copias de seguridad físicas dificulta la transferencia de datos fuera de RDS. Esto puede ser un problema importante si su base de datos supera el RDS y decide migrar a otra plataforma. Este blog de dos partes le muestra cómo realizar una migración en línea desde RDS a su propio servidor MySQL.

Usaremos EC2 para ejecutar nuestro propio servidor MySQL. Puede ser un primer paso para migraciones más complejas a sus propios centros de datos privados. EC2 le da acceso a sus datos para que pueda usar xtrabackup. EC2 también le permite configurar túneles SSH y elimina el requisito de configurar conexiones VPN de hardware entre su infraestructura local y la VPC.

Supuestos

Antes de comenzar, debemos hacer un par de suposiciones, especialmente en torno a la seguridad. En primer lugar, asumimos que no se puede acceder a la instancia de RDS desde fuera de AWS. También asumimos que tiene una aplicación en EC2. Esto implica que la instancia RDS y el resto de su infraestructura comparten una VPC o hay acceso configurado entre ellos, de una forma u otra. En resumen, asumimos que puede crear una nueva instancia EC2 y tendrá acceso (o puede configurarse para tener acceso) a su instancia MySQL RDS.

Hemos configurado ClusterControl en el host de la aplicación. Lo usaremos para administrar nuestra instancia EC2 MySQL.

Configuración inicial

En nuestro caso, la instancia RDS comparte la misma VPC con nuestra “aplicación” (instancia EC2 con IP 172.30.4.228) y el host que será el objetivo del proceso de migración (instancia EC2 con IP 172.30.4.238). Como aplicación vamos a utilizar tpcc-MySQL benchmark ejecutado de la siguiente forma:

./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 4

Plan Inicial

Vamos a realizar una migración siguiendo los siguientes pasos:

Configure nuestro entorno de destino utilizando ClusterControl:instale MySQL en 172.30.4.238
Luego, instale ProxySQL, que usaremos para administrar nuestro tráfico en el momento de la conmutación por error
Volcar los datos de la instancia de RDS
Cargar los datos en nuestro host de destino
Configurar la replicación entre la instancia de RDS y el host de destino
Cambio de tráfico de RDS al host de destino

Preparar el entorno usando ClusterControl

Suponiendo que tenemos instalado ClusterControl (si no lo tiene, puede obtenerlo de:https://severalnines.com/download-clustercontrol-database-management-system), necesitamos configurar nuestro host de destino. Usaremos el asistente de implementación de ClusterControl para eso:

Implementación de un clúster de base de datos en ClusterControl

Una vez hecho esto, verá un nuevo clúster (en este caso, solo su único servidor) en la lista de clústeres:

Clúster de base de datos en ClusterControl

El siguiente paso será instalar ProxySQL; a partir de ClusterControl 1.4, puede hacerlo fácilmente desde la interfaz de usuario. Cubrimos este proceso en detalle en esta publicación de blog. Al instalarlo, elegimos nuestro host de aplicación (172.30.4.228) como el host para instalar ProxySQL. Al instalar, también debe elegir un host para enrutar su tráfico. Como solo tenemos nuestro host de "destino" en el clúster, puede incluirlo, pero luego se necesitan algunos cambios para redirigir el tráfico a la instancia de RDS.

Si eligió incluir el host de destino (en nuestro caso fue 172.30.4.238) en la configuración de ProxySQL, verá las siguientes entradas en la tabla 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 configuró ProxySQL para usar los grupos de host 10 y 20 para enrutar escrituras y lecturas a los servidores back-end. Tendremos que eliminar el host configurado actualmente de esos grupos de host y agregar la instancia de RDS allí. Sin embargo, primero debemos asegurarnos de que el usuario del monitor de ProxySQL pueda acceder a la instancia de 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)

Necesitamos otorgar a este usuario acceso a RDS. Si lo necesitamos para rastrear el retraso de la replicación, el usuario tendría que tener el privilegio de 'CLIENTE DE REPLICACIÓN'. En nuestro caso, no es necesario ya que no tenemos una instancia de RDS esclava:"USO" será suficiente.

[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)

Ahora es el momento de reconfigurar ProxySQL. Vamos a agregar la instancia de RDS a los grupos de host de escritor (10) y lector (20). También eliminaremos 172.30.4.238 de esos grupos de host; solo los editaremos y agregaremos 100 a cada grupo de host.

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)

El último paso requerido antes de que podamos usar ProxySQL para redirigir nuestro tráfico es agregar nuestro usuario de aplicación a 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)

Nota rápida:ejecutamos "GUARDAR USUARIOS DE MYSQL EN LA MEMORIA"; solo para tener una contraseña codificada no solo en RUNTIME sino también en el búfer de la memoria de trabajo. Puede encontrar más detalles sobre el mecanismo de hashing de contraseñas de ProxySQL en su documentación.

Ahora podemos redirigir nuestro tráfico a ProxySQL. Cómo hacerlo depende de su configuración, simplemente reiniciamos tpcc y apuntamos a ProxySQL.

Redirigir el tráfico con ProxySQL

En este punto, hemos creado un entorno de destino al que migraremos. También preparamos ProxySQL y lo configuramos para que lo use nuestra aplicación. Ahora tenemos una buena base para el siguiente paso, que es la migración de datos real. En la próxima publicación, le mostraremos cómo copiar los datos de RDS a nuestra propia instancia de MySQL (que se ejecuta en EC2). También le mostraremos cómo cambiar el tráfico a su propia instancia mientras las aplicaciones continúan sirviendo a los usuarios, sin tiempo de inactividad.