Reparar una réplica rota: conflictos de filas 1062 / 1032

Comando

-- 1) Failing worker, error and GTID
SELECT WORKER_ID, LAST_ERROR_NUMBER, LEFT(LAST_ERROR_MESSAGE, 250) AS last_error, APPLYING_TRANSACTION
FROM performance_schema.replication_applier_status_by_worker
WHERE LAST_ERROR_NUMBER <> 0;

-- 2) Shell: decode the row images of that transaction from the relay log
mysqlbinlog --base64-output=DECODE-ROWS -vv --include-gtids='af6bc361-c353-11f1-8f12-f69e63ad6c0e:11' /var/lib/mysql/db2-relay-bin.0* | grep '^###'

-- 3a) 1062 Duplicate entry: delete the extra row on the replica without binlogging
SET SESSION sql_log_bin = 0;
DELETE FROM shop.orders WHERE id = 20001;
-- 3b) 1032 Can't find record: insert the missing row from the WHERE (before image) values
INSERT INTO shop.orders (id, cust, amount, note, created) VALUES (6, 6, 9.00, 'n6', '2026-10-08 20:09:44');
SET SESSION sql_log_bin = 1;

-- 4) Start the applier and verify
START REPLICA SQL_THREAD;
SELECT SERVICE_STATE, LAST_ERROR_NUMBER FROM performance_schema.replication_applier_status_by_coordinator;

Qué hace

Corrige las dos roturas más comunes de la replicación basada en filas (1062 clave duplicada, 1032 fila no encontrada) sin omitir la transacción, llevando la fila de la réplica al estado que espera el origen; se preserva la consistencia de los datos.

Cuándo usarlo

Cuando Replica_SQL_Running = No con el error 1062 / 1032; como reparación correcta en lugar de omitir el GTID con una transacción vacía.

Precaución

La corrección en la réplica debe ejecutarse con sql_log_bin=0; de lo contrario crea un GTID errant que da problemas en el failover. Si super_read_only=ON, desactívelo temporalmente y vuelva a activarlo después. Los valores de la before-image suponen binlog_row_image=FULL; con MINIMAL solo se registra la PK y el resto de la fila debe leerse del origen. Un conflicto en una tabla suele significar que hay más; tras la reparación compare la tabla con el origen usando pt-table-checksum. Ruta del relay log: SELECT @@relay_log_basename;