Nach einem fehlerhaften DROP / DELETE mit einer verzögerten Replica wiederherstellen (SOURCE_DELAY + UNTIL)

Befehl

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

Was es tut

Lässt die Replica Events mit festem zeitlichem Abstand anwenden; trifft ein fehlerhaftes DROP / DELETE die Quelle, rollst du die Replica bis kurz vor diese Transaktion vor und holst die verlorenen Daten von dort zurück.

Wann einsetzen

Als schnelle Wiederherstellungsebene gegen menschliche Fehler bei großen Datenbanken, bei denen ein Restore aus dem Backup Stunden dauern würde.

Vorsicht

Ist der Coordinator OFF, sind die Daten im Zustand unmittelbar vor der fehlerhaften Operation; die betroffene Tabelle mit mysqldump sichern und in die Quelle laden. Danach die Replica wieder in den verzögerten Modus versetzen; wendet sie die fehlerhafte Transaktion ebenfalls an, sind die Daten auch hier weg. Eine verzögerte Replica darf kein Failover-Kandidat sein (in Orchestrator / Router / ProxySQL ausschließen). Relay Logs sammeln sich über die gesamte Verzögerung an; Platte entsprechend dimensionieren.