En blogs anteriores (parte 1 y parte 2), discutimos cómo migrar sus datos RDS a una instancia EC2. En el proceso, logramos sacar nuestros datos de RDS, pero todavía estamos ejecutando en AWS. Si desea mover sus datos completamente fuera de Amazon Web Services, hay un poco más de trabajo por hacer. En la publicación de blog de hoy, le mostraremos cómo se puede hacer.
Introducción al entorno
El entorno con el que trabajaremos es bastante similar al que terminamos en nuestra última publicación de la serie. La única diferencia es que no se realizó la transición, ya que usaremos la instancia EC2 como un paso intermedio en el proceso de mudanza fuera de AWS.
Configuración de infraestructura inicial El Plan de Acción
Recursos relacionados MySQL en la nube:migración en línea de Amazon RDS a la instancia EC2 (parte 1) MySQL en la nube:migración en línea de Amazon RDS a su propio servidor (parte 2) MySQL en la nube:pros y contras de Amazon RDSEn el blog anterior, primero migramos nuestros datos de RDS a una instancia EC2 a la que tenemos acceso completo. Como ya tenemos MySQL ejecutándose en nuestra instancia EC2, tenemos más opciones para elegir con respecto a cómo copiar nuestros datos a otra nube. DigitalOcean solo se usa con fines de demostración aquí, el proceso que describimos a continuación se puede usar para migrar a cualquier otro proveedor de alojamiento o nube. Necesitaría acceso directo a las instancias de VPS. En este proceso, usaremos xtrabackup para copiar los datos (aunque está perfectamente bien usar cualquier otro método de transferencia binaria). Tendríamos que preparar una conexión segura entre AWS y DigitalOcean. Una vez que hagamos eso, configuraremos la replicación desde la instancia EC2 en un droplet de DigitalOcean. El siguiente paso sería realizar una transición y mover aplicaciones, pero no lo cubriremos aquí.
Decidir sobre el método de conectividad
Amazon Web Services le permite elegir entre muchas formas diferentes de crear una conexión a redes externas. Si tiene un dispositivo de hardware que admite conexiones VPN, puede usarlo para formar una conexión VPN entre su VPC en AWS y su infraestructura local. Si su proveedor de red le ofrece una conexión de emparejamiento con la red de AWS y tiene un enrutador BGP, puede obtener una conexión VLAN directa entre su red y AWS a través de AWS Direct Connect. Si tiene varias redes aisladas, puede vincularlas con Amazon mediante AWS VPN CloudHub. Finalmente, como las instancias EC2 son suyas para administrarlas, también puede configurar una VPN entre esa instancia EC2 y su red local utilizando soluciones de software como OpenVPN.
Como estamos hablando de bases de datos, también puede decidir configurar la replicación SSL entre MySQL en EC2 (el maestro) y el esclavo que se ejecuta en DigitalOcean. - Todavía tenemos que descubrir cómo hacer una transferencia de datos inicial al esclavo:una solución podría ser tarear la salida de xtrabackup, cifrar ese archivo y enviarlo a través de WAN (rsync) o cargarlo en el depósito S3 y luego descargarlo desde allí. También puede confiar en el cifrado SSH y simplemente scp (o incluso rsync, usando SSH) los datos a la nueva ubicación.
Hay muchas opciones para elegir. Sin embargo, usaremos otra solución:vamos a establecer un túnel SSH entre la instancia EC2 y nuestro droplet de DigitalOcean para formar un canal seguro que usaremos para replicar datos. La transferencia inicial se realizará mediante rsync a través de la conexión SSH.
Guía de DevOps para la gestión de bases de datos de VariousninesConozca lo que necesita saber para automatizar y gestionar sus bases de datos de código abiertoDescargar gratisCopia de datos a DigitalOcean
Una vez que tengamos MySQL 5.7 funcionando en la instancia de DigitalOcean, debemos realizar una copia de seguridad de la instancia EC2 y luego transferirla a DO. Técnicamente, debería ser posible realizar una transmisión directa de datos de xtrabackup entre los nodos, pero realmente no podemos recomendarlo. Los enlaces WAN pueden no ser confiables, y sería mejor hacer una copia de seguridad localmente y luego usar rsync con su capacidad para volver a intentar la transferencia cuando algo no esté bien.
Primero, hagamos una copia de seguridad en nuestra instancia EC2:
[email protected]:~# innobackupex --user=tpcc --password=tpccpass /tmp/backupUna vez que esté listo, debemos transferirlo a la red de DigitalOcean. Para hacerlo de forma segura, crearemos un nuevo usuario en el droplet DO, generaremos una clave SSH y usaremos este usuario para copiar los datos. Por supuesto, también puede usar cualquiera de los usuarios existentes, no es necesario crear uno nuevo. Entonces, agreguemos un nuevo usuario. Hay muchas maneras de hacer esto, usaremos el comando '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] yAhora es el momento de generar un par de claves ssh para usar en la conectividad:
[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 |
| . . |
| |
+-----------------+Al tener la clave SSH, debemos configurarla en nuestro droplet de Digital Ocean. Necesitamos crear el directorio .ssh y crear un archivo authorized_keys con los permisos de acceso adecuados.
[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_keysLuego, necesitamos copiar nuestra clave privada a la instancia EC2. Cuando estemos listos con él, podemos copiar nuestros datos. Como mencionamos anteriormente, usaremos rsync para eso; nos permitirá reiniciar la transferencia si, por cualquier motivo, el proceso se interrumpe. Combinado con SSH, hemos creado un método seguro y robusto para copiar los datos a través de WAN. Comencemos rsync en el host 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/rdscopyDespués de un tiempo, que dependerá de la cantidad de datos y la velocidad de transferencia, nuestros datos de respaldo deberían estar disponibles en el droplet de DigitalOcean. Esto significa que es hora de prepararlo aplicando los registros de rehacer de InnoDB y luego copiándolo nuevamente en el directorio de datos de MySQL. Para eso, debemos detener MySQL, eliminar el directorio de datos actual, volver a copiar los archivos usando innobackupex o manualmente y, finalmente, verificar que el propietario y el grupo para los nuevos archivos estén configurados en 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/mysqlAntes de iniciar MySQL, también debemos asegurarnos de que tanto server_id como UUID sean diferentes. El primero se puede editar en my.cnf, el segundo se puede asegurar mediante:
[email protected]:~# rm /var/lib/mysql/auto.cnfAhora, podemos iniciar MySQL:
[email protected]:~# service mysql startConfiguración de la replicación
Estamos listos para configurar la replicación entre EC2 y DO, pero primero debemos configurar un túnel ssh:crearemos una clave ssh adicional para el usuario de ubuntu en la instancia de EC2 y la copiaremos en la instancia de DO. Luego usaremos el usuario de ubuntu para crear un túnel que usaremos para la replicación.
Comencemos por crear la nueva clave 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|
| . . |
| |
| |
| |
+-----------------+Siguiente paso:debemos agregar nuestra clave pública al archivo authorized_keys en la instancia EC2, a la que nos conectaremos desde DigitalOcean para crear un túnel.
[email protected]:~# cat id_rsa_tunnel.pub >> /home/ubuntu/.ssh/authorized_keysTambién necesitamos una clave privada para transferirla al droplet DO. Se puede hacer de muchas maneras, pero usaremos scp seguro usando el usuario y la clave rdscopy que creamos anteriormente:
[email protected]:~# scp -i id_rsa_rdscopy id_rsa_tunnel [email protected]:/home/rdscopy
id_rsa_tunnel 100% 3247 3.2KB/s 00:00Eso es todo lo que necesitamos, ahora podemos crear el túnel SSH. Queremos que esté disponible todo el tiempo, así que usaremos la sesión de pantalla para ello.
[email protected]:~# screen -S tunnel
[email protected]:~# ssh -L 3307:localhost:3306 [email protected] -i /home/rdscopy/id_rsa_tunnelLo que hicimos aquí fue abrir un túnel SSH entre localhost, puerto 3307 y host remoto, 54.224.107.6, puerto 3306 utilizando el usuario "ubuntu" y una clave ubicada en /home/rdscopy/id_rsa_tunnel. Separe la sesión de pantalla y el host remoto debería estar disponible a través de 127.0.0.1:3307.
Para configurar la replicación, aún necesitamos agregar un usuario que usaremos para conectarnos a MySQL en EC2. Lo crearemos en el host EC2 y usaremos '127.0.0.1' como host:las conexiones a través del túnel SSH parecerán que provienen del host local:
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)Todo está listo para configurar la replicación, ahora es el momento de seguir un proceso tradicional de creación de un esclavo basado en datos de xtrabackup. Necesitamos usar datos de xtrabackup_binlog_info para identificar la posición principal en el momento de la copia de seguridad. Esta posición es la que queremos usar en nuestro comando CAMBIAR MAESTRO A…. Echemos un vistazo al contenido del archivo xtrabackup_binlog_info:
[email protected]:~# cat /home/rdscopy/xtrabackup_binlog_info
binlog.000052 896957365Este es el archivo de registro binario y la posición que usaremos en nuestro CAMBIO MAESTRO A:
[email protected]:~# mysql -u root -ppassmysql> 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;Esto es todo:la replicación debería estar ahora en funcionamiento y nuestro esclavo DigitalOcean debería estar poniéndose al día con la replicación. Una vez que se ha puesto al día, nuestro nivel de base de datos está listo para el cambio. Por supuesto, por lo general es más que un solo nodo:lo más probable es que tenga que configurar varios esclavos en DO antes de que la infraestructura esté lista para manejar el tráfico de producción.
El cambio en sí mismo es un tema diferente:tendrá que idear un plan para minimizar el tiempo de inactividad. En general, el tráfico debe moverse de la ubicación antigua a la nueva, pero la forma en que debe hacerse depende principalmente de su entorno. Puede ser cualquier cosa, desde un simple cambio en la entrada de DNS hasta secuencias de comandos complejas que activarán todos los desencadenantes en el orden correcto para redirigir el tráfico. Pase lo que pase, su base de datos ya está en la nueva ubicación, lista para atender solicitudes.
