Se remettre d'un DROP / DELETE erroné avec une réplique différée (SOURCE_DELAY + UNTIL)

Commande

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

Ce que fait la commande

Fait appliquer les événements par la réplique avec un retard fixe ; lorsqu'un DROP / DELETE erroné touche la source, vous faites avancer la réplique jusqu'à juste avant cette transaction et y récupérez les données perdues.

Quand l'utiliser

Comme couche de récupération rapide contre l'erreur humaine sur les grosses bases où une restauration depuis sauvegarde prendrait des heures.

Attention

Lorsque le coordinator est OFF, les données sont dans l'état juste avant l'opération erronée ; exportez la table concernée avec mysqldump et chargez-la dans la source. Ensuite, remettez la réplique en mode différé ; si elle applique aussi la transaction erronée, les données sont perdues ici aussi. Une réplique différée ne doit pas être candidate au failover (excluez-la dans Orchestrator / Router / ProxySQL). Les relay logs s'accumulent pendant tout le délai ; dimensionnez le disque en conséquence.