雑多なインフラエンジニア日記

技術ブログでっす～

RDSのフェイルオーバーについて

RDS

RDSのインスタンスタイプをsmallからmediumに変更した際に、
フェイルオーバーが走って、RDSがセカンダリAZに行ってしまった
件についてメモります。

再起動が発生する認識はありましたが、フェイルオーバーするという
認識は無く、なんでやねーんと調べてたら、以下にガッツリ書いてあ
りました。。。

・フェイルオーバー発生条件
http://aws.amazon.com/jp/rds/faqs/#43

以下が実行した際のログです。(AZは1a,1cのMulitiAZ構成)


1. ManagementConsole からインスタンスタイプ変更

2. 同時に別サーバからshow variablesをループさせて、
innodb_buffer_pool_sizeが変わるか確認。

Fri Apr  5 15:42:05 JST 2013
+-------------------------+------------+
| Variable_name           | Value      |
+-------------------------+------------+
| innodb_buffer_pool_size | 1179648000 |
+-------------------------+------------+

Fri Apr  5 15:42:06 JST 2013
ERROR 2003 (HY000): Can't connect to MySQL server on 'db001' (111)

Fri Apr  5 15:42:07 JST 2013
ERROR 2003 (HY000): Can't connect to MySQL server on 'db001' (111)

(省略)

Fri Apr  5 15:45:24 JST 2013
ERROR 2003 (HY000): Can't connect to MySQL server on 'db001' (110)

Fri Apr  5 15:46:29 JST 2013
+-------------------------+------------+
| Variable_name           | Value      |
+-------------------------+------------+
| innodb_buffer_pool_size | 2862612480 |
+-------------------------+------------+


約4分ほど通信断が発生したことが確認できました。
また、innodb_buffer_pool_sizeも自動的に増えています。



3. ステータスを確認する。(modifying → available)

[root@server001 ~]# A=0 ; while [ $A -eq 0 ] ; do date ; \
rds-describe-db-instances db001 |grep ^DBINSTANCE ; echo "" ; \
sleep 1 ; done

Fri Apr  5 15:51:04 JST 2013
DBINSTANCE  db001  2013-03-06T02:18:12.633Z  db.m1.small  mysql  5  dbuser1  
modifying  db001.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com  3306  
ap-northeast-1a  ap-northeast-1c  7  db.m1.medium  y  5.1.63
general-public-license  n

Fri Apr  5 15:51:06 JST 2013
DBINSTANCE  db001  2013-03-06T02:18:12.633Z  db.m1.small  mysql  5  dbuser1  
modifying  db001.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com  3306
ap-northeast-1a  ap-northeast-1c  7  db.m1.medium  y  5.1.63
general-public-license  n

(省略)

Fri Apr  5 15:56:17 JST 2013
DBINSTANCE  db001  2013-03-06T02:18:12.633Z  db.m1.medium  mysql  5  dbuser1  
available  db001.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com  3306  
ap-northeast-1c  ap-northeast-1a  7  y  5.1.63  
general-public-license  n

Fri Apr  5 15:56:20 JST 2013
DBINSTANCE  db001  2013-03-06T02:18:12.633Z  db.m1.medium  mysql  5  dbuser1  
available  db001.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com  3306  
ap-northeast-1c  ap-northeast-1a  7  y  5.1.63  general-public-license  n


上記では5分でステータスが変更したように見えてしまいますが、作業の都合上、
2.のあとに確認したので、実際にインスタンスのステータスが「modifying」から
「available」に変わるまでは、20-30分くらい掛かったと思います。

ここまでは良かったのですが、よくよくインスタンス情報を確認したら、
1a から 1c になっていたので焦りましたw

「ap-northeast-1a ap-northeast-1c」→「ap-northeast-1c ap-northeast-1a」
が該当の箇所です。左がプライマリAZ、右がセカンダリAZです。



4. IPアドレスを確認！

[root@server001 ~]# nslookup db001
Server:         192.168.0.2
Address:        192.168.0.2#53

Non-authoritative answer:
db001.test.com   canonical name = db001.xxxxxxxxxxxx.ap-northeast-
1.rds.amazonaws.com.
Name:   db001.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com
Address: 192.168.1.12

[root@server001 ~]#


元々は 192.168.0.10(1a) でしたが、フェイルオーバー後は
192.168.1.12(1c) になっています。


5. フェイルバックを実行し、AZを1aに戻します。

[root@server001 ]# rds-reboot-db-instance db001 --force-failover
DBINSTANCE  db001  2013-03-06T02:18:12.633Z  db.m1.medium  mysql  5  dbuser1  
rebooting  db001.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com  3306  
ap-northeast-1c  ap-northeast-1a  7  y  5.1.63  general-public-license  n
      VPCSECGROUP  sg-12345678  active
      SUBNETGROUP  db-subnet-pro01  production01  Complete  vpc-xxxxx
      SUBNET  subnet-11111111  ap-northeast-1c  Active
      SUBNET  subnet-22222222  ap-northeast-1a  Active
      PARAMGRP  para001  in-sync
      OPTIONGROUP  default:mysql-5-1  in-sync
[root@server001 ]#

[root@server001 ]# date ; rds-describe-db-instances db001
Fri Apr  5 19:00:38 JST 2013
DBINSTANCE  db001  2013-03-06T02:18:12.633Z  db.m1.medium  mysql  5  dbuser1  
rebooting  db001.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com  3306  
ap-northeast-1c  ap-northeast-1a  7  y  5.1.63  general-public-license  n
      VPCSECGROUP  sg-12345678  active
      PARAMGRP  custum001  in-sync
      SUBNETGROUP  db-subnet-pro01  Complete
      OPTIONGROUP  default:mysql-5-1  in-sync
[root@server001 ]#

[root@server001 ]# date ; rds-describe-db-instances db001
Fri Apr  5 19:02:40 JST 2013
DBINSTANCE  db001  2013-03-06T02:18:12.633Z  db.m1.medium  mysql  5  dbuser1  
available  db001.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com  3306  
ap-northeast-1a  ap-northeast-1c  7  y  5.1.63  general-public-license  n
      VPCSECGROUP  sg-12345678  active
      PARAMGRP  custum001  in-sync
      SUBNETGROUP  db-subnet-pro01  Complete
      OPTIONGROUP  default:mysql-5-1  in-sync
[root@server001 ~]#


約2分ほどでフェイルバックが完了しました。


6. フェイルバック後のIPアドレスを確認

[root@server001 ~]# nslookup db001
Server:         192.168.0.2
Address:        192.168.0.2#53

Non-authoritative answer:
db001.test.com   canonical name = db001.xxxxxxxxxxxx.ap-northeast-
1.rds.amazonaws.com.
Name:   db001.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com
Address: 192.168.0.59

[root@server001 ~]#

192.168.0.59(1a) であることが確認できました。RDSはDHCPなので想定通りです。
IPアドレスの変遷は、192.168.0.10(1a) → 192.168.1.12(1c) → 192.168.0.59(1a)
となります。


結論！


1. まず、インスタンスタイプを変更したらフェイルオーバーが発生しますYO！

2. お好み（必須？）でフェイルバックしてNE!

3. RDSのIPアドレスはコントロール出来ないので、R53でRDSのEndpointを登録する
必要がありますYO!（R53でなくても良いけどNE!）

4. NagiosでのRDSのDNS監視は、IP決め打ちなのだったので復旧を拾えない＆
都度監視の設定変更を強いられるので、不毛な設定になってしまったYO!

http://blog.cloudpack.jp/2011/06/aws-news-rds-failover-notes.html

5. RDSに障害が発生した際にSNS通知ができるようになったYO!必須だYO!

http://aws.typepad.com/aws_japan/2013/02/relational-database-service-now-with-event-subscriptions.html

Nagiosのport監視でもいいけど、SNSのほうが正確そうです。

以上です。