Replicación maestro-esclavo de MySQL usando Docker

En este artículo quiero compartir mi experiencia sobre cómo configurar la replicación de MySQL localmente usando Docker.

Se basa en este repositorio en GitHub que creé hace unos años. Contiene configuraciones e instrucciones con el ejemplo de replicación de MySQL basado en Docker. Esto es bueno para comenzar a comprender la replicación y probar declaraciones no seguras de replicación y no está diseñado para uso en producción. Después de obtener docenas de inicios, he considerado agregar algunas explicaciones más sobre cómo funciona.

En este artículo quiero darle explicaciones más detalladas sobre el proceso general. Puede ser útil para DevOps e ingenieros de software que desean crear un entorno de trabajo más cercano al entorno de producción y para aquellos que desean comprender mejor cómo es realmente la replicación de MySQL.

requisitos previos.

1. Tiene instalado Docker v.18 o superior.
2. Docker -compose v1.23 o superior instalado.
3. Conocimientos muy básicos de MySQL.

Algo de teoría.

La replicación MySQL es una configuración especial que involucra dos o más servidores MySQL donde un servidor de base de datos (conocido como maestro o fuente) se copia a otro (conocido como esclavo o réplica). El proceso de sincronización de réplicas se realiza copiando y ejecutando sentencias SQL desde el registro binario de la fuente. La configuración de MySQL permite seleccionar toda la base de datos de origen o solo tablas particulares para copiarlas en la réplica.

Por defecto, el tipo de sincronización para la replicación de MySQL es asíncrono (unidireccional), lo que significa que la "réplica" no notifica a su "fuente" sobre los resultados de los eventos de afrontamiento y procesamiento. Los tipos adicionales de sincronización (semisincrónica, síncrona) pueden estar disponibles a través de complementos o en configuraciones especiales (como NDB Cluster).

Con la replicación de MySQL se pueden realizar algunos tipos de configuración específicos: replicación encadenada , circular (también conocida como master-master o ring) y combinaciones de estas. La limitación es que la réplica solo puede tener un servidor de origen.

La replicación encadenada significa que hay una cadena de servidores de bases de datos.

Ejemplo: Origen 1 — > Réplica 1 — > Réplica 2. La Réplica 1 es fuente para la Réplica 2 y réplica para la Fuente 1. Es útil para un caso en el que la Réplica 1 contiene una base de datos "combinada", que consta de las tablas "fuente" y sus propias tablas "añadidas".

La replicación circular supone tener bases de datos maestras en el círculo, que sirven también como réplicas al mismo tiempo. Ejemplo: Maestro← → Maestro. El problema aquí es la sincronización automática de columnas incrementadas. La solución podría ser configurar ' auto_increment_increment'   y variables de servidor ' auto_increment_offset' para hacer incrementos con diferentes pasos o en diferentes rangos de acuerdo con la configuración de cada servidor maestro. Si está utilizando InnoDB, tenga en cuenta el hecho de que con la replicación en anillo, la fila no siempre se agregará al final del índice de la réplica, en tal caso, puede generar una latencia de inserción adicional en la réplica debido al orden del índice agrupado.

Práctica.

¡Es hora de hacer un poco de práctica! ¡Creo que aprender haciendo es el mejor enfoque de aprendizaje! Cree un directorio vacío y un repositorio de clones.

El proceso de compilación requiere que los puertos 4406 y 5506 no estén en uso en su sistema. De lo contrario, puede actualizarlo a cualquier puerto no utilizado en el archivo ' docker-compose.yml' y volver a ejecutar el script de compilación.

Si todo va bien, recibirá estos mensajes:

Esperando conexión a la base de datos mysql_master...

y finalmente un informe de estado de réplica (esclavo). La última línea dice que está esperando nuevas actualizaciones del maestro. Para probar que la replicación funciona, ejecute esta consulta en Master: Y verifique Réplica:

Bajo el capó. Configuración maestra.

Configuración del servidor maestro ubicada en “ master/conf/mysql.conf.cnf”. Aquí hay algo de explicación. Las primeras 2 opciones se usan para aumentar el rendimiento del servidor y no están relacionadas con la configuración de replicación en sí.

 skip-host-cache

Deshabilite el uso de la memoria caché interna del host para una resolución más rápida de nombre a IP.

 skip-name-resolve

Deshabilitar las búsquedas de nombres de host DNS

 server-id = 1

Para los servidores que se utilizan en una replicación, debe especificar un ID de servidor único. Debe ser diferente de todos los demás ID en uso por cualquier otra fuente o réplica.

 log_bin = /var/log/mysql/mysql-bin.log

Habilita el registro bin y establece el nombre base y la ruta para los archivos de registro binarios (como log_bin_basename ).

binlog_format = FILA

Los valores posibles son ROW (la réplica reproduce solo los cambios reales en la fila), STATEMENT (la réplica reproduce todas las consultas que cambian los datos), MIXED (se usa la replicación basada en declaraciones a menos que el servidor decida que solo la replicación basada en filas puede dar el resultado adecuado, como replicando el resultado de GUUID() ).

 binlog_do_db = mydb

Especifique una base de datos, cuyas declaraciones se escribirán en el archivo de registro binario.

Los parámetros del entorno relacionados con el lanzamiento de MySQL en un contenedor acoplable se colocan en el archivo " master/mysql_master.env ". Se describen en el sitio web de docker hub para la imagen .

Si es un usuario de Windows, el script build.sh probablemente no funcionará, por lo que deberá configurar la base de datos maestra con la creación del usuario `mydb_slave_user`: ejecute 2 comandos sql en Master y luego configure la base de datos esclava: ejecute 2 comandos sql en Réplica, ver detalles a continuación.

Finalmente, agregue un usuario de replicación en el servidor maestro. Cree un nuevo usuario para la replicación con el permiso REPLICATION SLAVE:

Configuración de réplicas.

Algunos de los parámetros de configuración repiten la base de datos Maestra.

 relay-log = /var/log/mysql/mysql-relay-bin.log

Contiene eventos de la base de datos, leídos desde el registro binario de origen.

Inicie una réplica.

Primero, debe encontrar una dirección IP de host maestro. Puede verificar el archivo "hosts" en el host maestro La última línea contendrá la dirección IP, ejemplo: 172.19.0.2. Este es un MASTER_HOST. En segundo lugar, busque un archivo de registro y una posición desde este comando: “Archivo:” es MASTER_LOG_FILE y “Posición:” es MASTER_LOG_POS. Ahora, cuando tengamos todas las variables, podemos modificar y ejecutar el siguiente comando para iniciar una replicación:

Declaraciones no seguras para la replicación y consultas no deterministas.

La "seguridad" de una declaración en la replicación de MySQL se refiere a si la declaración y sus efectos se pueden replicar correctamente utilizando un formato basado en declaraciones. La declaración es segura si es determinista. La declaración de medios deterministas siempre produce el mismo resultado. Cuando se utiliza el registro basado en declaraciones, las declaraciones marcadas como no seguras generan una advertencia. Consulte una lista de declaraciones inseguras . Ejemplo: FOUND_ROWS(), RAND(), UUID(). Para la replicación a nivel de fila, no se hace distinción entre declaraciones deterministas y no deterministas. El inconveniente de la replicación basada en filas es que son costosas en las actualizaciones de rango en caso de que la cláusula WHERE coincida con muchas filas.

Pensamientos finales.

La replicación es una parte poderosa de cualquier base de datos y, afortunadamente, es compatible con MySQL. El rango de uso es amplio. Se puede utilizar para distribuciones de datos y alta disponibilidad, copias de seguridad de datos, equilibrio de carga. E incluso para optimización de latencia basada en geolocalización. ¡Gracias por leer!

Publicado anteriormente en