Practical MySQL & MariaDB

Replicación MySQL Explicada: Configuración, GTID, Monitoreo y Guía de Solución de Problemas

Avanzado / Otros
目次

1. ¿Qué es la replicación de MySQL? Visión general y casos de uso

La replicación de MySQL es una funcionalidad que sincroniza copias de una base de datos con otros servidores en tiempo real. Esto mejora la redundancia y el rendimiento de la base de datos. A continuación, explicamos en detalle cuándo se utiliza la replicación de MySQL y cómo funciona.

Visión general de la replicación de MySQL

La replicación de MySQL comparte el contenido de la base de datos entre varios servidores mediante un servidor maestro y uno o más servidores esclavos. Concretamente, las actualizaciones de datos registradas en el registro binario del servidor maestro son leídas y aplicadas por los servidores esclavos para mantener los datos sincronizados. Esto permite la continuidad del servicio al cambiar a un servidor esclavo si el maestro sufre una falla.

Casos de uso de la replicación de MySQL

La replicación de MySQL se emplea ampliamente en los siguientes escenarios:

  • Alta disponibilidad : En caso de falla, cambiar a un servidor esclavo minimiza el tiempo de inactividad.
  • Balanceo de carga : Las consultas de solo lectura pueden distribuirse a los servidores esclavos, reduciendo la carga del servidor maestro.
  • Protección de datos y respaldo : Como la replicación duplica los datos en tiempo real, también puede servir como mecanismo de respaldo.

Tipos de replicación

La replicación de MySQL incluye los siguientes tipos según el método de sincronización:

  • Replicación asíncrona : El maestro continúa sin esperar confirmación del esclavo. Esto permite tiempos de respuesta más rápidos, pero puede provocar que algunos datos no lleguen al esclavo durante una falla.
  • Replicación semisíncrona : El maestro espera la confirmación de que el esclavo ha recibido los datos antes de continuar. Esto brinda mayor fiabilidad que la replicación asíncrona, aunque con tiempos de respuesta ligeramente más lentos.

La siguiente sección explica los conceptos fundamentales de la replicación de MySQL, incluidos los registros binarios y GTID.

2. Conceptos básicos de la replicación de MySQL

Para comprender la replicación de MySQL, es importante entender los roles del registro binario y del GTID (Identificador Global de Transacción), que desempeñan funciones críticas en el proceso de replicación. Estos elementos forman la base para una replicación de datos precisa.

Roles del maestro y del esclavo

En la replicación de MySQL, el servidor maestro y el servidor esclavo tienen roles distintos. El maestro registra las actualizaciones de datos en el registro binario y las envía al esclavo. El esclavo aplica los registros recibidos para actualizar sus datos. Como resultado, el esclavo mantiene los mismos datos que el maestro.

Registro binario y registro de retransmisión

La replicación de MySQL se basa en los siguientes dos registros:

  1. Registro binario
  • El registro binario almacena las actualizaciones de datos (como INSERT, UPDATE y DELETE) en el servidor maestro. Esto permite que el servidor esclavo mantenga el mismo estado de datos que el maestro.
  1. Registro de retransmisión
  • El registro de retransmisión guarda los eventos del registro binario recibidos del maestro en el servidor esclavo. El hilo SQL del esclavo ejecuta el registro de retransmisión secuencialmente para aplicar los cambios de datos.

¿Qué es GTID (Identificador Global de Transacción)?

GTID es un mecanismo que asigna un ID único a cada transacción, ayudando a mantener la consistencia entre varios esclavos. Al usar GTID, ya no es necesario especificar posiciones del registro binario. Solo las transacciones que aún no se han obtenido del maestro se aplican automáticamente al esclavo, simplificando enormemente la gestión.

Ventajas de GTID

  • Identificación única : Cada transacción recibe un GTID único, identificando claramente qué transacciones se han aplicado.
  • Recuperación más sencilla : Cuando se usa GTID, solo las transacciones no aplicadas se vuelven a procesar después de reiniciar el maestro o el esclavo.
  • Gestión operativa eficiente : Incluso en entornos de gran escala con múltiples esclavos, la consistencia de las transacciones puede mantenerse con una gestión simplificada.

Para usar GTID, se requieren los ajustes gtid_mode=ON y enforce_gtid_consistency=ON. Configurar estos parámetros tanto en el maestro como en el esclavo habilita la replicación basada en GTID.

La siguiente sección explica los pasos específicos para configurar la replicación de MySQL.

3. Procedimiento de Configuración de Replicación MySQL

Esta sección explica los pasos necesarios para configurar la replicación de MySQL. Siguiendo estos pasos, podrás configurar una estructura básica maestro‑esclavo y habilitar la sincronización de datos en tiempo real.

Configuración del Servidor Maestro

Primero, edita el archivo de configuración del servidor maestro (normalmente my.cnf o my.ini) para habilitar el registro binario y establecer el ID del servidor.

  1. Editar el Archivo de Configuración
  • Añade los siguientes ajustes bajo la sección [mysqld] y asigna un ID de servidor único (por ejemplo, 1).
    [mysqld]
server-id=1
log-bin=mysql-bin
  • El server-id debe ser un número único para cada servidor, y log-bin habilita el registro binario.
  1. Crear un Usuario de Replicación
  • Crea un usuario de replicación dedicado en el servidor maestro y otórgale los privilegios necesarios.
    CREATE USER 'repl'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;
  • Este usuario es necesario para que el servidor esclavo pueda acceder a los datos del maestro.
  1. Verificar el Estado del Maestro
  • Comprueba el archivo de registro binario actual y su posición (ubicación del log). Esta información es requerida al configurar el servidor esclavo.
    SHOW MASTER STATUS;
  • El File (nombre del archivo de log) y la Position mostrados por este comando se usarán en la configuración del esclavo.

Configuración del Servidor Esclavo

A continuación, edita el archivo de configuración del servidor esclavo y configura el ID del servidor y la información del maestro.

  1. Editar el Archivo de Configuración
  • Asigna un server-id único también en el servidor esclavo (por ejemplo, 2). Este valor debe ser diferente al ID del servidor maestro.
    [mysqld]
server-id=2

  • También es habitual establecer read_only=ON para evitar escrituras de datos en el servidor esclavo. 1. Configurar la Información del Maestro en el Esclavo

  • Ejecuta el siguiente comando en el servidor esclavo, especificando el nombre de host del maestro, el usuario, el nombre del archivo de registro binario y la posición.

    CHANGE MASTER TO
    MASTER_HOST='master_host',
    MASTER_USER='repl',
    MASTER_PASSWORD='password',
    MASTER_LOG_FILE='mysql-bin.000001',
    MASTER_LOG_POS=123;

  • Introduce los valores confirmados previamente en el maestro para MASTER_LOG_FILE y MASTER_LOG_POS . 1. Iniciar la Replicación

  • Ejecuta el siguiente comando en el servidor esclavo para iniciar la replicación.

    START SLAVE;

Verificando el Estado de la Replicación

Verifica que la replicación entre el maestro y el esclavo esté configurada correctamente.

  • Verificar el Estado del Maestro
    SHOW MASTER STATUS;
  • Verificar el Estado del Esclavo
    SHOW SLAVE STATUS\G;
  • Si Slave_IO_Running y Slave_SQL_Running ambos muestran Yes, la replicación está funcionando normalmente.

La siguiente sección explica configuraciones avanzadas de replicación, incluidas las diferencias entre replicación asíncrona y semi‑síncrona y la configuración mediante GTID.

4. Tipos de Replicación y Uso Avanzado

La replicación de MySQL incluye dos tipos principales según el método de sincronización de datos: replicación asíncrona y replicación semi‑síncrona. Al comprender sus características y elegir según tu caso de uso, puedes mejorar tanto el rendimiento del sistema como su fiabilidad. Esta sección también explica los beneficios de usar GTID (Identificador Global de Transacción) para la configuración de replicación.

Diferencias entre Replicación Asíncrona y Semi‑síncrona

1. Replicación Asíncrona

En la replicación asíncrona, el servidor maestro devuelve una respuesta al cliente inmediatamente después de completar una transacción. En otras palabras, el maestro puede seguir procesando nuevas solicitudes aun cuando la sincronización con el servidor esclavo esté retrasada. Esto brinda un excelente rendimiento de respuesta y es adecuado para sistemas centrados en la distribución de carga. Sin embargo, durante una falla, existe el riesgo de que los datos que aún no se hayan aplicado al esclavo se pierdan.

2. Replicación Semi‑síncrona

En la replicación semisíncrona, el servidor maestro devuelve una respuesta al cliente solo después de confirmar que la transferencia de datos al servidor esclavo se ha completado. Esto mejora la consistencia de los datos, pero al esperar al esclavo, los tiempos de respuesta de las transacciones pueden aumentar. La replicación semisíncrona es adecuada para sistemas que requieren alta consistencia de datos o entornos donde la fiabilidad de los datos es la máxima prioridad.

Replicación usando GTID

GTID (Identificador Global de Transacción) asigna un ID único a cada transacción y mantiene la consistencia de las transacciones entre el maestro y el esclavo. Habilitar GTID facilita la gestión de la replicación en comparación con la replicación tradicional basada en la posición del registro binario.

Ventajas de GTID

  • Mejora de la consistencia de datos : Con GTID, el esclavo puede identificar automáticamente las transacciones que aún no se han aplicado, lo que facilita mantener la consistencia.
  • Gestión simplificada de la replicación : GTID mejora la eficiencia para conmutación por error, cambio maestro/esclavo y tareas de recuperación. Como ya no es necesario especificar posiciones del registro binario, las operaciones se vuelven más simples.

Configuración de replicación GTID

Para usar GTID, debe agregar y habilitar las siguientes opciones en los archivos de configuración tanto del maestro como del esclavo.

Configuración del servidor maestro

[mysqld]
server-id=1
log-bin=mysql-bin
gtid_mode=ON
enforce_gtid_consistency=ON

Configuración del servidor esclavo

[mysqld]
server-id=2
gtid_mode=ON
enforce_gtid_consistency=ON
read_only=ON

En un entorno con GTID habilitado, la replicación se realiza automáticamente mediante GTID simplemente configurando la información del maestro en el esclavo usando el comando CHANGE MASTER TO.

La siguiente sección explica los métodos de mantenimiento para la replicación de MySQL y los puntos clave de monitoreo para la gestión operativa.

5. Mantenimiento y monitoreo de la replicación

Para operar la replicación de MySQL correctamente, el mantenimiento y monitoreo regular son esenciales. Esta sección explica los comandos para verificar si la replicación funciona normalmente y cómo manejar errores comunes.

Cómo verificar el estado de la replicación

Utilice los siguientes comandos para comprobar el estado de sincronización entre el maestro y el esclavo.

Verificando el estado del maestro

Puede verificar el estado de replicación del servidor maestro usando el comando SHOW MASTER STATUS. Este comando muestra el nombre del archivo de registro binario actual y su posición, lo que le permite confirmar las últimas actualizaciones que deben entregarse al esclavo.

SHOW MASTER STATUS;

La salida normalmente incluye los siguientes campos:

  • File : El nombre del archivo de registro binario actual generado por el maestro
  • Position : La posición actual dentro del registro binario
  • Binlog_Do_DB y Binlog_Ignore_DB : Bases de datos incluidas/excluidas de la replicación

Verificando el estado del esclavo

Puede comprobar el estado de replicación del servidor esclavo usando el comando SHOW SLAVE STATUS. Los resultados incluyen la información necesaria para determinar si el esclavo está funcionando correctamente.

SHOW SLAVE STATUS\G;

Los campos clave incluyen:

  • Slave_IO_Running y Slave_SQL_Running : Si ambos son Yes, el esclavo está funcionando normalmente.
  • Seconds_Behind_Master : Indica cuánto tiempo lleva el esclavo detrás del maestro (en segundos). Idealmente, este valor debería ser 0.

Solución de problemas de replicación

Los problemas comunes durante la operación de replicación incluyen errores de conexión e inconsistencias de datos. A continuación se presentan casos de error típicos y cómo abordarlos.

1. Errores de conexión

Si Slave_IO_Running es No, significa que el esclavo no puede conectarse al maestro. Intente lo siguiente:

  • Verifique el nombre de host o la dirección IP del maestro : Asegúrese de que la dirección del maestro sea correcta.
  • Revise la configuración del firewall : Confirme que el puerto requerido (usualmente 3306) esté abierto.

2. Inconsistencia de datos

If Last_Error contains an error message, a data inconsistency may have occurred between the master and slave. In such cases, stop the slave and apply corrections before restarting replication.

STOP SLAVE;
# Restart after applying fixes
START SLAVE;

3. Reducción del retraso de replicación

Replication lag can be caused by slave hardware limitations or network issues. If needed, upgrading the slave server configuration can improve performance.

The next section explores replication troubles in more detail and provides further solutions.

6. Problemas comunes y sus soluciones

During MySQL replication operation, various issues may arise. This section explains common problems and how to resolve them. Detecting issues early and applying the correct fixes helps maintain stable system operation.

1. Cuando Slave_IO_Running está detenido

Síntoma: If Slave_IO_Running shows No in the output of SHOW SLAVE STATUS, the slave is unable to connect to the master.

Causas y soluciones:

  • Problemas de red : If there is a network connectivity problem, the slave cannot access the master. Check firewall settings and confirm that the master is reachable.
  • Nombre de host o dirección IP del maestro incorrectos : Verify that the hostname or IP address specified in CHANGE MASTER TO is correct.
  • Problemas de privilegios de usuario : If the replication user on the master does not have sufficient privileges, the connection will fail. Confirm that the correct privileges have been granted using GRANT REPLICATION SLAVE .

2. Inconsistencia de datos en el esclavo

Síntoma: If data does not match between the master and slave, the slave may enter an inconsistent state.

Causas y soluciones:

  • Corrección manual de datos : Stop the slave, manually fix the problematic transaction, and then restart replication. STOP SLAVE; # Fix data if necessary START SLAVE;
  • Resincronización : If the inconsistency is large-scale, take a full backup from the master and resynchronize the slave.

3. Retraso de replicación

Síntoma: If Seconds_Behind_Master is not 0 in the output of SHOW SLAVE STATUS, the slave is lagging behind the master. Ideally, this value should be as close to 0 as possible.

Causas y soluciones:

  • Limitaciones de hardware del esclavo : If the slave server has insufficient resources, it may not keep up. Upgrading hardware can be effective.
  • Optimización de consultas : If queries received from the master take too long to execute on the slave, replication delay can occur. Adding indexes and optimizing queries can reduce processing time.

4. Errores de permisos del usuario de replicación

Síntoma: If Last_Error shows a permission-related message, the slave may not have sufficient privileges to connect to the master.

Causas y soluciones:

  • Reconfigurar los privilegios del usuario : Ensure that a user with appropriate privileges exists on the master. Reconfigure if necessary. GRANT REPLICATION SLAVE ON *.* TO 'repl'@'slave_ip_address'; FLUSH PRIVILEGES;

5. Crecimiento del registro binario

Síntoma: The master’s binary logs may grow excessively, consuming disk space.

Causas y soluciones:

  • Rotación de registros binarios : Regularly delete or archive binary logs to prevent excessive growth. By configuring expire_logs_days , you can automatically remove logs older than a specified period. SET GLOBAL expire_logs_days = 7; # Delete logs older than 7 days

By understanding these common MySQL replication issues and their solutions, you can ensure smoother operational management. The next section summarizes key points for replication management.

7. Conclusión

La replicación de MySQL es una característica crítica para mejorar la consistencia de los datos y la fiabilidad del sistema. En este artículo, cubrimos todo, desde los conceptos básicos de la replicación de MySQL hasta los procedimientos de configuración, las prácticas de monitoreo y los métodos de solución de problemas. A continuación, se muestra un resumen de los puntos clave para una gestión eficaz de la replicación.

Key Takeaways

  1. Choosing the Right Replication Type
  • La replicación asíncrona ofrece tiempos de respuesta más rápidos y es ideal para la distribución de carga. Sin embargo, si la fiabilidad es la prioridad, la replicación semisíncrona es más adecuada. Elija según los requisitos de su sistema.
  1. Effective Use of GTID
  • GTID elimina la necesidad de especificar posiciones del registro binario y permite una gestión fluida de las transacciones. Es especialmente útil en entornos con múltiples esclavos o donde el failover es crítico.
  1. Regular Status Monitoring
  • Utilice SHOW MASTER STATUS y SHOW SLAVE STATUS para monitorear regularmente el estado operativo de los servidores maestro y esclavo. Una acción rápida al detectar anomalías minimiza riesgos como la inconsistencia de datos o el retraso.
  1. Mastering Basic Troubleshooting
  • Los problemas comunes de replicación incluyen errores de conexión del esclavo, inconsistencias de datos y retrasos. Comprender soluciones básicas para cada problema garantiza operaciones más fluidas.
  1. Binary Log Management
  • Dado que los registros binarios pueden consumir un espacio de disco significativo, se recomienda configurar expire_logs_days para la limpieza automática y realizar mantenimiento regular.

La replicación de MySQL no es una tarea de configuración única. El monitoreo continuo y el mantenimiento adecuado son esenciales. Al revisar regularmente el estado del sistema y ajustar las configuraciones cuando sea necesario, puede construir y mantener un sistema de bases de datos altamente fiable.

Esperamos que esta guía le ayude a comprender e implementar mejor la replicación de MySQL. Le deseamos operaciones de replicación fluidas y estables.