遅延レプリカで誤った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がソースで実行された場合、そのトランザクションの直前までレプリカを進め、失われたデータをそこから回復する。

使用する場面

バックアップからのリストアに数時間かかる大規模データベースで、人為的ミスに対する迅速な復旧層として。

注意

コーディネータがOFFのとき、データは誤った操作の直前の状態にある。影響を受けた表をmysqldumpでダンプし、ソースにロードする。その後、レプリカを遅延モードに戻す。レプリカも誤ったトランザクションを適用すると、ここでもデータは失われる。遅延レプリカはフェイルオーバー候補にしてはならない(Orchestrator / Router / ProxySQLで除外する)。リレーログは遅延期間全体にわたって蓄積するため、それに応じてディスクをサイジングする。