Cuando se trabaja con bases de datos, puede resultar útil disponer de varias copias de los datos. Esto proporciona redundancia en caso de que falle uno de los servidores de bases de datos y puede mejorar la disponibilidad, escalabilidad y rendimiento general de una base de datos. La práctica de sincronizar datos a través de múltiples bases de datos separadas se denomina replicación.

Introducción

MySQL es un sistema de gestión de bases de datos relacionales, y es la base de datos relacional de código abierto más popular del mundo en la actualidad. Viene instalada con un número de características de replicación incorporadas, permitiéndole mantener múltiples copias de sus datos.

Este tutorial describe cómo configurar una instancia de MySQL en un servidor como base de datos de origen y luego configurar una instancia de MySQL en otro servidor para que funcione como su réplica. También incluye una visión general de cómo MySQL maneja la replicación.

Nota: Históricamente, este tipo de replicación de bases de datos se ha denominado replicación «maestro-esclavo». En una entrada de blog publicada en julio de 2020, el equipo de MySQL reconoció el origen negativo de esta terminología y anunció sus esfuerzos por actualizar el programa de base de datos y su documentación para utilizar un lenguaje más inclusivo.

Sin embargo, este es un proceso en curso. Aunque la documentación de MySQL y gran parte de los comandos de la versión 8 del programa se han actualizado para referirse en su lugar a los servidores de una topología de replicación como el origen y sus réplicas, hay lugares donde todavía aparece la terminología negativa. Esta guía utilizará por defecto la terminología más inclusiva fuente-replica siempre que sea posible, pero hay algunos casos en los que los términos antiguos aparecen inevitablemente.

Replicación en MySQL

En MySQL, la replicación implica que la base de datos de origen anote todos los cambios realizados en los datos contenidos en una o más bases de datos en un archivo especial conocido como el registro binario. Una vez que la instancia de réplica ha sido inicializada, crea dos procesos enhebrados. El primero, llamado el hilo IO, se conecta a la instancia MySQL fuente y lee los eventos del registro binario línea por línea, y luego los copia en un archivo local en el servidor de la réplica llamado el registro de retransmisión. El segundo hilo, llamado hilo SQL, lee los eventos del registro de retransmisión y luego los aplica a la instancia de réplica lo más rápido posible.

Las versiones recientes de MySQL soportan dos métodos para replicar datos. La diferencia entre estos métodos de replicación tiene que ver con cómo las réplicas rastrean qué eventos de base de datos de la fuente ya han procesado.

MySQL se refiere a su método de replicación tradicional como replicación basada en la posición del archivo de registro binario. Cuando convierte una instancia MySQL en una réplica utilizando este método, debe proporcionarle un conjunto de coordenadas de registro binario. Éstas consisten en el nombre del fichero de registro binario en el origen que la réplica debe leer y una posición específica dentro de ese fichero que representa el primer evento de base de datos que la réplica debe copiar a su propia instancia MySQL.

Estas coordenadas son importantes ya que las réplicas reciben una copia de todo el registro binario de su fuente y, sin las coordenadas correctas, comenzarán a replicar cada evento de base de datos registrado en él. Esto puede dar lugar a problemas si sólo desea replicar datos después de un cierto punto en el tiempo o sólo desea replicar un subconjunto de los datos de la fuente.

La replicación basada en la posición del archivo de registro binario es viable para muchos casos de uso, pero este método puede volverse torpe en configuraciones más complejas. Esto llevó al desarrollo del nuevo método de replicación nativa de MySQL, que a veces se conoce como replicación basada en transacciones. Este método implica la creación de un identificador de transacción global (GTID) para cada transacción - o, una pieza aislada de trabajo realizada por una base de datos - que la instancia MySQL fuente ejecuta.

La mecánica de la replicación basada en transacciones es similar a la replicación basada en archivos de registro binarios: cada vez que se produce una transacción de base de datos en el origen, MySQL asigna y registra un GTID para la transacción en el archivo de registro binario junto con la propia transacción. El GTID y la transacción se transmiten entonces a las réplicas de la fuente para que las procesen.

La replicación basada en transacciones de MySQL tiene una serie de beneficios sobre su método de replicación tradicional. Por ejemplo, debido a que tanto una fuente como sus réplicas preservan los GTIDs, si la fuente o una réplica encuentran una transacción con un GTID que han procesado antes, omitirán esa transacción. Esto ayuda a garantizar la coherencia entre el origen y sus réplicas. Además, con la replicación basada en transacciones, las réplicas no necesitan conocer las coordenadas del registro binario del siguiente evento de base de datos a procesar. Esto significa que iniciar nuevas réplicas o cambiar el orden de las réplicas en una cadena de replicación es mucho menos complicado.

Ten en cuenta que esto es sólo una explicación general de cómo MySQL maneja la replicación; MySQL proporciona muchas opciones que puede ajustar para optimizar su propia configuración de replicación. Esta guía describe cómo configurar la replicación basada en la posición de ficheros de registro binarios. Si está interesado en configurar un tipo diferente de entorno de replicación, le recomendamos que consulte la documentación oficial de MySQL .

Configuración de la base de datos de origen

Para que su base de datos MySQL de origen comience a replicar datos, necesita realizar algunos cambios en su configuración.

E fichero de configuración por defecto del servidor MySQL se llama mysqld.cnf y se encuentra en el directorio /etc/mysql/mysql.conf.d/. Abra este archivo en el servidor fuente con su editor de texto preferido. Aquí, usaremos nano:

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

bind-address            = 127.0.0.1

127.0.0.1 es una dirección IPv4 loopback que representa localhost, y establecer esto como valor para la directiva bind-address instruye a MySQL para que sólo escuche conexiones en la dirección localhost. En otras palabras, esta instancia MySQL sólo podrá aceptar conexiones que se originen desde el servidor donde está instalada.

Recuerde que está convirtiendo su otra instancia MySQL en una réplica de ésta, por lo que la réplica debe ser capaz de leer cualquier dato nuevo que se escriba en la instalación de origen. Para permitir esto, debe configurar su instancia MySQL de origen para escuchar conexiones en una dirección IP que la réplica pueda alcanzar, como la dirección IP pública del servidor de origen.

Sustituye 127.0.0.1 por la dirección IP del servidor de origen. Después de hacer esto, la directiva bind-address tendrá este aspecto, con la dirección IP de su propio servidor.

A continuación, busque la directiva server-id, que define un identificador que MySQL utiliza internamente para distinguir servidores en una configuración de replicación. Cada servidor en un entorno de replicación, incluyendo la fuente y todas sus réplicas, debe tener su propio valor server-id único. Esta directiva será comentada por defecto y tendrá este aspecto:

server-id               = 1

Activa el log binario:

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

Indica la bases de datos:

binlog_do_db          = db 

Nota: Si quieres replicar más de una base de datos, puedes añadir otra directiva binlog_do_db por cada base de datos que quieras añadir. Este tutorial continuará con la replicación de una única base de datos, pero si quisieras replicar más podría tener este aspecto:

/etc/mysql/mysql.conf.d/mysqld.cnf

binlog_do_db = db

binlog_do_db = db_1

binlog_do_db = db_2

Alternativamente, puede especificar qué bases de datos MySQL no debe replicar añadiendo una directiva binlog_ignore_db para cada una de ellas:

binlog_ignore_db = db_to_ignore

binlog_format = ROW

Los valores posibles son ROW (la réplica sólo reproduce los cambios reales en la fila), STATEMENT (la réplica reproduce todas las consultas que cambian los datos), MIXED (la réplica basada en sentencias se utiliza a menos que el servidor decida que sólo la réplica basada en filas puede dar un resultado adecuado, como replicar el resultado de GUUID() ). 

Reinicia MySQL

sudo systemctl restart mysql 

Con esto, esta instancia MySQL está lista para funcionar como la base de datos fuente que su otro servidor MySQL replicará. Antes de que pueda configurar su réplica, sin embargo, todavía hay algunos pasos más que necesita realizar en la fuente para asegurarse de que su topología de replicación funcionará correctamente. El primero de ellos es crear un usuario MySQL dedicado que realizará cualquier acción relacionada con el proceso de replicación.

Crear un Usuario de Replicación

Cada réplica en un entorno de replicación MySQL se conecta a la base de datos origen con un nombre de usuario y una contraseña. Las réplicas pueden conectarse usando cualquier perfil de usuario MySQL que exista en la base de datos fuente y que tenga los privilegios apropiados, pero este tutorial describirá cómo crear un usuario dedicado para este propósito.

Nota: Si ha configurado un usuario MySQL dedicado que se autentifica mediante una contraseña, puede conectarse a su MySQL con un comando como este en su lugar:

    mysql -u sammy -p

Sustituye sammy por el nombre de su usuario dedicado e introduzca la contraseña de este usuario cuando se solicite.

Ten en cuenta que algunas operaciones de esta guía, incluidas algunas que deben realizarse en el servidor de réplica, requieren privilegios avanzados. Debido a esto, puede ser más conveniente conectarse como un usuario administrativo, como puedes hacer con el comando anterior sudo mysql. Sin embargo, si desea utilizar un usuario MySQL con menos privilegios a lo largo de esta guía, al menos se le deben conceder los privilegios CREATE USER, RELOAD, REPLICATION CLIENT, REPLICATION SLAVE y REPLICATION_SLAVE_ADMIN.

Desde el prompt, crea un nuevo usuario MySQL. El siguiente ejemplo creará un usuario llamado replica_user, pero puedes nombrar el tuyo como quieras. Asegúrese de cambiar replica_server_ip a la dirección IP pública de su servidor de réplica y cambiar la contraseña a una contraseña segura de su elección:

CREATE USER 'replica_user'@'replica_server_ip' IDENTIFIED WITH mysql_native_password BY 'password';

Ten en cuenta que este comando especifica que replica_user utilizará el complemento de autenticación mysql_native_password. Es posible usar en su lugar el mecanismo de autenticación por defecto de MySQL, caching_sha2_password, pero esto requeriría configurar una conexión encriptada entre la fuente y la réplica. Este tipo de configuración sería óptima para entornos de producción, pero la configuración de conexiones cifradas está fuera del alcance de este tutorial. La documentación de MySQL incluye instrucciones sobre cómo configurar un entorno de replicación que utilice conexiones encriptadas si desea hacerlo.

Después de crear el nuevo usuario, concédale los privilegios apropiados. Como mínimo, un usuario de replicación MySQL debe tener permisos de ESCLAVO DE REPLICACIÓN:

GRANT REPLICATION SLAVE ON *.* TO 'replica_user'@'replica_server_ip';

A continuación, es recomendable ejecutar el comando FLUSH PRIVILEGES. Esto liberará la memoria que el servidor haya almacenado en caché como resultado de las sentencias CREATE USER y GRANT anteriores:

FLUSH PRIVILEGES; 

Configuración de la base de datos de réplica

Todo lo que queda por hacer es cambiar la configuración de la réplica de forma similar a como cambió la del origen. Abra el archivo de configuración de MySQL, mysqld.cnf, esta vez en su servidor de réplica:

    sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

Como se mencionó anteriormente, cada instancia de MySQL en una configuración de replicación debe tener un único valor server-id. Encuentre la directiva server-id de la réplica, descoméntela y cambie su valor a cualquier número entero positivo, siempre y cuando sea diferente al de la fuente:

server-id = 2

A continuación, actualiza los valores de log_bin y binlog_do_db para que coincidan con los que estableciste en el archivo de configuración de la máquina de origen:

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

. . .

binlog_do_db = db

Por último, añada una directiva relay-log que defina la ubicación del archivo de registro de retransmisión de la réplica. Incluya la siguiente línea al final del archivo de configuración:

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

Tras realizar estos cambios, guarde y cierre el archivo. A continuación, reinicie MySQL en la réplica para implementar la nueva configuración:

    sudo systemctl restart mysql

Después de reiniciar el servicio mysql, por fin estás listo para empezar a replicar datos desde tu base de datos de origen. 

Iniciando y Probando la Replicación

En este punto, ambas instancias de MySQL están completamente configuradas para permitir la replicación. Para empezar a replicar datos desde su fuente, abra el shell de MySQL en su servidor de réplica:

Desde el prompt, ejecute la siguiente operación, que configura varios parámetros de replicación MySQL al mismo tiempo. Después de ejecutar este comando, una vez que habilite la replicación en esta instancia, intentará conectarse a la dirección IP que sigue a SOURCE_HOST utilizando el nombre de usuario y la contraseña que siguen a SOURCE_USER y SOURCE_PASSWORD, respectivamente. También buscará un archivo de registro binario con el nombre SOURCE_LOG_FILE y empezará a leerlo desde la posición después de SOURCE_LOG_POS.

Asegúrate de sustituir source_server_ip por la dirección IP de tu servidor de origen. Del mismo modo, replica_user y password deberían coincidir con el usuario de replicación que creaste en el Paso 2; y mysql-bin.000001 y 899 deberían reflejar las coordenadas binarias del log que obtuviste en el Paso 3.

Es posible que desees escribir este comando en un editor de texto antes de ejecutarlo en tu servidor de réplica para que puedas reemplazar más fácilmente toda la información relevante:

CHANGE REPLICATION SOURCE TO
SOURCE_HOST='source_server_ip',
SOURCE_USER='replica_user',
SOURCE_PASSWORD='password',
SOURCE_LOG_FILE='mysql-bin.000001',
SOURCE_LOG_POS=899;

Versiones antiguas de MySQL deberemos usar:

CHANGE MASTER TO
 MASTER_HOST='ip',
MASTER_USER='replication_user',
MASTER_PASSWORD='xxx',
MASTER_LOG_FILE='mysql-bin.000002',
MASTER_LOG_POS=20022451;

A continuación, active el servidor de réplica:

    START REPLICA;

o START SLAVE; si es MySQL antiguo

Si has introducido todos los detalles correctamente, esta instancia comenzará a replicar cualquier cambio realizado en la base de datos db en el origen.

Puedes ver detalles sobre el estado actual de la réplica ejecutando la siguiente operación. El modificador \G en este comando reordena el texto para hacerlo más legible:

    SHOW REPLICA STATUS\G;

o bien SHOW SLAVE STATUS\G; si es MySQL anterior

Este comando devuelve mucha información que puede ser útil a la hora de solucionar problemas:

             Replica_IO_State: Waiting for master to send event

                  Fuente_Host: 138.197.3.190

                  Source_User: replica_user

                  Puerto_fuente: 3306

                Conectar_repetición: 60

              Source_Log_File: mysql-bin.000001

          Read_Source_Log_Pos: 1273

               Relay_Log_File: mysql-relay-bin.000003

                Relay_Log_Pos: 729

        Relay_Source_Log_File: mysql-bin.000001

Lo importante es:

Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Slave_IO_State: Waiting for master to send event

 Recuperar coordenadas de registro binario del origen

Recuerda de la sección Entendiendo la Replicación en MySQL que MySQL implementa la replicación copiando eventos de base de datos desde el archivo de registro binario fuente línea por línea e implementando cada evento en la réplica. Cuando se usa la replicación basada en la posición del archivo de registro binario de MySQL, debe proporcionar a la réplica un conjunto de coordenadas que detallen el nombre del archivo de registro binario de la fuente y una posición específica dentro de ese archivo. La réplica utiliza estas coordenadas para determinar el punto del archivo de registro desde el que debe comenzar a copiar los eventos de la base de datos y realizar un seguimiento de los eventos que ya ha procesado.

Este paso describe cómo obtener las coordenadas de registro binario actuales de la instancia de origen para configurar sus réplicas para que comiencen a replicar datos desde el último punto del archivo de registro. Para asegurarse de que ningún usuario cambia los datos mientras obtiene las coordenadas, lo que podría provocar problemas, deberá bloquear la base de datos para evitar que ningún cliente lea o escriba datos mientras obtiene las coordenadas. En breve desbloquearás todo, pero este procedimiento hará que tu base de datos sufra cierto tiempo de inactividad.

Todavía debes tener abierto el intérprete de comandos MySQL de su servidor fuente desde el final del paso anterior. Desde el prompt, ejecute el siguiente comando que cerrará todas las tablas abiertas en cada base de datos en su instancia fuente y las bloqueará:

FLUSH TABLES WITH READ LOCK;

A continuación, ejecuta la siguiente operación que devolverá la información de estado actual de los archivos de registro binario de la fuente:

SHOW MASTER STATUS;

Esta es la posición desde la que la réplica comenzará a copiar los eventos de la base de datos. Anote el nombre del archivo y el valor de la posición, ya que los necesitará más adelante cuando inicie la replicación.

Lo que hagas inmediatamente después de obtener esta información dependerá de si su base de datos de origen tiene algún dato existente que desee migrar a sus réplicas. 

Arquitectura de la replicación MySQL

Cuando se realiza una transacción en el nodo primario, los cambios de datos asociados se registran en un log especial llamado log binario (binlog). Este registro consiste en «eventos» que describen cambios en la base de datos, como cambios DDL o DML, y se mantiene además del registro de escritura anticipada, o el redo log como MySQL lo llama. En el servidor réplica, un hilo IO especial mantiene una conexión persistente con el servidor primario, leyendo los eventos binlog a medida que se escriben en el primario, manteniéndose así al día con cada evento de cambio. El subproceso IO de la réplica escribe estos eventos en un registro especial llamado registro de retransmisión. Un subproceso SQL independiente en el servidor de réplica lee los registros de retransmisión y ejecuta los eventos de cambio que contienen. En efecto, estamos reproduciendo en la réplica todos los cambios de datos que tuvieron lugar en el servidor primario. El retardo de replicación, según informa la réplica, es la diferencia de tiempo entre el último evento de cambio escrito en el registro de retransmisión (por el subproceso IO) y el último evento aplicado desde el registro de retransmisión por el subproceso SQL. Tenga en cuenta que el retardo reportado no tiene en cuenta un hilo IO lento.

MySQL soporta varios modos de replicación, tales como replicación semisincrónica, replicación de grupo y replicación asincrónica. Nuestra configuración RDS sólo permitía la replicación asíncrona, y en esta entrada de blog, sólo nos centraremos en eso.

Desactivación de registros binarios en las réplicas

Cuando una transacción se confirma, sus cambios se escriben inicialmente en un buffer en memoria para mejorar el rendimiento de escritura. Para asegurar la durabilidad y protegerse contra posibles caídas, MySQL escribe los cambios de datos en su registro de escritura anticipada, conocido como registro de rehacer, durante la transacción. Y en el momento de la confirmación, estas escrituras WAL se sincronizan con el disco. Este mecanismo permite a MySQL recuperar transacciones comprometidas en caso de fallo.

Cuando el registro binario está habilitado en una instancia, se convierte en parte del proceso de confirmación, con los cambios siendo sincronizados con el archivo de registro binario en el disco inmediatamente después de que el registro de rehacer es sincronizado. Esto duplica efectivamente el número de costosas sincronizaciones de archivos en el momento de la confirmación (puede obtener más información sobre este proceso aquí, que entra en mayor detalle).

En nuestra configuración, estas sincronizaciones afectan significativamente a la latencia de la confirmación, sobre todo porque utilizamos EBS (Elastic Block Store). Para poner las cosas en contexto, el mejor tipo de EBS disponible para RDS en ese momento era io1, que sólo garantizaba una latencia de un milisegundo para operaciones de lectura/escritura el 99,9% de las veces. En cambio, las unidades SSD locales suelen ofrecer una latencia de decenas de microsegundos.

En resumen, estas son las mejoras más importantes que hemos implementado para reducir el retraso:

•  La replicación multihilo es lo más importante que puede hacer para reducir el retraso. Hemos descubierto que habilitar GTID y actualizar su versión de MySQL a la 8.0.18 solucionará los problemas de fiabilidad que encontramos.
• Considera designar réplicas separadas como objetivos de conmutación por error que no sirvan tráfico en vivo, y deshabilite los registros binarios en esas réplicas de no conmutación por error para minimizar el retardo.
• Establece binlog_transaction_dependency_tracking en WRITESET para aumentar la paralelizabilidad de la replicación de transacciones. Esto se ha hecho por defecto a partir de 8.2.0.

Consejos Rendimiento

En Cloud SQL, los valores por defecto, mínimo permitido y máximo permitido del indicador innodb_buffer_pool_size dependen de la memoria de la instancia. Estos valores pueden calcularse aproximadamente como un porcentaje de la RAM de la instancia. Por defecto, el valor de este indicador suele estar cerca del valor máximo permitido. El porcentaje de asignación máximo permitido aumenta con el tamaño de la instancia. El valor mínimo permitido suele estar en torno al 20% de la RAM de la instancia.

• Ajusta innodb_io_capacity e innodb_io_capacity_max para optimizar el rendimiento de E/S.
• Para obtener un mayor rendimiento en la réplica de lectura, establezca el valor de innodb_flush_log_at_trx_commit en 2. Si establece el valor del indicador en 2, deberá desactivar el registro binario en la réplica, o establecer syc_binlog en un valor distinto de 1.

Nota: Para el cumplimiento completo de ACID, y para mantener la durabilidad y la consistencia en una configuración de replicación, los indicadores innodb_flush_log_at_trx_commit y sync_binlog deben establecerse al valor predeterminado de 1. Por lo tanto, después de la promoción, estos indicadores se eliminarán automáticamente.

Replicación retardada (delay)

MySQL soporta replicación retardada de tal forma que un servidor de réplica deliberadamente se retrasa respecto al origen al menos una cantidad de tiempo especificada. El retraso por defecto es de 0 segundos. Use la opción MASTER_DELAY para CHANGE MASTER TO para establecer el retardo a N segundos:

CHANGE MASTER TO MASTER_DELAY = N;

Un evento recibido de la fuente no se ejecuta hasta al menos N segundos después de su ejecución en la fuente. Las excepciones son que no hay retardo para eventos de descripción de formato o eventos de rotación de archivos de registro, que afectan sólo al estado interno del hilo SQL.

La replicación retardada se puede utilizar para varios propósitos:

• Para proteger contra errores del usuario en la fuente. Un DBA puede hacer retroceder una réplica retardada al momento justo antes del desastre.
• Para probar cómo se comporta el sistema cuando hay un retraso. Por ejemplo, en una aplicación, un retraso puede ser causado por una carga pesada en la réplica. Sin embargo, puede ser difícil generar este nivel de carga. La replicación retardada puede simular el retardo sin tener que simular la carga. También puede utilizarse para depurar condiciones relacionadas con una réplica retrasada.
• Para inspeccionar cómo era la base de datos hace tiempo, sin tener que recargar una copia de seguridad. Por ejemplo, si el retraso es de una semana y el DBA necesita ver cómo era la base de datos antes de los últimos días de desarrollo, se puede inspeccionar la réplica retrasada. 

START SLAVE y STOP SLAVE tienen efecto inmediato e ignoran cualquier retardo. RESET SLAVE reinicia el retardo a 0.

SHOW SLAVE STATUS tiene tres campos que proveen información sobre el retardo:

•  SQL_Delay: Un entero no negativo que indica el número de segundos que la réplica debe retrasar al origen.
• SQL_Remaining_Delay: Cuando Slave_SQL_Running_State es Waiting until MASTER_DELAY segundos después de que el maestro ejecutara el evento, este campo contiene un entero que indica el número de segundos que quedan del retardo. En otras ocasiones, este campo es NULL.
•  Slave_SQL_Running_State: Cadena que indica el estado del hilo SQL (análogo a Slave_IO_State). El valor es idéntico al valor del estado del subproceso SQL mostrado por SHOW PROCESSLIST. 
• Cuando el subproceso SQL de replicación está esperando a que transcurra el retardo antes de ejecutar un evento, SHOW PROCESSLIST muestra su valor de estado como Waiting until MASTER_DELAY segundos después de que el maestro haya ejecutado el evento. 

Replicación bidireccional

Cualquier modificación de datos en un nodo se replicará en el otro y viceversa. La replicación es bidireccional.

Simplemente replica y crea la misma configuración en el servidor 1 (Master) para que ahora se conecte al servidor 2 (Esclavo)

Errores

Normalmente la replicación MySQL se detendrá siempre que se produzca un error al ejecutar una consulta en el esclavo. Esto ocurre para poder identificar el problema y solucionarlo, y mantener los datos consistentes con el mater que ha enviado la consulta. Puedes omitir estos errores, aunque no sea recomendable, siempre y cuando sepas muy bien cuáles son esas consultas y por qué están fallando, etc.

Por ejemplo, puedes omitir sólo una consulta que está colgando el esclavo utilizando:

mysql>SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE;

Puede haber casos en los que deseas omitir más consultas. Por ejemplo, es posible que desees omitir todos los errores duplicados que pueda estar recibiendo (salida de show slave status;):

Si está sseguro de que saltarse esos errores no hará que su esclavo sea inconsistente y quiere saltárselos TODOS, añadiría al my.cnf:

slave-skip-errors = 1062

Fuentes:

https://www.digitalocean.com/community/tutorials/how-to-set-up-replication-in-mysql

https://medium.com/airtable-eng/optimizing-mysql-replication-lag-with-parallel-replication-and-writeset-based-dependency-tracking-1fc405cf023c