Migrar su base de datos a un nuevo centro de datos puede ser un proceso de alto riesgo y lento. Una base de datos contiene estado y puede ser mucho más difícil de migrar en comparación con servidores web, colas o servidores de caché.
En esta publicación de blog, le daremos algunos consejos sobre cómo migrar sus datos de un proveedor de servicios a otro. El proceso es algo similar a nuestra publicación anterior sobre cómo actualizar MySQL, pero hay un par de diferencias importantes.
¿Replicación de MySQL o clúster de Galera?
Cambiar a otro proveedor de servicios (por ejemplo, pasar de AWS a Rackspace o de servidores colocados a la nube) muy a menudo significa que uno construiría una infraestructura completamente nueva en paralelo, la sincronizaría con la infraestructura anterior y luego cambiaría a ella. Para conectarlos y sincronizarlos, es posible que desee aprovechar la replicación de MySQL.
Si está utilizando Galera Cluster, podría ser más fácil mover sus nodos de Galera a un centro de datos diferente. Sin embargo, tenga en cuenta que todo el clúster aún debe tratarse como una única base de datos. Esto significa que su sitio de producción podría verse afectado por la latencia adicional que se presenta al extender Galera Cluster a través de la WAN. Es posible minimizar el impacto ajustando la configuración de la red tanto en Galera como en el sistema operativo, pero el impacto no se puede eliminar por completo. También es posible configurar la replicación asíncrona de MySQL entre el clúster antiguo y el nuevo, si el impacto de la latencia no es aceptable.
Configuración de conectividad segura
La replicación de MySQL no está cifrada y, por lo tanto, no es seguro usarla a través de la WAN. Existen numerosas formas de garantizar que sus datos se transfieran de forma segura. Debe investigar si es posible establecer una conexión VPN entre su infraestructura actual y su nuevo proveedor de servicios. La mayoría de los proveedores (por ejemplo, tanto Rackspace como AWS) brindan dicho servicio:puede conectar su parte "en la nube" a su centro de datos existente a través de una red privada virtual.
Si, por alguna razón, esta solución no funciona para usted (tal vez requiera un hardware al que no tiene acceso), puede usar un software para construir una VPN; uno de ellos será OpenVPN. Esta herramienta funcionará muy bien para configurar conexiones cifradas entre sus centros de datos.
Si OpenVPN no es una opción, hay más formas de garantizar que la replicación se cifre. Por ejemplo, puede usar SSH para crear un túnel entre los centros de datos antiguos y los nuevos, y reenviar el puerto 3306 desde el esclavo (o maestro) de MySQL actual al nuevo nodo. Se puede hacer de una forma muy sencilla siempre y cuando tengas conectividad SSH entre los hosts:
$ ssh -L local_port:old_dc_host:mysql_port_in_old_dc [email protected]_dc_host -N &Por ejemplo:
$ ssh -L 3307:10.0.0.201:3306 [email protected] -N &Ahora, puede conectarse al servidor remoto usando 127.0.0.1:3307
$ mysql -P3307 -h 127.0.0.1Funcionará de manera similar para la replicación, solo recuerde usar 127.0.0.1 para master_host y 3307 para master_port
Por último, pero no menos importante, puede cifrar su replicación mediante SSL. Esta publicación de blog anterior explica cómo se puede hacer y qué tipo de impacto puede tener en el rendimiento de la replicación.
Si decidió usar la replicación de Galera en ambos centros de datos, las sugerencias anteriores también se aplican aquí. Cuando se trata de SSL, anteriormente escribimos en un blog sobre cómo cifrar el tráfico de replicación de Galera. Para una solución más completa, es posible que desee cifrar todas las conexiones de base de datos de las aplicaciones cliente y cualquier infraestructura de administración/supervisión.
Configuración de la nueva infraestructura
Una vez que tenga conectividad, debe comenzar a construir la nueva infraestructura. Para eso, probablemente usará xtrabackup o mariabackup. Puede ser tentador combinar la migración con la actualización de MySQL, después de todo, está configurando un entorno completamente nuevo en la nueva ubicación. No recomendaríamos hacer eso. La migración a una nueva infraestructura es lo suficientemente importante por sí sola, por lo que combinarla con otro cambio importante aumenta la complejidad y el riesgo. Eso también es cierto para otras cosas:desea adoptar un enfoque paso a paso para los cambios. Solo cambiando las cosas una a la vez podrá comprender los resultados de los cambios y cómo afectan su carga de trabajo; si realizó más de un cambio en un momento dado, no puede estar seguro de cuál es responsable de un determinado (nuevo ) comportamiento que has observado.
Cuando tiene una nueva instancia de MySQL en funcionamiento en el nuevo centro de datos, debe esclavizarla fuera del nodo en el antiguo centro de datos, para garantizar que los datos en ambos centros de datos permanezcan sincronizados. Esto será útil mientras se prepara para la transición final. También es una buena manera de asegurarse de que el nuevo entorno pueda manejar su carga de escritura.
El siguiente paso será construir una infraestructura de escenario completa en la nueva ubicación y realizar pruebas y puntos de referencia. Este es un paso muy importante que no debe omitirse:el problema aquí es que usted, como DBA, debe comprender la capacidad de su infraestructura. Cuando cambias de proveedor, las cosas también cambian. El nuevo hardware/vm es más rápido o más lento. Hay más o menos memoria por instancia. Debe comprender nuevamente cómo encajará su carga de trabajo en el hardware que va a utilizar. Para eso, probablemente usará Percona Playback o pt-log-player para reproducir algunas de las consultas de la vida real en el sistema de preparación. Querrá probar el rendimiento y asegurarse de que esté en un nivel aceptable para usted. También desea realizar todas las pruebas de aceptación estándar que ejecuta en sus nuevos lanzamientos, solo para confirmar que todo está en funcionamiento. En general, todas las aplicaciones deben construirse de manera que no dependan de la configuración del hardware y de una configuración actual. Pero es posible que se haya escapado algo y que su aplicación dependa de algunos ajustes de configuración o soluciones de hardware que no tiene en el nuevo entorno.
Finalmente, una vez que esté satisfecho con sus pruebas, querrá construir una infraestructura lista para la producción. Una vez hecho esto, es posible que desee ejecutar algunas pruebas de solo lectura para la verificación final. Este sería el último paso antes de la transición.
transición
Después de que se hayan realizado todas esas pruebas y que la infraestructura se haya considerado lista para la producción, el último paso es cortar el tráfico de la infraestructura anterior.
Hablando globalmente, este es un proceso complejo, pero cuando observamos el nivel de la base de datos, es más o menos lo mismo que la conmutación por error estándar, algo que puede haber hecho varias veces en el pasado. Lo cubrimos en detalle en una publicación anterior, en resumen, los pasos son:detener el tráfico, asegurarse de que esté detenido, esperar mientras la aplicación se mueve al nuevo centro de datos (los registros DNS cambian o lo que no), hacer algunas pruebas de humo para asegurar todo se ve bien, vaya en vivo, monitoree de cerca por un tiempo.
Este cambio requerirá algún tiempo de inactividad, como podemos ver. El problema es asegurarse de que tengamos un estado coherente en el sitio antiguo y en el nuevo. Si queremos hacerlo sin tiempo de inactividad, entonces tendríamos que configurar la replicación maestro-maestro. La razón es que a medida que actualizamos el DNS y cambiamos las sesiones del sitio anterior al nuevo, ambos sistemas estarán en uso al mismo tiempo, hasta que todas las sesiones se redirijan al sitio nuevo. Mientras tanto, cualquier cambio en el sitio nuevo debe reflejarse en el sitio anterior.
El uso de Galera Cluster, como se describe en esta publicación de blog, también puede ser una forma de mantener sincronizados los datos entre los dos sitios.
Somos conscientes de que esta es una descripción muy breve del proceso de migración de datos. Con suerte, será suficiente para orientarlo en una buena dirección y ayudarlo a identificar qué información adicional necesita buscar.
