Operación diaria de la replicación MySQL y escenarios de fallo (8.0 / 8.4)

Runbook de operación diaria y recuperación ante fallos para una topología source + replica ya instalada (async / semi-sync, GTID o posición de binlog): comprobación de estado y retraso, switchover planificado, failover, reincorporación del source antiguo, reconstrucción de una replica (clone / XtraBackup / mysqldump), errant GTID, errores 1062/1032, recuperación de datos con una replica retrasada, traslado de una replica y limpieza de binlogs. Cada escenario sigue el esquema diagnóstico → red de seguridad → aplicación → verificación → seguimiento. No es una guía de instalación: para configurar la replicación por primera vez abra la guía «Replicación GTID de MySQL»; para InnoDB Cluster (Group Replication), la guía «Operación de InnoDB Cluster».

Topología: 1 source + 1..5 replicas (async / semi-sync)

Escenarios

• Comprobación de estado y retraso (¿la replicación está sana?) — Solo lectura: threads IO/SQL, últimos errores, retraso real, estado de semi-sync y comprobación de errant GTID; no se modifica nada, sin interrupción. Si no está seguro de qué hacer, empiece aquí: el último paso le dirige al escenario adecuado según la salida.
• Switchover planificado (traspasar el rol de source a una replica) — El source y las replicas están sanos; va a traspasar de forma planificada el rol de source a una replica por mantenimiento, cambio de hardware o upgrade. Las escrituras se detienen unos minutos, no hay pérdida de datos; la vuelta atrás es el mismo escenario a la inversa.
• Source perdido: failover a la replica más adelantada — El source se ha caído o no es accesible y no volverá pronto (thread IO en Connecting en las replicas, 2003/2013). La replica más adelantada pasa a ser el nuevo source y las demás se conectan a ella. Las escrituras quedan cortadas hasta que se abre el nuevo source; con replicación async pueden perderse las últimas transacciones del source.
• Reincorporar el source antiguo como replica tras un failover — Se ha hecho un failover y el servidor del source antiguo ha vuelto. Primero se cierra a escrituras y se copian sus binlogs, y se comprueba si tiene errant transactions; si está limpio pasa directamente a replica, si no se reconstruye desde el nuevo source. Sin interrupción en el nuevo source.
• Reconstruir una replica desde cero (clone / XtraBackup / mysqldump) — Los binlogs que necesita la replica se han purgado en el source (1236), sus datos han divergido del source, los errores 1062/1032 se repiten o se ha perdido el disco de la replica. Todos los datos de la replica se sustituyen por una copia del source; el source sigue en servicio y la replica de destino no está disponible durante el proceso.
• Errant GTID: la replica tiene transacciones que el source no tiene — Hay transacciones escritas directamente en la replica (con super_read_only desactivado) o heredadas de un source antiguo; en un failover estas transacciones se propagan a las demás replicas o detienen la replicación con 1236. Solución: transacción vacía, aplicarlas en el source o reconstruir. Sin interrupción.
• Replicación detenida: 1062 Duplicate entry / 1032 Can't find record — El thread SQL se ha detenido por un error de datos (Replica_SQL_Running: No, Last_SQL_Errno 1062/1032/1146/1677…). Primero se lleva la fila al estado que tiene en el source; si no es posible, como último recurso se omite una única transacción. Solo se ve afectada esta replica: se queda atrás y las aplicaciones que leen de ella ven datos obsoletos.
• Replica retrasada (SOURCE_DELAY): configurarla o recuperar datos borrados — Quiere mantener una replica deliberadamente N segundos por detrás (configurar / quitar el retraso) o recuperar desde la replica retrasada datos borrados/modificados por error (DROP, DELETE/UPDATE sin WHERE) antes de que se apliquen en ella. El source sigue en servicio.
• Trasladar una replica a otro source (cadena / reconexión) — Quiere colgar una replica de otra replica (cadena / replica intermedia) o volver a conectarla al source; no se copian datos, solo cambia la conexión. La replica trasladada se detiene unos segundos.
• Limpieza y retención de binlogs (el disco se llena) — Los binlogs están llenando el disco o quiere ajustar el periodo de retención; se purgan sin borrar los ficheros que las replicas y la PITR todavía necesitan. Sin interrupción.

Antes de empezar

• MySQL …… (8.0.26 y posteriores)… en la misma versión menor en todos los servidores…, gtid_mode = ON y enforce_gtid_consistency = ON…, binlog activado…; el root del sistema operativo puede conectarse con mysql sin contraseña (auth_socket o ~/.mylogin.cnf). La topología se instaló con la guía de instalación de la replicación o de forma equivalente.
• Se ha verificado que los roles coinciden con los datos introducidos: … (…)… es el source antiguo perdido… es el source actual (read_only = 0, sin configuración de replica)…, los servidores de la lista son replicas.… Promovida a source durante el failover: … (…).…
• Se conoce la contraseña de la cuenta …. La cuenta existe para la IP de cada servidor ('…'@'<ip>', REQUIRE SSL); los pasos la usan para leer valores como el conjunto de GTID en los demás servidores y para la conexión de replicación en un cambio de rol. La contraseña no contiene ', " ni \.
• Los servidores pueden comunicarse entre sí por el puerto ….
• En todos los servidores están instalados y en estado ACTIVE los dos plugins de semi-sync: rpl_semi_sync_source (semisync_source.so) y rpl_semi_sync_replica (semisync_replica.so); en un cambio de rol se activan o desactivan ambos lados en cada servidor. Si están instalados los de nombre antiguo rpl_semi_sync_master / rpl_semi_sync_slave (anteriores a 8.0.26, obsoletos en 8.4), no existen las variables rpl_semi_sync_source_enabled / rpl_semi_sync_replica_enabled que usan los pasos: primero elimine el plugin antiguo con UNINSTALL PLUGIN e instale el nuevo (no pueden cargarse los dos en el mismo servidor; INSTALL PLUGIN se rechaza en un servidor de solo lectura, por lo que super_read_only se desactiva temporalmente).
• En la replica que pasará a ser el nuevo source / servidor intermedio, log_bin = ON y log_replica_updates = ON (valor predeterminado en 8.x); de lo contrario su binlog no contiene las transacciones que llegan del source y las demás replicas no pueden conectarse a ella.
• Existe acceso SSH de root (con clave) entre los servidores implicados para la transferencia de ficheros…: … → ……. Si no, traslade los ficheros con el método aprobado por su organización; los pasos muestran las rutas de los ficheros.
• Percona XtraBackup, de la misma versión mayor que MySQL, está instalado en el donor (…) y en el destino (…); en el donor existe la cuenta de backup bkpuser (auth_socket) — las dos primeras fases de la guía de XtraBackup.
• Están preparados la aprobación del cambio y el canal de comunicación (equipo de aplicación, ventana de mantenimiento). Para un cambio de rol se sabe quién cambia el punto de escritura de la aplicación (VIP, DNS, ProxySQL / HAProxy / Router) y cómo.

Fases de la guía

• Estado: source, replicas y retraso (solo lectura) — Mostrar el rol del source, la posición del binlog y las replicas conectadas · Mostrar el estado de los threads, los errores y el retraso de las replicas · Medir el retraso real y la cola de aplicación en performance_schema · Comprobación de errant GTID (¿tiene la replica transacciones que el source no tiene?) · Interpretar el resultado y elegir el escenario adecuado
• 1. Diagnóstico: ¿está listo para el switchover? — Comprobar el source y las replicas conectadas · Verificar que la replica candidata es adecuada · Comprobar que todas las replicas están sanas
• 2. Red de seguridad — Registrar el estado actual en todos los servidores
• 3. Aplicación: traspasar el rol — Detener las escrituras de la aplicación · Cerrar el source a escrituras y obtener la última posición · Esperar a que las replicas se pongan al día con el source · Promover el candidato a source (promote) · Convertir el source antiguo en replica del nuevo source · Conectar las demás replicas al nuevo source (…) …
• 4. Verificación — Hacer una escritura de prueba en el nuevo source · Comprobar la replicación y la fila de prueba en todos los servidores
• 5. Seguimiento — Borrar la base de datos de prueba y actualizar la operación
• 1. Diagnóstico: ¿se ha perdido realmente el source y qué replica es la más adelantada? — Intentar acceder al source por última vez (desde la replica candidata) · Aislar el source antiguo (fencing) · Esperar en cada replica a que se apliquen las transacciones del relay log · Determinar la replica más adelantada · Determinar la replica más adelantada (por posición)
• 2. Red de seguridad — Registrar el estado actual en las replicas
• 3. Aplicación: failover — Promover el candidato a source (promote) · Conectar las demás replicas al nuevo source (…) · Abrir las escrituras en el nuevo source · Redirigir la aplicación al nuevo source
• 4. Verificación — Hacer una escritura de prueba en el nuevo source · Comprobar la replicación y la fila de prueba en las replicas
• 5. Seguimiento — Planificar las transacciones perdidas, el backup y el source antiguo
• 1. Diagnóstico: ¿está limpio el source antiguo? — Mostrar el estado del source antiguo · Buscar errant transactions (comparar con el nuevo source) · Decisión de reincorporación con replicación por posición
• 2. Red de seguridad — Cerrar de inmediato el source antiguo a escrituras y registrar su estado · Extraer las errant transactions a un fichero aparte
• 3. Aplicación: conectar como replica — Conectar el source antiguo al nuevo source
• 4. Verificación — Verificar que el source antiguo funciona como replica
• 5. Seguimiento — Planificar la topología y el futuro del source antiguo
• 1. Diagnóstico: ¿cuál es el conjunto errant? — Calcular el conjunto de errant GTID
• 2. Red de seguridad: guardar el contenido de las errant transactions — Decodificar las errant transactions del binlog y guardarlas
• 3. Aplicación: inyectar transacciones vacías en el source — Ejecutar los errant GTID como transacciones vacías en el source
• 3. Aplicación: aplicar las errant transactions en el source — Extraer las errant transactions a un fichero y copiarlo al source · Aplicar las transacciones en el source
• 4. Verificación — Verificar que no queda ningún conjunto errant
• 5. Seguimiento: evitar que se repita — Encontrar la causa raíz y proteger las replicas
• 1. Diagnóstico: ¿qué transacción, qué fila? — Mostrar el error y la transacción fallida · Decodificar del relay log las filas de la transacción fallida · Comparar la fila en el source y en la replica
• 2. Red de seguridad — Registrar el estado de la replica y el estado actual de la tabla
• 3. Aplicación: corregir la fila en la replica — Preparar el SQL de corrección · Aplicar la corrección sin escribir en el binlog e iniciar la replicación
• 3. Aplicación: omitir la transacción fallida (último recurso) — Omitir solo la transacción fallida
• 4. Verificación — Comparar la fila y el checksum de la tabla en ambos lados
• 5. Seguimiento — Encontrar la causa raíz
• 1. Diagnóstico — Mostrar la configuración de retraso actual de la replica
• 2. Red de seguridad — Registrar el estado de la replica