SQL Azureを徹底活用

第3回 SQL Azureのバックアップ

この記事を読むのに必要な時間:およそ 2 分

SQL Azureは,SQL Serverをベースに開発されました。しかし,バックアップ周りはSQL Serverと異なる点が多く,SQL Serverのバックアップ設計ノウハウを活用することができません。

SQL Serverでは,フルバックアップ,差分バックアップ,トランザクションログバックアップを組み合わせて,障害発生時のダウンタイムを短くしつつ,データロストを最小限にとどめるように設計してきました。

SQL Azureでは,ユーザがフルバックアップ,差分バックアップ,トランザクションログバックアップを取得することはできません。フルバックアップは,SQL Azureデータセンター内部で取得され,必要に応じてデータセンター内部で実行されるものです。ユーザにはフルバックアップ機能へのアクセスは提供されていません。

今回は,SQL Azureのバックアップ設計を検討する際に,参考になる情報を提供したいと思います。バックアップを取得する目的を整理し,目的に応じたバックアップ方法を提示します。

バックアップの目的

データベースをバックアップする目的には,次の4つがあります。

表1 データベースバックアップの目的

目的必要なデータ
データファイル破損からの復旧障害発生直前のデータ
大災害復旧対策可能な限り新しいデータ
アプリケーションバグによるデータ不整合からの復旧数日前~2週間前のデータ
開発環境や評価環境の構築直近のデータ
作業直前のデータ

データファイル破損からの復旧

データベースを運用していると,何らかの理由でデータファイルやトランザクションログが破損することがあります。ファイルが破損するとデータベースの動作が停止する障害が発生します。この障害発生に備えておくためにバックアップをとっておきます。アプリケーションの要件に左右されますが,障害直前にまでデータを復旧させられる必要があります。

大災害復旧対策

大災害によりデータセンターが,破壊されたり,ネットワーク不通になったり,電源消失したりし,データベースが使用できなくなる可能性があります。このような事態になった場合でも,事業継続(アプリケーション継続)できるようにするために,遠隔地にバックアップをとっておきます。大災害が発生してもデータが完全に喪失しないことが優先事項となるため,データの最新性は問われない傾向にあります。

アプリケーションバグによるデータ不整合からの復旧

アプリケーションバグやヒューマンエラーにより,データの不整合が発生することがあります。予期できないタイミングで発生するため,定期的にバックアップを自動で取り続ける必要があります。数日前から1,2週間前のバックアップデータが必要になることがあります。

開発環境や評価環境の構築

開発・テストのためのデータベース複製や,テスト後にデータを元に戻せるようにバックアップをすることがあります。この場合,直近のデータを手動でバックアップをすることが多いです。

データファイル破損からの復旧

第1回「SQL Azureとは何か」「プロビジョニング」で紹介したように,SQL Azureはデータを自動的に三重化しています。プライマリレプリカとセカンダリレプリカは,コミット同期されているため最新の状態に保たれています。

図1 SQL Azureのデータ三重化

図1 SQL Azureのデータ三重化

SQL Azureデータベースはオンライン状況を監視しています。データベースファイル破損などで,データベースが使用できない状態になった場合,プライマリレプリカがシャットダウンされ,セカンダリレプリカがプライマリレプリカに昇格します。

図2 障害時の処理

図2 障害時の処理

つまり,データファイル破損による障害から復旧を目的としたデータバックアップは必要が無いことがわかります。

SQL Azureで提供されているバックアップ手法では,障害が発生した直前の段階のデータをバックアップすることができません。SQL Azureの仕組みとして必要が無く,SQL Azureの仕組みとして実現する方法が無いため,設計から除外できます。

著者プロフィール

大和屋貴仁(やまとやたかひと)

Microsoft MVP for SQL Azure

2010年1月のWindows Azure正式リリース直後に,sqlazure.jpドメインを取得。ネタを探す日々ですので,SQL Azureで不明点があれば遠慮なくTwitterなどでご相談くださいませ。

Twitter:SQLAzureJP

URL:http://sqlazure.jp

コメント

コメントの記入