Amazon RDS のバックアップと復旧

Amazon RDS には、データベースバックアップを自動化する機能が含まれています。Amazon RDS は、データベースインスタンスのストレージボリュームのスナップショットを作成し、個々のデータベースのみではなく、DB インスタンス全体をバックアップします。Amazon RDS を使用すると、自動バックアップ用のバックアップウィンドウを設定したり、データベースインスタンスのスナップショットを作成したり、リージョンやアカウント間でスナップショットを共有したりコピーしたりできます。

Amazon RDS には、DB インスタンスのバックアップと復元に 2 つの異なるオプションがあります。

• 自動バックアップは、DB インスタンスのポイントインタイムリカバリ (PITR) を提供します。自動バックアップは、新しい DB インスタンスを作成するとデフォルトでオンになっています。

  Amazon RDS は、DB インスタンスの作成時に定義したバックアップウィンドウ中に、データの完全バックアップを毎日実行します。自動バックアップの保存期間は最大 35 日まで設定できます。Amazon RDS はまた、DB インスタンスのトランザクションログを 5 分ごとに Amazon S3 にアップロードします。Amazon RDS は、毎日のバックアップとデータベーストランザクションログを使用して DB インスタンスを復元します。LatestRestorableTime (通常、最後の 5 分) までの保持期間中であれば、インスタンスを任意の秒にリストアできます。

  DB インスタンスの復元可能な最新の時刻を確認するには、DescribeDBInstances API 呼び出しを使用します。または、Amazon RDS コンソールの [説明] タブでデータベースを確認してください。

  PITR を開始すると、トランザクションログと最も適切な日次バックアップが組み合わされ、DB インスタンスが要求された時刻に復元されます。

• DB スナップショットはユーザーが開始するバックアップであり、DB インスタンスを必要な頻度で既知の状態に復元するために使用できます。その後、いつでもその状態に復元できます。DB スナップショットを作成するには、Amazon RDS コンソールか CreateDBSnapshot API コールを使用します。これらのスナップショットは、コンソールまたは DeleteDBSnapshot API 呼び出しを使用して明示的に削除するまで保持されます。

これらのバックアップオプションはどちらも、AWS Backup に含まれる Amazon RDS でサポートされています。AWS Backup を使用して Amazon RDS データベースの標準バックアッププランを設定することを検討し、特定のデータベースのバックアッププランが独自の場合はユーザー主導のインスタンスバックアップオプションを使用することを検討します。

Amazon RDS は DB インスタンスが使用する基盤となるストレージへの直接アクセスを防ぎます。これにより、RDS DB インスタンス上のデータベースをローカルディスクに直接エクスポートすることもできなくなります。場合によっては、クライアントユーティリティを使用してネイティブのバックアップおよび復元機能を使用できます。たとえば、Amazon RDS MySQL データベースで mysqldump のコマンド実行 を使用して、データベースをローカルクライアントマシンにエクスポートできます。Amazon RDS には、データベースのネイティブバックアップと復元を実行するための拡張オプションも用意されている場合があります。例えば、Amazon RDS はSQL Server データベースの RDS データベースバックアップをエクスポートインポートするストアドプロシージャを提供しています。

バックアップと復元の全体的なアプローチの一環として、データベースの復元プロセスとそれがデータベースクライアントに与える影響を徹底的にテストします。

DNS CNAME レコードを使用して、データベース復旧中のクライアントへの影響を軽減します。

PITR または RDS DB インスタンススナップショットを使用してデータベースを復元すると、新しいエンドポイントを持つ新しい DB インスタンスが作成されます。この方法では、特定の DB スナップショットまたは特定の時点から複数の DB インスタンスを作成できます。RDS DB インスタンスを復元してライブの RDS DB インスタンスを置き換える場合は、特別な考慮事項があります。たとえば、中断や変更を最小限に抑えながら、既存のデータベースクライアントを新しいインスタンスにリダイレクトする方法を決定する必要があります。また、リストアされたデータの時間と、新しいインスタンスが書き込みを受け始める際のリカバリ時間を考慮することで、データベース内のデータの継続性と一貫性を確保する必要があります。

DB インスタンスのエンドポイントを指す別の DNS CNAME レコードを作成し、クライアントにこの DNS 名を使用させることができます。そうすれば、データベースクライアントを更新しなくても、復元された新しいエンドポイントを指すように CNAME を更新できます。

CNAME レコードの TTL (Time to Live) を適切な値に設定します。指定する TTL によって、別のリクエストが行われるまでレコードが DNS リゾルバーにキャッシュされる時間が決まります。DNS リゾルバやアプリケーションの中には、TTL を守らず、TTL よりも長い間レコードをキャッシュするものがあるかもしれないことに注意することが重要です。Amazon Route 53 の場合、より長い値 (たとえば、172800 秒、または 2 日間) を指定すると、DNS 再帰リゾルバがこのレコードの最新情報を取得するために Route 53 に行わなければならない呼び出しの回数を減らすことができます。これによりレイテンシーが軽減され、Route 53 サービスの請求額が削減されます。詳細については、「Amazon Route 53 によりドメインのトラフィックをルーティングする方法」を参照してください。

アプリケーションやクライアントオペレーティングシステムは DNS 情報をキャッシュする場合もあるため、新しい DNS 解決リクエストを開始して更新された CNAME レコードを取得するには、フラッシュまたは再起動する必要があります。

データベースの復元を開始し、復元したインスタンスにトラフィックを移すときは、すべてのクライアントが以前のインスタンスではなく、復元されたインスタンスに書き込んでいることを確認します。データアーキテクチャによっては、データベースの復元、DNS の更新、復元したインスタンスへのトラフィックの移行、前のインスタンスにまだ書き込まれているデータの修正がサポートされている場合があります。そうでない場合は、DNS CNAME レコードを更新する前に既存のインスタンスを停止できます。そうすれば、新しく復元したインスタンスからすべてのアクセスが可能になります。これにより、個別に処理できる一部のデータベースクライアントで接続の問題が一時的に発生することがあります。クライアントへの影響を軽減するために、メンテナンスの時間帯にデータベースを復元できます。

指数バックオフを使用して再試行してデータベース接続障害をスムーズに処理するアプリケーションを作成します。これにより、復元中にデータベース接続が使用できなくなった場合でも、アプリケーションが予期せずクラッシュすることなく、アプリケーションを回復できます。

復元プロセスが完了したら、以前のインスタンスを停止状態に保つことができます。または、セキュリティグループのルールを使用して、不要になったことを確認するまで前のインスタンスへのトラフィックを制限できます。段階的に廃止するアプローチでは、まず実行中のデータベースへのアクセスをセキュリティグループによって制限します。インスタンスが不要になった場合は、最終的に停止できます。最後に、データベースインスタンスのスナップショットを作成して削除します。