En esta publicación de blog, veremos cómo realizar una migración en línea desde la configuración independiente de MySQL 5.6 a un nuevo conjunto de replicación que se ejecuta en MySQL 5.7, implementado y administrado por ClusterControl.
El plan es configurar un enlace de replicación desde el nuevo clúster que se ejecuta en MySQL 5.7 al maestro que se ejecuta en MySQL 5.6 (fuera de la provisión de ClusterControl), que no usa GTID. MySQL no admite la combinación de GTID y no GTID en una cadena de replicación. Por lo tanto, debemos hacer algunos trucos para cambiar entre los modos GTID y no GTID durante la migración.
Nuestra arquitectura y plan de migración se pueden ilustrar a continuación:
La configuración consta de 4 servidores, con la siguiente representación:
- mysql56a - Antiguo maestro - Oracle MySQL 5.6 sin GTID
- Clúster esclavo:
- mysql57a - Nuevo maestro - Oracle MySQL 5.7 con GTID
- mysql57b - Nuevo esclavo - Oracle MySQL 5.7 con GTID
- cc - ClusterControl Server - Servidor de implementación/administración/supervisión para los nodos de la base de datos.
Todos los servidores MySQL 5.7 se ejecutan en Debian 10 (Buster), mientras que MySQL 5.6 se ejecuta en Debian 9 (Stretch).
Implementación del clúster esclavo
En primer lugar, preparemos el clúster esclavo antes de configurar un enlace de replicación desde el antiguo maestro. La configuración final del clúster esclavo se ejecutará en MySQL 5.7, con GTID habilitado. Instale ClusterControl en el servidor ClusterControl (cc):
$ wget https://severalnines.com/downloads/install-cc$ chmod 755 install-cc$ ./install-cc Siga las instrucciones hasta que se complete la instalación. Luego, configure SSH sin contraseña desde ClusterControl a mysql57a y mysql57b:
$ whoamiroot$ ssh-keygen -t rsa # presione Enter en todas las indicaciones$ ssh-copy-id [email protected] # ingrese la contraseña raíz del host de destino$ ssh-copy-id [email protected] # ingrese la contraseña raíz del host de destino Luego, inicie sesión en la interfaz de usuario de ClusterControl, complete el formulario inicial y vaya a la sección ClusterControl -> Implementar -> Replicación de MySQL y complete lo siguiente:
Luego haga clic en Continuar y elija Oracle como proveedor y 5.7 como proveedor versión. Luego proceda a la sección de topología y configúrela como se muestra a continuación:
Espere hasta que se complete la implementación y debería ver el nuevo clúster como se muestra a continuación:
Nuestro clúster esclavo que se ejecuta en MySQL 5.7 con GTID ya está listo.
Preparando al Viejo Maestro
El maestro actual que queremos replicar es un MySQL 5.6 independiente (registro binario habilitado, ID de servidor configurado, sin GTID) y está sirviendo bases de datos de producción. Por lo tanto, el tiempo de inactividad no es una opción para esta migración. Por otro lado, ClusterControl configura el nuevo MySQL 5.7 con GTID habilitado, lo que significa que debemos desactivar la funcionalidad de GTID dentro del clúster esclavo para poder replicar correctamente desde este maestro independiente.
Las siguientes líneas muestran nuestra configuración actual relacionada con la replicación para el maestro /etc/mysql/mysql.conf.d/mysqld.cnf bajo la directiva [mysqld]:
server_id=1binlog_format=ROWlog_bin=binloglog_slave_updates=1relay_log=relay-binexpire_logs_days=7sync_binlog=1 Verifique que el servidor MySQL esté produciendo un registro binario, sin GTID:
mysql> MOSTRAR ESTADO DEL MAESTRO;+---------------+----------+---------------- ----+---------------------------------+-------------------+| Archivo | Posición | Binlog_Do_DB | Binlog_Ignorar_DB | Conjunto_Gtid_ejecutado |+---------------+----------+--------------+---------- -------------+-------------------+| binlog.000007 | 734310 | | | |+---------------+----------+--------------+------ ------------+-------------------+1 fila en conjunto (0.00 seg) Para no GTID, se espera que Executed_Gtid_Set esté vacío. Tenga en cuenta que nuestro nuevo clúster de replicación MySQL 5.7 implementado por ClusterControl está configurado con GTID habilitado.
1) Cree un usuario de replicación para ser utilizado por mysql57a:
mysql> CREAR USUARIO 'slave'@'192.168.10.31' IDENTIFICADO POR 'slavepassword';mysql> OTORGAR REPLICACIÓN ESCLAVO EN *.* A 'slave'@192.168.10.31'; 2) Deshabilitar la recuperación automática de ClusterControl. En la interfaz de usuario de ClusterControl -> elija el clúster -> asegúrese de que el clúster y el nodo de recuperación automática estén apagados (iconos de energía rojos), como se muestra en la siguiente captura de pantalla:
No queremos que ClusterControl recupere el nodo durante esta configuración de replicación.
3) Ahora necesitamos crear una copia de seguridad completa de mysqldump ya que esta será una actualización de versión principal. Otras herramientas de copia de seguridad sin bloqueo, como Percona Xtrabackup o MySQL Enterprise Backup, no admiten la restauración a una versión principal diferente. También necesitamos preservar el archivo de registro binario actual y la posición usando el indicador --master-data:
$ mysqldump -u root -p --single-transaction --master-data=2 --todas las bases de datos> mysql56a-fullbackup.sql Tenga en cuenta que el comando anterior no bloqueará ninguna tabla de InnoDB debido a --single-transaction. Entonces, si tiene tablas MyISAM, las tablas se bloquearán durante el período de copias de seguridad para mantener la coherencia.
4) Copie la copia de seguridad de mysql56a a mysql57a y mysql57b:
$ scp mysql56a-fullbackup.sql [email protected]:~$ scp mysql56a-fullbackup.sql [email protected]:~ Preparación del clúster esclavo
En esta fase, configuraremos el clúster esclavo para comenzar a replicar desde el antiguo maestro, mysql56a sin GTID.
1) Detenga la replicación entre mysql57a y mysql57b, elimine todas las credenciales relacionadas con esclavos configuradas por ClusterControl y desactive solo lectura en mysql57b:
mysql> DETENER ESCLAVO;mysql> RESTABLECER ESCLAVO TODO;mysql> SET GLOBAL super_read_only =0;mysql> SET GLOBAL read_only =0; 2) Deshabilitar GTID en mysql57a:
mysql> SET GLOBAL gtid_mode ='ON_PERMISSIVE';mysql> SET GLOBAL gtid_mode ='OFF_PERMISSIVE';mysql> SET GLOBAL gtid_mode ='OFF';mysql> SET GLOBAL enforce_gtid_consistency ='OFF'; 3) Deshabilitar GTID en mysql57b:
mysql> SET GLOBAL gtid_mode ='ON_PERMISSIVE';mysql> SET GLOBAL gtid_mode ='OFF_PERMISSIVE';mysql> SET GLOBAL gtid_mode ='OFF';mysql> SET GLOBAL enforce_gtid_consistency ='OFF'; 4) Restaurar la copia de seguridad de mysqldump en mysql57a:
$ mysql -uroot -p 5) Restaurar la copia de seguridad de mysqldump en mysql57b:
$ mysql -uroot -p 6) Ejecute el script de actualización de MySQL en mysql57a (para verificar y actualizar todas las tablas a la versión actual):
$ mysql_upgrade -uroot -p 7) Ejecute el script de actualización de MySQL en mysql57b (para comprobar y actualizar todas las tablas a la versión actual):
$ mysql_upgrade -uroot -p Ambos servidores en el clúster esclavo ahora están configurados con la instantánea de datos del maestro anterior, mysql56a, y ahora están listos para replicar.
Configuración de la replicación para el clúster esclavo
1) Restablezca los registros binarios usando RESET MASTER en mysql57a, para que no tengamos que especificar el archivo binario y el posicionamiento del registro más adelante en mysql57b. Además, eliminamos todas las referencias de GTID existentes que se configuraron antes:
mysql> RESTABLECER MAESTRO;mysql> SET @@global.gtid_purged=''; 2) En mysql57a, recupere el archivo binlog y la posición del archivo de volcado, mysql56a-fullbackup.sql:
$ head -100 mysql56a-fullbackup.sql | grep LOG_POS-- CAMBIAR MAESTRO A MASTER_LOG_FILE='binlog.000007', MASTER_LOG_POS=4677987; 3) Inicie el esclavo de replicación desde el maestro antiguo, mysql56a, al nuevo maestro mysql57a, especificando los valores MASTER_LOG_FILE y MASTER_LOG_POS correctos recuperados en el paso anterior. En mysql57a:
mysql> CAMBIAR MAESTRO A MASTER_HOST ='192.168.10.22', MASTER_USER ='slave', MASTER_PASSWORD ='slavepassword', MASTER_LOG_FILE='binlog.000007', MASTER_LOG_POS=4677987;mysql> START SLAVE;mysql> MOSTRAR ESTADO DE ESCLAVO\G Asegúrese de ver las siguientes líneas:
Slave_IO_Running:Sí Slave_SQL_Running:Sí Probablemente necesite esperar hasta que mysql57a alcance a mysql56a monitoreando "Seconds_Behind_Master" y asegurándose de que cambie a 0.
4) En este punto, mysql57a está replicando datos de mysql56a, lo que significa que todos los usuarios creados por ClusterControl ahora no están en el servidor (porque mysql57a ahora sigue los datos en mysql56a). ClusterControl tendrá un problema para conectarse a mysql57a y aparecerá como "inactivo". Básicamente significa que ClusterControl no puede conectarse a los servidores MySQL porque faltan las concesiones. Los usuarios que faltan son:
- [email protected]
- [email protected]'{todos los nodos en un clúster en particular}'
- [email protected]'{ClusterControl host}'
Todas las credenciales se almacenan de forma segura en el ClusterControl y en el propio servidor de la base de datos. Debe tener acceso raíz para recuperar las credenciales de los archivos relevantes.
Ahora, volvamos a crear los usuarios que faltan en el nuevo maestro, mysql57a:
a) Cree un usuario de respaldo (contraseña tomada de /etc/mysql/secrets-backup.cnf en mysql57a):
mysql> CREAR USUARIO [email protected] IDENTIFICADO POR '[email protected]!65%JlNB1z';mysql> OTORGAR RECARGA, BLOQUEAR TABLAS, PROCESO, SUPER, CLIENTE DE REPLICACIÓN EN *.* A ejemplo@ sqldat.com; b) Cree usuarios de replicación para todos los hosts de base de datos (contraseña tomada de la variable repl_password dentro de /etc/cmon.d/cmon_X.cnf en el servidor ClusterControl, donde X es el ID de clúster del clúster esclavo):
mysql> CREAR USUARIO 'rpl_user'@'192.168.10.31' IDENTIFICADO POR '68n61F+bdsW1}[email protected]}x5J';mysql> OTORGAR ESCLAVO DE REPLICACIÓN EN *.* A 'rpl_user'@' 192.168.10.31';mysql> CREAR USUARIO 'rpl_user'@'192.168.10.32' IDENTIFICADO POR '68n61F+bdsW1}[email protected]}x5J';mysql> OTORGAR ESCLAVO DE REPLICACIÓN EN *.* A 'rpl_user'@'192.168 .10.32'; c) Cree dos usuarios de la base de datos cmon (uno para la dirección IP y otro para el nombre de host) para el uso de ClusterControl (contraseña tomada de la variable mysql_password dentro de /etc/cmon.d/cmon_X.cnf en el servidor de ClusterControl, donde X es la ID de clúster del esclavo grupo):
mysql> CREAR USUARIO [email protected]'192.168.10.19' IDENTIFICADO POR 'My&Passw0rd90';mysql> OTORGAR TODOS LOS PRIVILEGIOS EN *.* A [email protected]'192.168.10.19' CON OPCIÓN DE CONCESIÓN; mysql> CREAR USUARIO [email protected]'cc.local' IDENTIFICADO POR 'Mi&Contraseña0rd90';mysql> OTORGAR TODOS LOS PRIVILEGIOS EN *.* A [email protected]'cc.local' CON LA OPCIÓN DE OTORGAR; 5) En este punto, mysql57a debería aparecer en verde en ClusterControl. Ahora, podemos configurar un enlace de replicación de mysql57a a mysql57b. En mysql57b:
ejemplo @sqldat.com}x5J';mysql> INICIAR ESCLAVO;mysql> MOSTRAR ESTADO DEL ESCLAVO\G**No necesitamos especificar MASTER_LOG_FILE y MASTER_LOG_POS porque siempre comenzará con una posición inicial fija después de RESET MASTER en el paso #1.
Asegúrese de ver las siguientes líneas:
Slave_IO_Running:Sí Slave_SQL_Running:Sí Supervise el estado de replicación y asegúrese de que mysql57b se mantenga al día con mysql57a y mysql57a se mantenga al día con mysql56a. Es posible que deba habilitar solo lectura en mysql57b (y/o mysql57a) después de eso, para protegerse contra escrituras accidentales.
mysql> SET GLOBAL super_read_only =1;mysql> SET GLOBAL read_only =1; Desde la interfaz de usuario de ClusterControl, verá el estado actual en la sección Descripción general:
En este punto, el nuevo maestro mysql57a, 192.168.10.31 se está replicando desde el antiguo host independiente mysql56a, 192.168.10.22, mientras que el nuevo esclavo mysql57b (solo lectura) se replica desde mysql57a, 192.168.10.31. Todos los nodos se sincronizan con el retraso de replicación 0.
Alternativamente, puede comentar las siguientes líneas dentro de los archivos de configuración de MySQL en la sección [mysqld]:
#gtid_mode=ON#enforce_gtid_consistency=1 Habilitación de GTID en el clúster esclavo
Tenga en cuenta que para MySQL 5.6 y versiones posteriores, ClusterControl ya no admite la implementación que no sea GTID en algunas de sus funciones de administración, como Reconstruir esclavo de replicación y Cambiar maestro de replicación. Por lo tanto, durante el tiempo límite (cuando dirige las aplicaciones al nuevo clúster) desde el servidor MySQL independiente (mysql56a), se recomienda volver a habilitar GTID en mysql57a y mysql57b con los siguientes pasos:
1) Asegúrese de desactivar la función de recuperación automática de ClusterControl:
2) Durante la ventana de mantenimiento de corte, tenemos que dejar de replicar del antiguo maestro, mysql56a, elimine toda la configuración de esclavos en mysql57a y habilite nuevamente GTID. En mysql57a, ejecute los siguientes comandos en el orden correcto:
mysql> MOSTRAR ESTADO DEL ESCLAVO\G # Asegúrese de ver "El esclavo ha leído todo el registro del relé" mysql> DETENER ESCLAVO;mysql> RESTABLECER TODO ESCLAVO;mysql> SET GLOBAL super_read_only =0;mysql> SET GLOBAL read_only =0;mysql> SET GLOBAL gtid_mode ='OFF_PERMISSIVE';mysql> SET GLOBAL gtid_mode ='ON_PERMISSIVE';mysql> SET GLOBAL enforce_gtid_consistency ='ON';mysql> SET GLOBAL gtid_mode ='ON'; En este punto, es prácticamente seguro que su aplicación comience a escribir en el nuevo maestro, mysql57a. El antiguo MySQL independiente ahora está fuera de la cadena de replicación y se puede cerrar.
3) Repita los mismos pasos para mysql57b. Recuerda seguir los pasos en el orden correcto:
mysql> MOSTRAR ESTADO DEL ESCLAVO\G # Asegúrese de ver "El esclavo ha leído todo el registro del relé" mysql> DETENER ESCLAVO;mysql> RESTABLECER TODO ESCLAVO;mysql> SET GLOBAL super_read_only =0;mysql> SET GLOBAL read_only =0;mysql> SET GLOBAL gtid_mode ='OFF_PERMISSIVE';mysql> SET GLOBAL gtid_mode ='ON_PERMISSIVE';mysql> SET GLOBAL enforce_gtid_consistency ='ON';mysql> SET GLOBAL gtid_mode ='ON'; 4) Luego, reinicie el maestro en el nuevo maestro, mysql57a:
mysql> RESTABLECER MAESTRO; 3) Luego, en el nuevo esclavo, mysql57b configure el enlace de replicación usando GTID para mysql57a:
mysql> RESET MASTER;mysql> CAMBIAR MASTER A MASTER_HOST ='192.168.10.31', MASTER_USER ='rpl_user', MASTER_PASSWORD ='68n61F+bdsW1}[email protected]}x5J', MASTER_AUTO_POSITION =1; mysql> INICIAR ESCLAVO;mysql> MOSTRAR ESTADO DEL ESCLAVO\G Asegúrese de ver que los campos Retrieved_Gtid_Set y Executed_Gtid_Set tienen su valor GTID.
4) En este punto, hemos restaurado la configuración de replicación como la configuró previamente ClusterControl durante la etapa de implementación del clúster. Luego, podemos habilitar solo lectura en el nuevo esclavo, mysql57b para protegerlo contra escrituras accidentales:
mysql> SET GLOBAL super_read_only =1;mysql> SET GLOBAL read_only =1; Finalmente, vuelva a habilitar la recuperación automática de ClusterControl para el clúster, cambiando los íconos de encendido a verde. A continuación, puede desmantelar el antiguo maestro, mysql56a. Acabamos de completar nuestra migración en línea de MySQL 5.6 a MySQL 5.7 con un tiempo de inactividad mínimo. Los pasos similares también deberían funcionar para la migración a MySQL 8.0.
