DB の切り替え
エンドユーザーに対する メンテナンス時間開始 の通知
Auroraでデータが確認できました。 次は、WordPressアプリケーションからみて、利用するDBインスタンスを変更します。
- もちろん、実際の運用時を考えると、この作業中はDBへの書き込みは行うことは(業務的に)できません。
- RDS for MySQL との接続性を切断するため、書き込んだデータが失われる可能性があるためです。
- 現実に近いケースを考えた場合はエンドユーザー/利用者との調整を行い、書き込みが無くなったタイミングで、メンテナンス時間に入っていることが分かるようにすることでしょう。
それを踏まえて、ここでは 簡易的な「メンテナンス中」であることを伝える手段として、 WordPress を実行する Webサーバーの前段の ALBで、メンテナンス中であることを伝えるようにしてみます。
EC2のコンソールから、「ロードバランサー」を選び、作成したALB（elb-user1など）を選択します。
「ルールの表示/編集」をクリックします。
- 「＋」のようなアイコンをクリックします。
- 続けて画面中央の「ルールの挿入」というリンクをクリックし、新規の「ルール」に対して次の条件で設定します。
- IF: 「パス」を
*に設定 - THEN: 「固定レスポンスを返す」で「レスポンス本文」に
under maintenanceなど好きなメッセージを入力
- IF: 「パス」を
ルールを保存し、数秒すると、WordPressのサイトにWebブラウザからアクセスしても、設定した メッセージ文字列 が返ってくる状態になります。
- これでユーザーのアクセスも無くなり、書き込みが無い状態となりました。(もちろん、ユーザーが書き込めないことが分かっている場合はこのような作業は不要でしょう)
Aurora MySQL の 昇格
では、RDS for MySQL から Aurora MySQL へのレプリケーションを切断し、Aurora クラスターを単独で利用するための準備を行います。
- Auroraのクラスターを選択し、「アクション」から「昇格」をクリックします
- 確認ダイアログで、「リードレプリカの昇格」をクリックします
昇格は 数分(1-2分程度) を要します。
完了したかどうかを確認するには、左のメニューから「イベント」を選択し、次のイベントが出力されているかを確認します。 (定期的に リロードボタンをクリックして表示を更新し、確認して下さい)
- ソース:
aurora-user1-clusterなどの名前 - タイプ:
クラスター - メッセージ:
Promoted Read Replica cluster to a stand-alone database cluster.
これで RDS for MySQL とのレプリケーションは切断され、独立した Auroraクラスター として動作するようになりました！
WordPressアプリケーション への DB接続先設定の変更
念の為、Auroraの書き込みエンドポイントに接続できるか確認してみましょう。
手順は先ほどと同様です。(省略しますが、ここで行って下さい)
この状態では、WordPressはまだ接続先とすべきDBが変わったことを知りません。
現在の設定では各インスタンスに接続情報を持っているため、これを1つづつ変更します。
本番環境では通常避けるべきことですが、DBの接続情報などをハードコードしていると変更耐性が極めて低く、障害発生時に特に対応が困難となります。 ワークロードによりますが、様々な場面を考慮し、より変更に強い構成を採用しましょう。
- 2つの WordPress 用 EC2インスタンス (webserver#1-user1, webserver#2-user1) それぞれに 同様の手順で Session Manager で 接続し、vi エディタで
/var/www/html/wp-config.phpファイルのDB_HOST変数の値 をAuroraクラスターの書き込みエンドポイントに変更して保存します。
sh-4.2$ vi /var/www/html/wp-config.php
<?php
/**
* WordPress の基本設定
*
* このファイルは、インストール時に wp-config.php 作成ウィザードが利用します。
* ウィザードを介さずにこのファイルを "wp-config.php" という名前でコピーして
* 直接編集して値を入力してもかまいません。
*
* このファイルは、以下の設定を含みます。
*
* * MySQL 設定
* * 秘密鍵
* * データベーステーブル接頭辞
* * ABSPATH
*
* @link https://ja.wordpress.org/support/article/editing-wp-config-php/
*
* @package WordPress
*/
// 注意:
// Windows の "メモ帳" でこのファイルを編集しないでください !
// 問題なく使えるテキストエディタ
// (http://wpdocs.osdn.jp/%E7%94%A8%E8%AA%9E%E9%9B%86#.E3.83.86.E3.82.AD.E3.82.B9.E3.83.88.E3.82.A8.E3.83.87.E3.82.A3.E3.82.BF 参照)
// を使用し、必ず UTF-8 の BOM なし (UTF-8N) で保存してください。
// ** MySQL 設定 - この情報はホスティング先から入手してください。 ** //
/** WordPress のためのデータベース名 */
define( 'DB_NAME', 'wordpress' );
/** MySQL データベースのユーザー名 */
define( 'DB_USER', 'admin' );
/** MySQL データベースのパスワード */
define( 'DB_PASSWORD', 'wordpress' );
/** MySQL のホスト名 */
define( 'DB_HOST', 'aurora-user1-cluster.cluster-cxswvm02cbrf.ap-northeast-1.rds.amazonaws.com' ); ← このホスト名をAurora書き込みエンドポイントに変更
/** データベースのテーブルを作成する際のデータベースの文字セット */
define( 'DB_CHARSET', 'utf8mb4' );
/** データベースの照合順序 (ほとんどの場合変更する必要はありません) */
define( 'DB_COLLATE', '' );- WordPressアプリケーションへの反映は再起動が不要なため、これで完了です。
メンテナンス時間 の終了
先ほど行った、メンテナンス用ルールを削除します。
- ルール追加時にクリックした「+」のアイコンがあるメニューバーの右にある「-」のアイコンをクリックし、先ほど追加したルールを選択状態にして「削除」をクリックします。
本来はこの前に、社内のみ確認できるような経路を作り、問題がないことを検証すべきですが、今回は割愛します。
数秒後に今までと同じページが表示されていれば成功です！
旧DBの停止
- とはいえ、見た目には何も変わりません。
- 旧DBである RDS for MySQL の DBインスタンス を 停止 してからWordPressにアクセス・操作し、「継続して利用できること」を確認することで、実際にWordPressが利用しているDBが切り替わっていることを検証してみましょう。
もちろん、本番環境ではあれば、切り替えられているかどうかは 各種ログ や 各種メトリクスなども併せて複合的に確認を行うべきです。
- RDSの「データベース」から、RDS for MySQL データベースインスタンスを選択し、「アクション」「停止」をクリックします。
- 「はい、今すぐ停止します」をクリックすると、ステータスが「停止中」となります。
停止するまでは2,3分ほどかかります。「停止済み」状態になったことを確認したら、EC2インスタンス から mysqlコマンド で接続を試行したり、WordPressのページにアクセスしたりして状況を確認してみましょう。
これで Aurora MySQLクラスター への DB移行 が完了したことになります。
次のセクションへ進んで下さい。