もう止まらない。Amazon RDS Multi-AZ Deployments機能をリリース

本日、Amazon RDSの新機能、 Multi-AZ Deploymentsがリリースされました。

Release: Amazon Relational Database Service on 2010-05-17

これにより、RDSのダウンタイムがほぼ0になるという素敵な機能です!

Multi-AZ deploymentを有効にするとプライマリDBとは別のAvailability Zoneにホットスタンバイとしてレプリカが作成されます。
レプリカはプライマリDBと同期していて、プライマリDBが止まると自動的にレプリカにスイッチします。
フェイルオーバーの仕組みはシンプルで、CNAMEレコードを変更し、スタンバイDBに向けるだけです。

スタンバイDBに切りかわるタイミングは以下のとおりです。

• Availabilyty Zoneが落ちた時


• プライマリDBが落ちた時


• DBのスケールを変更した時


• ソフトウェアにパッチを当てている時

DBのバックアップ時に発生していたI/Oフリーズもなくなるようです。たぶんレプリカの方でバックアップを取るようになるのでしょう。

また、レプリカには直接アクセスすることができないので、Read Onlyなクエリをレプリカに逃がすというスケールアウト的な使い方はできません。

忘れてはならないコストですが、利用料は倍になります。
インスタンスが二つになるのでしょうがないと言えばしょうがないですね。


Multi-AZを適用する方法はすごく簡単です。

まずは以下から最新版のコマンドラインツールをダウンロードして使えるようにします。

Amazon RDS Command Line Toolkit

バージョンが1.1.004ならOKです。

$ rds-version
Relational Database Service CLI version 1.1.004 (API 2010-01-01)

あとは以下のコマンドを叩くだけで既存のインスタンスにMulti-AZ 機能を適用できます。

$ rds-modify-db-instance dbname --multi-az true

既存のインスタンスに適用すると、適用中に数分DBがダウンすると書かれているので、実行するタイミングには注意が必要です。

実際試してみたところ、このコマンドを実行するとインスタンスにPending MultAZフラグが立ちます。(rds-describe-db-instancesコマンドで確認できます。)
僕の環境ではコマンド実行から数時間経過しましたがまだPending状態のままです。
PendingからMulti-AZが有効の状態になるにはかなり時間がかかりそうです。

Pendingの状態でもDBには接続できているので、準備ができて、実際に適用するタイミングでちょっとばかりアクセスできなくなるんだと思います。

また、新規作成の際も--multi-azオプションを指定してやるだけみたいです。

これでますますRDSが手放せなくなりそうです。

RDS バックアップから復旧する方法

fooというRDSのインスタンスのバックアップからbarという新規インスタンスを作成する場合、以下のコマンドを実行する。

$ rds-restore-db-instance-to-point-in-time bar -s foo -l

-sでソースにする元のインスタンスの名前(ここではfoo)を指定し、-lで復元可能な最新の時刻のバックアップから復元することを指定する。

復元時刻を指定する場合は、-rオプションを使用する。
指定する時刻はUTC

$ rds-restore-db-instance-to-point-in-time bar -s foo -r 2010-05-04T09:20:00Z

リストア可能な最終時間はrds-describe-db-instancesに--show-longを指定することで確認できる。

$ rds-describe-db-instances --show-long --headers
DBINSTANCE,DBInstanceId,Created,Class,Engine,Storage,Master Username,Status,Endpoint Address,Port,AZ,Backup Retention,PendingBackupRetention,PendingClass,PendingCredentials,PendingStorage,DB Name,Mainte
nance Window,Backup Window,Latest Restorable Time
DBINSTANCE,foo,2010-02-22T10:07:04.933Z,db.m2.4xlarge,mysql5.1,20,owner,available,foo.xxxxxxx.us-east-1.rds.amazonaws.com,3306,us-east-1a,1,(nil),(nil),(nil),(nil),(nil),tue:05:00-mon:09:00,
19:00-21:00,2010-05-06T08:45:00Z

見づらいが、一番最後の2010-05-06T08:45:00Zが復元可能な最終時刻になる。

バックアップが行われるのは1日1回だけだが、バックアップ後のトランザクションが全部保存されているので、それを元に直近1分前程度の状態を復元可能。
このため、バックアップから時間が経過していればしているほど、復元する際に時間がかかる。
特にDBの更新が頻繁だと復元に時間がかかる。
150 updates/sec程度の更新量で5時にバックアップを行っていた場合、9時に復元したところ、1時間程度、19時頃復元したところ、5時間くらいかかった。