Recuperar-se de um DROP / DELETE errado com uma réplica atrasada (SOURCE_DELAY + UNTIL)

Comando

-- Setup: the replica applies events one hour behind
STOP REPLICA;
CHANGE REPLICATION SOURCE TO SOURCE_DELAY = 3600;
START REPLICA;

-- During the incident: stop the applier (the receiver keeps fetching binlogs)
STOP REPLICA SQL_THREAD;

-- Find the bad transaction's GTID in the source binlog, apply up to just before it
CHANGE REPLICATION SOURCE TO SOURCE_DELAY = 0;
START REPLICA SQL_THREAD UNTIL SQL_BEFORE_GTIDS = 'af6bc361-c353-11f1-8f12-f69e63ad6c0e:17';
SELECT SERVICE_STATE FROM performance_schema.replication_applier_status_by_coordinator;

O que faz

Faz a réplica aplicar os eventos com um atraso fixo; quando um DROP / DELETE errado atinge a source, você avança a réplica até logo antes dessa transação e recupera dela os dados perdidos.

Quando usar

Como camada de recuperação rápida contra erro humano em bancos grandes, onde restaurar a partir do backup levaria horas.

Atenção

Quando o coordinator estiver OFF, os dados estão no estado imediatamente anterior à operação errada; faça dump da tabela afetada com mysqldump e carregue-a na source. Depois coloque a réplica de volta em modo atrasado; se ela também aplicar a transação errada, os dados se perdem aqui também. Uma réplica atrasada não deve ser candidata a failover (exclua-a no Orchestrator / Router / ProxySQL). Os relay logs se acumulam durante todo o atraso; dimensione o disco de acordo.