Aurora MySQL 8.4.8 の新機能「遅延レプリケーション」で DROP TABLE からの復旧を試してみた
はじめに
2026 年 9 月 3 日、Aurora MySQL 8.4.8 でマルチソースレプリケーションと遅延レプリケーションがサポートされました。遅延レプリケーションでは、ソースで実行された更新のレプリカへの適用を、指定した秒数だけ遅らせられます。
本記事では、遅延レプリケーションの設定方法、遅延の実測、DROP TABLE 後の復旧手順を確認します。
検証内容
初期データを揃えたうえで遅延レプリケーションを開始し、更新の到達状況と、DROP TABLE 後の停止・部分再生を確認しました。
構成
本検証では、Aurora ネイティブのレプリケーションではなく、ソースとレプリカを別のクラスターとして作成し、バイナリログベースのレプリケーションを構成しました。同一クラスター内のリーダーインスタンスは共有ストレージを参照しており、遅延を設定できないためです。両クラスターは同一 VPC・同一セキュリティグループに配置し、ソースとレプリカの両方に binlog_format を ROW に設定したクラスターパラメータグループを適用しました。
| 項目 | 値 |
|---|---|
| エンジンバージョン（ソース / レプリカ） | 8.4.mysql_aurora.8.4.8 |
| インスタンスクラス | db.r8g.large |
| リージョン | ap-northeast-1 |
| binlog_format（ソース） | ROW |
| 設定した遅延秒数 | 300 |
| Database Insights モード | standard |
レプリカクラスターは次のコマンドで作成しました。
aws rds create-db-cluster \
--db-cluster-identifier aurora848-verify-replica \
--engine aurora-mysql \
--engine-version 8.4.mysql_aurora.8.4.8 \
--master-username admin --manage-master-user-password \
--db-subnet-group-name aurora848-verify-subnet-group \
--vpc-security-group-ids sg-xxxxxxxxxxxxxxxxx \
--db-cluster-parameter-group-name aurora848-verify-binlog-row \
--database-insights-mode standard \
--backup-retention-period 1 --no-deletion-protection
aws rds create-db-instance \
--db-instance-identifier aurora848-verify-replica-1 \
--db-cluster-identifier aurora848-verify-replica \
--db-instance-class db.r8g.large --engine aurora-mysql \
--enable-performance-insights --performance-insights-retention-period 7 \
--no-publicly-accessible
作成を開始した 2026-09-05T16:02:39Z から available になった 2026-09-05T16:10:23Z までは 7 分 44 秒でした。
レプリカからソースへ接続できるよう、同一セキュリティグループを送信元とする 3306 番ポートの自己参照インバウンドルールを設定します。
GTID の自動位置指定は使わず、binlog のファイル名と位置を指定しました。
遅延レプリケーションの設定
遅延の設定には、Aurora が提供するストアドプロシージャを利用しました。まずソース側の準備を source-setup.sql として保存し、ソースクラスターのライターへ接続して実行しました。
CALL mysql.rds_set_configuration('binlog retention hours', 24);
CREATE USER 'repl_user'@'%' IDENTIFIED BY '<password>';
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'repl_user'@'%';
FLUSH PRIVILEGES;
CREATE DATABASE demo;
CREATE TABLE demo.orders (
id INT PRIMARY KEY AUTO_INCREMENT,
note VARCHAR(64),
created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);
INSERT INTO demo.orders (note) VALUES ('before-dump-1'), ('before-dump-2');
SHOW BINARY LOG STATUS;
SHOW BINARY LOG STATUS が返した mysql-bin-changelog.000004 の 1705 を、遅延レプリケーション開始時の起点に使いました。Aurora MySQL 8.4 では SHOW MASTER STATUS は使えません。
初期データは、ソースから取ったダンプをレプリカへ取り込んで揃えました。
mysqldump -h <source-cluster-endpoint> -u admin -p \
--single-transaction --databases demo > dump.sql
mysql -h <replica-cluster-endpoint> -u admin -p < dump.sql
今回は、起点位置を取得してからダンプを作成するまで、ソースで更新を行っていないため、先に取得した 1705 をそのまま開始位置に使いました。ダンプ取得時に binlog 位置を出力するオプションは使いませんでした。
遅延レプリケーションの開始は start-delayed-replication.sql として保存し、レプリカクラスターのライターへ接続して実行しました。
CALL mysql.rds_set_external_source_with_delay(
'<source-cluster-endpoint>',
3306,
'repl_user',
'<password>',
'mysql-bin-changelog.000004',
1705,
0,
300
);
CALL mysql.rds_set_binlog_source_ssl('1');
CALL mysql.rds_start_replication;
第 5・第 6 引数が binlog のファイル名と位置です。第 8 引数が遅延秒数で、今回は 300 を指定しました。第 7 引数の ssl_encryption には 0 を指定して初期設定し、その後 mysql.rds_set_binlog_source_ssl('1') でレプリケーション接続の SSL を有効化しました。開始後の SHOW REPLICA STATUS では、Source_SSL_Allowed は Yes でした。
レプリカで SHOW REPLICA STATUS を実行して確認しました。
Replica_IO_State: Waiting for source to send event
Replica_IO_Running: Yes
Replica_SQL_Running: Yes
Seconds_Behind_Source: 269
SQL_Delay: 300
SQL_Remaining_Delay: 32
Replica_SQL_Running_State: Waiting until SOURCE_DELAY seconds after source executed event
Auto_Position: 0
設定した遅延秒数は SQL_Delay に表示され、Replica_SQL_Running_State は遅延待ちであることを示しています。読み方に注意が必要なのは Seconds_Behind_Source です。この値には設定した遅延分が入っています。遅延レプリカでは単独で見ても障害の指標になりません。残りの待ち秒数は SQL_Remaining_Delay で分かります。
遅延の実測
ソースへ 1 行 INSERT した後、レプリカ側で同じ行を約 30 秒間隔でポーリングし、到達を確認できたのは 315 秒後でした。
insert-time: 2026-09-05T16:33:18Z
2026-09-05T16:33:28Z count=0
2026-09-05T16:33:58Z count=0
2026-09-05T16:34:29Z count=0
2026-09-05T16:34:59Z count=0
2026-09-05T16:35:30Z count=0
2026-09-05T16:36:00Z count=0
2026-09-05T16:36:31Z count=0
2026-09-05T16:37:01Z count=0
2026-09-05T16:37:32Z count=0
2026-09-05T16:38:02Z count=0
2026-09-05T16:38:33Z count=1
到達を確認できなかった最後のポーリングは INSERT から 284 秒後の 16:38:02Z、確認できた最初のポーリングは 315 秒後の 16:38:33Z です。このポーリング間隔から言えるのは、284 秒時点では未到達、315 秒時点では到達済みというところまでです。到達時刻そのものは特定していません。設定した遅延秒数どおりの時刻に届くとは限りません。実際の到達時刻は、ソースの更新量とレプリカの適用速度によって前後します。
同じ時間帯について、CloudWatch の AuroraBinlogReplicaLag でも確認しました。期間 60 秒の Maximum です。
| 時刻（UTC） | AuroraBinlogReplicaLag（秒） |
|---|---|
| 16:33 | 0 |
| 16:34 | 41 |
| 16:35 | 101 |
| 16:36 | 161 |
| 16:37 | 221 |
| 16:38 | 281 |
| 16:39 | 0 |
遅延を 300 秒に設定したレプリカで観測した値です。この増加は設定した遅延を含んでおり、障害によるラグではありません。16:39 の 0 は、後述のレプリケーション停止（16:38:56Z）より後に観測された値で、遅延が解消したことを示すものではありません。
DROP TABLE の実行
ソースで DROP TABLE demo.orders; を実行しました。
drop-time: 2026-09-05T16:38:47Z
binlog-before-drop: mysql-bin-changelog.000005:1775
binlog-after-drop: mysql-bin-changelog.000005:1983
DROP のイベントは 1775 から 1983 の区間に記録されています。この 1775 が、後の部分再生で停止位置として指定する値です。今回の検証では DROP TABLE の前後で SHOW BINARY LOG STATUS を実行して停止位置を得ました。実運用では誤操作の前に位置を取得できないため、mysqlbinlog などでイベント位置を探すことになります。
DROP 直後に、ソースとレプリカの状態を並べて確認しました。
=== Source: tables in demo ===
tables: []
=== Replica: tables in demo ===
tables: ['orders']
=== Replica: SELECT COUNT(*) FROM demo.orders ===
count: 4
ソースの demo にはテーブルが残っていませんが、レプリカには orders が 4 行のまま存在しています。
停止と部分再生
レプリケーション用ユーザーの作成・変更は、レプリケーションを開始する前に済ませておきます。開始後にソースで ALTER USER を実行すると、その文が binlog を通ってレプリカ側でも実行され、適用に失敗してレプリケーションが停止しました。
DROP がレプリカへ適用される前に、レプリケーションを止めました。
CALL mysql.rds_stop_replication;
Replica_IO_Running: No
Replica_SQL_Running: No
Source_Log_File: mysql-bin-changelog.000005
Read_Source_Log_Pos: 1983
Exec_Source_Log_Pos: 1775
Seconds_Behind_Source: NULL
SQL_Delay: 300
SQL_Remaining_Delay: NULL
受信済みの位置を示す Read_Source_Log_Pos は DROP を含む 1983 まで進んでいます。一方、適用済みの位置を示す Exec_Source_Log_Pos は 1775 で止まっています。DROP のイベントはレプリカへ届いてはいるものの、まだ実行されていない状態です。停止中は Seconds_Behind_Source と SQL_Remaining_Delay が NULL になります。
適用位置を DROP 直前に固定するため、停止位置を指定してレプリケーションを再開しました。
CALL mysql.rds_start_replication_until('mysql-bin-changelog.000005', 1775);
Replica_IO_Running: Yes
Replica_SQL_Running: No
Exec_Source_Log_Pos: 1775
Until_Condition: Source
Until_Log_File: mysql-bin-changelog.000005
Until_Log_Pos: 1775
同じ時点でレプリカの demo.orders を読み出した結果です。
id note created_at
1 before-dump-1 2026-09-05 16:03:45
2 before-dump-2 2026-09-05 16:03:45
3 delay-probe 2026-09-05 16:21:14
4 delay-probe2 2026-09-05 16:33:19
Tables_in_demo
orders
指定した位置で SQL スレッドが停止し、demo.orders は 4 行すべてが残っていました。レプリケーションを止めた時点で、適用位置はすでに DROP 直前の 1775 でした。今回の呼び出しでは未適用イベントを進めず、適用位置を 1775 に固定した状態で停止しました。
ソースで DROP TABLE を実行した 16:38:47Z から、レプリカでレプリケーションを停止した 16:38:56Z までは 9 秒でした。これは DROP 直後に停止操作を行った場合の値です。停止操作を行うまでの猶予は、SQL_Delay に設定した 300 秒です。
まとめ
Aurora MySQL 8.4.8 でサポートされた遅延レプリケーションが機能することを確認できました。
誤操作からの復旧という点では、Aurora にはバックトラックという選択肢があります。しかし、Blue/Green Deployments などでバイナリログを利用したレプリケーションを行っている環境でバックトラックを実行した場合、レプリケーションが損傷し、再構築が必要となることがあります。
今回サポートされた遅延レプリケーションを利用すれば、バイナリログを利用したレプリケーションを前提とするシステムでも、DDL や複数のトランザクションを伴うメンテナンスの影響がレプリケーション先に及ぶまでの時間を確保できます。ソースとレプリカが同時に使えなくなる事態を避ける手段が増えました。
なお、バイナリログを利用したレプリケーションは、ストレージ層を共有する Aurora ネイティブのレプリケーションとは異なり、バイナリログ処理に伴う負荷が発生します。採用する場合は、enhanced binlog の利用も含めて、検証環境で実際のワークロードを再現する事前評価をおすすめします。
