RDS for MySQL / MariaDB のリードレプリカは、別リージョンにも作成できます。別リージョンのレプリカを用意しておけば、東京リージョン全体に障害が起きたときでも、レプリカを「昇格」させて独立した DB として使い、WordPress を動かし続ける道ができます。この記事では、読み取り分散ではなく 災害対策（DR） を目的に、クロスリージョンのリードレプリカを CLI で作る手順、切り替え（昇格）の手順書の作り方、事前の切り替え訓練、切り替え後に元へ戻す方法までを説明します。
RDS の機能や対応エンジン、コンソールの表記は更新されることがあります。ここでは AWS の公開ドキュメント（2026年10月現在）に沿って説明しますが、作業前に公式ドキュメントで確認し、スナップショットを取ってから進めてください。コマンドは例なので、識別子やリージョンは自分の環境に合わせて書き換えます。
Multi-AZとクロスリージョンレプリカの違い
最初に、何に備えるのかをはっきりさせておきます。
- Multi-AZ：同じリージョン内の別のアベイラビリティーゾーン（AZ）にスタンバイを置き、障害時は自動でフェイルオーバーします。AZ 単位の障害やハードウェア故障への備えです。
- クロスリージョンのリードレプリカ：別リージョンに非同期で複製を置きます。障害時に自動では切り替わらず、人（または自分で組んだ仕組み）が昇格の操作をします。リージョン単位の障害への備えです。
両者は代わりにはならないので、本番 DB は Multi-AZ にしたうえで、さらにリージョン障害に備えたい場合にクロスリージョンレプリカを足す、という組み合わせが一般的です。
あわせて、2つの数字を決めておくと設計がぶれません。どこまでのデータ消失を許すか（RPO） と、何分で復旧したいか（RTO） です。非同期複製なので、障害の瞬間のレプリケーション遅延の分だけ、最新の書き込みが失われる可能性があります。数時間の停止とその日の更新の消失を許容できるなら、別リージョンへの自動バックアップの複製やスナップショットのコピーで足りる場合もあります。Aurora を使っている場合は、Aurora Global Database という別の仕組みも選択肢になります。どれが合うかは、費用（データ転送量を含む）と求める復旧時間で比べてください。
作成前に別リージョンで用意するもの
レプリカを作る前に、複製先のリージョンで次のものを準備します。ここが抜けていると作成コマンドが失敗するか、作れても切り替え時に使えません。
- ソース DB の自動バックアップ：保持期間が1日以上になっている必要があります。0 だとレプリカを作成できません。
- VPC と DB サブネットグループ：複製先リージョンに VPC を作り、複数の AZ のプライベートサブネットで DB サブネットグループを作っておきます。
- セキュリティグループ：複製先で WordPress を動かすサーバーから 3306 番ポートに接続できるものを用意します。
- KMS キー：ソースが暗号化されている場合、複製先リージョンの KMS キーを指定する必要があります。
- パラメータグループ：ソースで文字コードやタイムアウトなどを変えているなら、同じ内容のものを複製先にも作ります。指定しないと既定のものが使われます。
手順1：クロスリージョンのリードレプリカを作る
コマンドは 複製先のリージョン に向けて実行し、ソースは ARN で指定します。次は東京（ap-northeast-1）の wp-db を大阪（ap-northeast-3）に複製する例です。
aws rds create-db-instance-read-replica \
--region ap-northeast-3 \
--source-region ap-northeast-1 \
--db-instance-identifier wp-db-dr \
--source-db-instance-identifier arn:aws:rds:ap-northeast-1:123456789012:db:wp-db \
--db-instance-class db.r6g.large \
--db-subnet-group-name wp-dr-db-subnets \
--vpc-security-group-ids sg-0123456789abcdef0 \
--db-parameter-group-name wp-mysql-params \
--kms-key-id arn:aws:kms:ap-northeast-3:123456789012:key/your-kms-key-id \
--no-publicly-accessible
aws rds wait db-instance-available --region ap-northeast-3 --db-instance-identifier wp-db-dr初回はソースのデータを丸ごと転送するため、データ量によっては時間がかかります。インスタンスクラスはソースと同じにしておくのが無難です。切り替え後はこのインスタンスが本番になるので、小さすぎると昇格した直後から性能が足りなくなります。
作成できたら、複製先リージョンの CloudWatch で ReplicaLag（秒）を確認し、アラームを設定します。リージョンをまたぐ分、同じリージョン内のレプリカより遅延は大きくなりがちです。この値がそのまま「今障害が起きたら失うかもしれない時間」の目安になるので、RPO を超えたら通知されるようにしておきます。
手順2：WordPress側の切り替え先を用意する
DB だけを複製しても、WordPress は動きません。複製先リージョンで次のものがそろっているかを確認します。
- Web サーバー：AMI を複製先リージョンにコピーしておくか、起動テンプレートと構成管理でサーバーを作り直せるようにしておきます。
- メディアファイル：
wp-content/uploadsがサーバーのディスク上にあるなら、そのバックアップも複製先に必要です。S3 に置いているなら、S3 のクロスリージョンレプリケーションを検討します。 - 設定と秘密情報：
wp-config.phpの認証用キーや DB の接続情報を、複製先で取り出せる場所に保管します。 - DNS：サイトのドメインを複製先のロードバランサーなどへ向け直す手順と、そのときの TTL を確認しておきます。
DB_HOST の切り替えを楽にするには、Route 53 のプライベートホストゾーンに db.internal.example.com のような名前を作り、RDS のエンドポイントを CNAME で指しておく方法があります。WordPress 側は常にこの名前で接続し、切り替え時は DNS レコードを書き換えるだけで済みます。
注意したいのは、複製先の WordPress を 昇格前から動かさない ことです。レプリカは読み取り専用なので、WordPress を接続すると WP-Cron や管理画面からの書き込みが失敗し、エラーが出続けます。複製先のサーバーは停止しておくか、台数を0にしておきます。
手順3：切り替え（昇格）の手順
計画的に切り替える場合
メンテナンスやリージョン移行のように、ソースがまだ動いている状態で切り替えるなら、書き込みを止めてから昇格すればデータを失わずに済みます。
- WordPress のドキュメントルートに
.maintenanceファイルを置き、書き込みを止めます。中身を<?php $upgrading = time(); ?>にすると、ファイルを消すまで訪問者にはメンテナンス表示（503）が返ります。 - 書き込みを止めたあと、ソース DB に mysql クライアントで接続し、目印の値を書き込みます。レプリカ側で同じ値が読めれば、そこまでの書き込みはすべて複製済みと判断できます。テーブル接頭辞が
wp_以外なら読み替えてください。
-- ソース DB で実行（目印を書く）
INSERT INTO wp_options (option_name, option_value, autoload)
VALUES ('dr_switch_marker', UNIX_TIMESTAMP(), 'no')
ON DUPLICATE KEY UPDATE option_value = VALUES(option_value);
SELECT option_value FROM wp_options WHERE option_name = 'dr_switch_marker';
-- レプリカ（wp-db-dr）で実行し、同じ値が返るまで待つ
SELECT option_value FROM wp_options WHERE option_name = 'dr_switch_marker';- レプリカを昇格させます。
aws rds promote-read-replica \
--region ap-northeast-3 \
--db-instance-identifier wp-db-dr \
--backup-retention-period 7
aws rds wait db-instance-available --region ap-northeast-3 --db-instance-identifier wp-db-dr
# 昇格後は Multi-AZ と削除保護を有効にしておく
aws rds modify-db-instance \
--region ap-northeast-3 \
--db-instance-identifier wp-db-dr \
--multi-az \
--deletion-protection \
--apply-immediately- 複製先の Web サーバーを起動し、
DB_HOST（または先ほどの内部 DNS 名）を昇格したインスタンスのエンドポイントに向けます。エンドポイントのホスト名は昇格の前後で変わりません。 - 複製先で表示と管理画面へのログイン、投稿の保存を確認してから、サイトのドメインの DNS を切り替え、
.maintenanceを外します。
障害で切り替える場合
ソースのリージョンに障害が起きているときは、目印の確認はできません。障害直前の ReplicaLag の分だけデータが失われる可能性を受け入れたうえで、手順3以降を進めます。切り替えた時刻と、その時点の遅延の値を記録しておくと、あとで失われた可能性のある更新を確認するときに役立ちます。
昇格は元に戻せません。昇格した時点でソースとの複製は止まり、以後は別々の DB になります。
事前に切り替えを訓練する
手順書は、一度も試していないと本番で詰まります。本番に影響を出さずに訓練するには、ソースから 訓練用のレプリカを別に作り、そちらを昇格させます。
- 手順1と同じ要領で、
wp-db-drillのような識別子のレプリカを作成します。 - 昇格させ、ステージング用のサーバーから
DB_HOSTをそのエンドポイントに向けて WordPress を起動します。 - 表示・ログイン・保存・WP-Cron が動くか、作業にかかった時間はどれくらいかを記録します。
- 確認が済んだら訓練用のインスタンスを削除します。
本番の DR 用レプリカには手を触れないので、訓練中も本来の備えは残ったままです。かかった時間が RTO に収まるか、手順書に抜けがないかをこの場で洗い出し、手順書を直します。
切り替え後に元のリージョンへ戻す
障害が収まって元のソース DB が復旧しても、切り替え後の書き込みは入っていません。古いソースに WordPress を向け直すと、切り替え後の投稿や注文が消えたように見えるので、そのまま戻してはいけません。
戻すときは、昇格したインスタンスをソースにして、元のリージョンに新しいリードレプリカを作ります。複製が追いついたら、手順3の「計画的に切り替える場合」と同じ流れで書き込みを止め、元のリージョン側を昇格させて戻します。古いソースは、念のためスナップショットを取ってから削除します。
まとめ
- クロスリージョンのリードレプリカはリージョン障害への備え。AZ 障害は Multi-AZ で備え、両方を組み合わせる。
- 作成前に、複製先リージョンの DB サブネットグループ・セキュリティグループ・KMS キー・パラメータグループを用意する。
ReplicaLagが失うかもしれないデータの目安になる。RPO に合わせてアラームを設定する。- DB だけでなく、Web サーバー・メディア・設定・DNS の切り替え先もそろえる。複製先の WordPress は昇格前に動かさない。
- 計画的な切り替えは書き込みを止め、目印の値で複製を確かめてから昇格する。昇格は元に戻せない。
- 訓練用レプリカで定期的に切り替えを試し、戻すときは新しいレプリカを作って同じ手順で切り替える。