2026年7月27日

WordPressのDBをAmazon Aurora MySQLへ移行する手順とスケーラビリティの考え方

データベース・バックアップ

WordPress の DB を Amazon Aurora MySQL に移すと、ストレージの自動拡張や読み取りレプリカの追加がしやすくなり、DB 側の伸びしろを確保できます。ただし、移行しただけで WordPress が速くなるわけではなく、読み取りを分散するには WordPress 側にも仕組みが必要です。この記事では、移行が効く場面の見極め、移行方式の選び方、停止時間を抑えた切り替え手順、移行後に読み取りを分散する方法を順に説明します。

Aurora に移行すると何が変わるのか

Aurora MySQL は、MySQL 互換のエンジンと、複数のアベイラビリティーゾーンにまたがる共有ストレージを組み合わせた AWS のマネージド DB です。WordPress から見ると通常の MySQL と同じように扱え、wp-config.php の DB_HOST を変えるだけで接続できます。

WordPress の運用で効いてくるのは主に次の点です。

ストレージが自動で拡張される: 容量の事前見積もりや拡張作業の手間が減ります。
読み取りレプリカを追加しやすい: レプリカは書き込み側とストレージを共有するため、追加が比較的速く、複製の遅延も一般に小さく抑えられます。
フェイルオーバーが速い: 書き込み側に障害が起きたとき、レプリカが昇格して処理を引き継ぎます。
Aurora Serverless v2: 負荷に応じて DB の処理能力を自動で増減させる構成も選べます。

一方で、書き込みは1台の書き込みインスタンス（ライター）が担います。書き込みの性能を上げるには、インスタンスのサイズを上げる垂直方向の拡張が基本です。

移行の前に確かめること

多くの WordPress サイトで、遅さの原因は DB ではなく PHP の処理やキャッシュ不足にあります。移行を決める前に、次の点を確認してください。

遅い時間帯に DB の CPU やディスク I/O が高くなっているか
スロークエリログに、繰り返し出てくる遅いクエリがあるか
ページキャッシュとオブジェクトキャッシュを使っているか

DB の負荷が高い原因が特定のクエリなら、インデックスやクエリの改善のほうが先に効きます。Aurora は、その対策をしても DB の負荷が伸び続けるサイトや、可用性を上げたいサイトに向いた選択肢です。

バージョンと互換性を確認する

Aurora MySQL にはメジャーバージョンがあり、執筆時点では MySQL 8.0 互換のバージョン 3 が主流です。MySQL 5.7 互換の旧バージョンは標準サポートの終了が進んでいるため、新規に移行するなら MySQL 8.0 互換を選ぶのが自然です（2026年10月現在。サポート期間や対応バージョンは AWS の公式ドキュメントで確認してください）。

移行元が MySQL 5.7 や MariaDB の場合、次の点で差が出ることがあります。

照合順序: MySQL 8.0 の既定は utf8mb4_0900_ai_ci です。MariaDB 固有の照合順序はそのまま持ち込めないことがあるため、ダンプ内の照合順序の指定を確認します。
sql_mode: MySQL 8.0 の既定は厳しめです。WordPress コアは自分で調整しますが、独自 SQL を書いているプラグインは影響を受けることがあります。
予約語: MySQL 8.0 で増えた予約語を、プラグインの独自テーブルが列名に使っていると SQL エラーになります。

ステージングとして Aurora のクラスターを作り、サイトのコピーを載せて主要な機能を試すのが最も確かな確認方法です。

移行方式を選ぶ

データ量と、許容できる停止時間で方式を選びます。

ダンプとインポート: mysqldump（WP-CLI の wp db export）で出力し、Aurora に読み込みます。手順が単純で、数 GB 程度までのサイトに向いています。ダンプから切り替えまでの間は書き込みを止める必要があります。
RDS for MySQL からの移行: 移行元が RDS for MySQL なら、スナップショットから Aurora クラスターを作る方法や、Aurora のリードレプリカを作って昇格させる方法が用意されています。
バイナリログによるレプリケーション: 自前の MySQL サーバーから移す場合、まずダンプで初期データを入れ、その後 Aurora を移行元のレプリカとして追従させます。切り替え時の停止時間を短くできます。
AWS DMS: 異なる環境間の継続的な移行に使えますが、設定項目が多く、WordPress 程度の規模ではダンプかレプリケーションで足りることが多いです。

停止時間を抑えた切り替え手順

ここでは、自前の MySQL からバイナリログのレプリケーションで移す場合を例にします。どの方式でも、開始前に移行元 DB と wp-config.php のバックアップを取ってください。

1. 初期データを入れる

移行元でバイナリログを有効にし、整合性のとれたダンプを取ります。--single-transaction を付けると、InnoDB のテーブルをロックせずに一貫した時点のデータを出力できます。

# 移行元のサーバーで実行（WP-CLI は追加の引数を mysqldump に渡す）
wp db export wp-initial.sql --single-transaction --quick

# Aurora のクラスターエンドポイントへ読み込む
mysql -h wp-cluster.cluster-abcdefghijkl.ap-northeast-1.rds.amazonaws.com \
  -u admin -p wordpress < wp-initial.sql

レプリケーションを組む場合は、ダンプを取った時点のバイナリログの位置を記録しておく必要があります。mysqldump のオプション（--source-data または古い版の --master-data）で出力に含められます。

2. レプリケーションで追従させる

Aurora 側では、AWS が用意したストアドプロシージャで移行元をレプリケーション元として設定します。プロシージャ名はバージョンによって異なり（mysql.rds_set_external_source や旧名の mysql.rds_set_external_master など）、引数も変わることがあるため、利用するバージョンのドキュメントで確認してください。移行元には、Aurora からの接続を許可したレプリケーション用ユーザーを作ります。

追従が始まったら、遅延がゼロ付近で安定するまで待ちます。

3. 書き込みを止めて切り替える

アクセスの少ない時間帯を選び、次の順で進めます。

メンテナンスモードにして書き込みを止める（wp maintenance-mode activate）
Aurora 側でレプリケーションの遅延がゼロであることを確かめる
主要テーブルの行数を移行元と比べる
Aurora 側のレプリケーションを停止する
wp-config.php の DB_HOST をクラスターエンドポイント（書き込み用）に変更する
メンテナンスモードを解除し、ログイン、投稿の保存、画像のアップロードなどを試す

define( 'DB_HOST', 'wp-cluster.cluster-abcdefghijkl.ap-northeast-1.rds.amazonaws.com' );

DB_HOST には、インスタンス個別のエンドポイントではなくクラスターエンドポイントを指定します。フェイルオーバーでライターが入れ替わっても、クラスターエンドポイントは新しいライターを指すからです。

4. 戻し方を決めておく

切り替え後に問題が見つかった場合、移行元の DB に戻せば復旧できます。ただし、切り替え後に Aurora に書き込まれたデータは移行元にありません。戻す判断の期限（例: 切り替え後1時間以内）と、その間に発生した注文やコメントの扱いを事前に決めておきます。

移行後に読み取りを分散する

Aurora にはレプリカ用の読み取りエンドポイントがありますが、WordPress コアは1つの DB_HOST にしか接続しません。レプリカを追加しただけでは、WordPress からの読み取りは分散されません。

読み取りをレプリカへ振り分けるには、wpdb を置き換えるドロップイン（wp-content/db.php）を使います。代表的なものは次の2つです。

HyperDB: Automattic が公開している、複数 DB への振り分けを行うドロップインです。
LudicrousDB: HyperDB を元に拡張されたドロップインで、GitHub で公開されています。

どちらも、更新の頻度や新しい PHP・WordPress への対応状況はその時々で異なります。導入前にリポジトリの最近の更新や Issue を確認し、ステージングで十分に試してください。

読み取りの分散で注意したいのが、レプリカの遅延です。Aurora のレプリカの遅延は小さいものの、ゼロではありません。投稿を保存した直後にレプリカから読むと、古い内容が表示されることがあります。HyperDB 系のドロップインには、書き込みを行ったリクエストではその後の読み取りもライターに送る仕組みがありますが、設定によって挙動が変わるため、管理画面での保存と表示の流れを重点的に確認します。

なお、読み取り負荷の多くはページキャッシュとオブジェクトキャッシュで減らせます。レプリカの追加は、キャッシュを入れても DB の読み取り負荷が残る場合の次の手段と考えると、構成を複雑にしすぎずに済みます。

まとめ

Aurora MySQL はストレージの自動拡張、レプリカの追加、速いフェイルオーバーで DB の伸びしろを広げるが、書き込みはライター1台が担う
移行の前に、遅さの原因が DB にあるかをスロークエリや負荷の指標で確かめる
MySQL 8.0 互換を選び、照合順序・sql_mode・予約語の差をステージングで確認する
停止時間を短くするには、ダンプで初期データを入れてからレプリケーションで追従させ、メンテナンスモード中に DB_HOST を切り替える
読み取りの分散には HyperDB や LudicrousDB などのドロップインが必要で、レプリカの遅延とキャッシュとの役割分担を考えて導入する