Восстановиться после ошибочного DROP / DELETE с помощью отложенной реплики (SOURCE_DELAY + UNTIL)

Команда

-- 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;

Что делает

Заставляет реплику применять события с фиксированной задержкой; когда на источник приходит ошибочный DROP / DELETE, реплика прокручивается вперёд до момента непосредственно перед этой транзакцией, и потерянные данные восстанавливаются из неё.

Когда использовать

Как слой быстрого восстановления от человеческих ошибок на больших базах, где восстановление из бэкапа заняло бы часы.

Внимание

Когда coordinator в состоянии OFF, данные находятся в состоянии непосредственно перед ошибочной операцией; выгрузите затронутую таблицу через mysqldump и загрузите её в источник. Затем верните реплику в отложенный режим; если она применит и ошибочную транзакцию, данные будут утеряны и здесь. Отложенная реплика не должна быть кандидатом на failover (исключите её в Orchestrator / Router / ProxySQL). Relay log накапливаются за всё время задержки; рассчитайте размер диска соответственно.