Amazon RDS for MySQL / MariaDB では、コンソールか AWS CLI の操作でリードレプリカ（読み取り専用の複製インスタンス）を作れます。ただし、作っただけでは WordPress の負荷は減りません。WordPress のコアは接続先を1つしか持たないため、読み取りをレプリカへ振り分ける仕組みを別に用意する必要があります。この記事では、レプリカの作成手順、作成後に確認すべき項目、レプリケーション遅延の監視、WordPress 側で読み書きを分ける方法とその注意点を順に説明します。
この記事は AWS ドキュメントの内容（2026年10月現在）をもとに説明していますが、RDS の機能や上限値、コンソールの表記は更新されることがあります。作業前にはスナップショットを取り、まずはステージング環境で試してください。
リードレプリカで解決できること・できないこと
リードレプリカは、ソース DB の変更を 非同期 で複製し続ける読み取り専用のインスタンスです。向いているのは次のような場面です。
- 記事一覧や検索など、読み取りクエリが多くソース DB の CPU が高止まりしている
- 集計やエクスポートなどの重いクエリを、本番の書き込みとは別の場所で実行したい
- 別リージョンに複製を置き、災害時の切り替え先の候補にしたい
一方、可用性を高める目的なら Multi-AZ が本来の機能 です。Multi-AZ はスタンバイへの自動フェイルオーバーを提供しますが、リードレプリカは障害時に自動で昇格しません。また、書き込みが多くて詰まっている場合はレプリカでは解決しません。目的に応じて使い分け、必要なら両方を組み合わせます。
なお、Aurora の場合は「Aurora レプリカ」という別の仕組みで、ストレージを共有するため考え方が異なります。この記事は RDS for MySQL / MariaDB を前提にしています。
作成前の準備
自動バックアップが有効になっているか
RDS for MySQL / MariaDB でリードレプリカを作るには、ソース DB の自動バックアップが有効（バックアップ保持期間が 1 日以上）になっている必要があります。保持期間が 0 だとレプリカを作成できません。変更が必要な場合、設定の反映タイミングによっては再起動が伴うことがあるので、メンテナンス時間帯に行うと安心です。
接続数とインスタンスクラスを決める
レプリカのインスタンスクラスはソースと別に選べますが、ソースより極端に小さいと複製の適用が追いつかず、遅延が大きくなります。最初はソースと同等のクラスで作り、CloudWatch のメトリクスを見ながら調整するのが無難です。
手順1：リードレプリカを作成する
コンソールでは、RDS の「データベース」一覧でソース DB を選び、「アクション」メニューからリードレプリカの作成を選びます。識別子、インスタンスクラス、配置する AZ（またはリージョン）、公開アクセスの有無を指定して作成します。
AWS CLI では次のように作成します。
aws rds create-db-instance-read-replica \
--db-instance-identifier wp-db-replica-1 \
--source-db-instance-identifier wp-db \
--db-instance-class db.r6g.large \
--availability-zone ap-northeast-1c \
--no-publicly-accessible作成にはデータ量に応じて時間がかかります。状態とエンドポイントは次のコマンドで確認できます。
aws rds describe-db-instances \
--db-instance-identifier wp-db-replica-1 \
--query 'DBInstances[0].[DBInstanceStatus,Endpoint.Address,ReadReplicaSourceDBInstanceIdentifier]'状態が available になり、エンドポイントのホスト名が表示されれば作成完了です。ソース DB が暗号化されている場合、レプリカも暗号化されます。別リージョンに作る場合は、そのリージョンの KMS キーの指定が必要になります。
手順2：作成後に確認する項目
レプリカは作成直後から使えますが、次の点はソースと同じになっているとは限らないため、一度確認してください。
- セキュリティグループ: WordPress の EC2 からレプリカのポート 3306 に接続できるか。ソースと同じセキュリティグループを付けるのが分かりやすい方法です。
- パラメータグループ: 文字コードやタイムアウトなど、ソースで変更している値がレプリカにも適用されているか。
- 読み取り専用の状態: MySQL 系のレプリカは既定で読み取り専用として動きます。誤ってレプリカに書き込むとソースとの整合が崩れるため、この設定は変えないでください。
- 監視とアラーム: ソースに設定している CloudWatch アラームは、レプリカには自動で付きません。
接続確認は EC2 から行います。
mysql -h wp-db-replica-1.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com -u wp_user -p wordpress \
-e "SELECT COUNT(*) FROM wp_posts WHERE post_status = 'publish';"ソースとレプリカで同じ件数が返れば、複製は正しく動いています。
手順3：レプリケーション遅延を監視する
非同期複製なので、ソースで書き込んだ内容がレプリカに反映されるまでには遅れ（レプリカラグ）が生じます。通常は短時間ですが、大量更新や重いクエリがあると数分以上に広がることもあります。
CloudWatch の ReplicaLag メトリクス（単位は秒）で遅延を確認できます。
aws cloudwatch get-metric-statistics \
--namespace AWS/RDS \
--metric-name ReplicaLag \
--dimensions Name=DBInstanceIdentifier,Value=wp-db-replica-1 \
--start-time 2026-10-18T00:00:00Z \
--end-time 2026-10-18T06:00:00Z \
--period 300 \
--statistics MaximumMySQL に直接つないで確認する場合は、レプリカ上で SHOW REPLICA STATUS\G（古い MySQL では SHOW SLAVE STATUS\G）を実行し、遅延の秒数を表す項目を見ます。運用では ReplicaLag に CloudWatch アラームを設定し、一定秒数を超えたら通知されるようにしておくと、遅延に気づかないまま古いデータを配信する事態を防げます。
手順4：WordPressで読み取りをレプリカへ振り分ける
WordPress は wp-config.php の DB_HOST に書いた1つの接続先しか使いません。読み書きを分けるには、wp-content/db.php に置くドロップイン（$wpdb を置き換える仕組み）を使います。代表的なものに、Automattic が公開している HyperDB と、それを発展させた LudicrousDB があります。どちらも更新頻度が高いプロジェクトではないため、導入前に最新の WordPress と PHP で動作するか、リポジトリの更新状況や未解決の報告を確認してください。
HyperDB の場合は、db-config.php に接続先を登録します。次は書き込みをソース、読み取りをレプリカ優先にする例です。
// db-config.php（HyperDB）。ソース DB：書き込み担当、読み取りは予備
$wpdb->add_database( array(
'host' => DB_HOST,
'user' => DB_USER,
'password' => DB_PASSWORD,
'name' => DB_NAME,
'write' => 1,
'read' => 2,
) );
// リードレプリカ：読み取り担当（read の数値が小さいほど優先される）
$wpdb->add_database( array(
'host' => 'wp-db-replica-1.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com',
'user' => DB_USER,
'password' => DB_PASSWORD,
'name' => DB_NAME,
'write' => 0,
'read' => 1,
) );設定項目の意味や既定値は、配布物に含まれるサンプルの db-config.php のコメントで確認してください。パスワードは wp-config.php の定数を参照し、設定ファイルに直接書き写さないようにします。
遅延で起きる不具合に備える
読み書きを分けると、「記事を保存した直後に画面を開くと古い内容が出る」「設定を変えたのに反映されない」といった、遅延が原因の症状が出ることがあります。HyperDB は同じリクエスト内で書き込みがあった後の読み取りをソースへ送る仕組みを持っていますが、別のリクエストにまたがる遅延までは防げません。
そのため、まずは管理画面や WP-Cron ではソース DB だけを使い、読み取りが多い公開ページだけをレプリカへ振り分ける、という段階的な導入が安全です。db-config.php が読み込まれる時点では、管理画面（admin-ajax.php を含む）なら WP_ADMIN、WP-Cron なら DOING_CRON の定数がすでに定義されているので、これを条件にレプリカの登録を省けます。先ほどの例のレプリカ登録部分を、次の形に置き換えます。
// 管理画面と WP-Cron ではレプリカを登録しない（ソース DB だけで読み書きする）
if ( ! defined( 'WP_ADMIN' ) && ! defined( 'DOING_CRON' ) ) {
$wpdb->add_database( array(
'host' => 'wp-db-replica-1.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com',
'user' => DB_USER,
'password' => DB_PASSWORD,
'name' => DB_NAME,
'write' => 0,
'read' => 1,
) );
}REST API のリクエストかどうかはこの段階ではまだ判定できないため、ブロックエディターの保存直後などに遅延の影響が出ないか、ステージングで確かめておいてください。ドロップインを外せば元の単一接続に戻るので、問題が出たときは wp-content/db.php をリネームして切り戻します。
レプリカを昇格・削除するとき
レプリカは「昇格」させると独立した通常の DB インスタンスになります。昇格は元に戻せず、ソースとの複製はその時点で止まります。ソース障害時の切り替えに使う場合は、昇格後に DB_HOST を書き換える手順をあらかじめ文書にしておきましょう。不要になったレプリカを削除しても、ソース DB には影響しません。
まとめ
- リードレプリカは読み取り負荷の分散用。可用性が目的なら Multi-AZ を検討する。
- 作成にはソースの自動バックアップが有効になっている必要がある。
- 作成後はセキュリティグループ・パラメータグループ・アラームを確認する。
ReplicaLagを監視し、遅延が広がったら通知されるようにする。- WordPress で使うには HyperDB などのドロップインが必要。管理画面や書き込みはソースに残し、公開ページの読み取りから段階的に振り分ける。