使用延迟副本从错误的 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 导出受影响的表并加载到源中。之后将副本重新置于延迟模式；如果它也应用了错误的事务，这里的数据也会丢失。延迟副本不得作为故障转移候选（在 Orchestrator / Router / ProxySQL 中将其排除）。relay log 会在整个延迟期间累积；请相应规划磁盘大小。