この記事では、フェイルオーバー型のDBの冗長化まで書けていないので、今回の記事でその部分について少し書く。 この記事に書いてあることはすべて設定済みとして話を進める。
こちらの記事では、wordpressでDBをAmazon RDSにするという話が既に書かれているのでメインのDBの構築についてはこの記事に譲ることにする。
同一リージョンにおける冗長化構成についてはマルチAZという機能を使える。というか、AWSとしては「冗長化したいならMultiAZがおすすめ」らしいのだが、今回リージョンをまたいだ冗長化構成をしたかったので、リードレプリカを用いた方法について書く。リードレプリカの作り方などはこちらの記事にあるのでそちらを参照していただきたい。
まだ記事になっていないリードレプリカの昇格方法について説明する。
といっても、とても簡単で、「インスタンスの操作」から「リードレプリカの昇格」を選ぶだけである。
しかし、これではフェイルオーバーは実現できない。マルチAZでは勝手にフェイルオーバーをやってくれるようだが、リードレプリカにはそういった機能はないようなので自分でスクリプトを作ってcronに書くなどする必要がある。
python3であれば、以下のようなスクリプトを使えば自動で昇格ができる。
import boto3 import socket domain_ip = socket.gethostbyname('ドメイン名') if domain_ip != 'メインのIP': secondary_client = boto3.client('rds',region_name='リージョン名',aws_acces s_key_id='*********',aws_secret_access_key='**********') secondary_response = secondary_client.promote_read_replica( DBInstanceIdentifier='昇格させたいリードレプリカの名前', )
rubyの場合のスクリプトはこの記事に書いてあるのを見つけた。
なお、この記事によると、一度昇格させると再びリードレプリカにすることはできないようである。
サブのwordpressの設定は、こちらの記事にあるものとほぼ同じである。 wp-config.phpでDB_USERとDB_PASSWORDはメインのRDSのユーザー名とパスワードにする。 DB_HOSTにはリードレプリカのホスト名を入れる。
(ちなみに、リードレプリカでも読み込みはできるので、昇格させないままでもページを表示させることは可能である。)
これで、メインのwordpressが使えなくなってもすぐにサブに切り替えることができる。