セールス: 1-800-867-1380

Azure SQL データベースにおける高可用性と災害復旧

更新日: 2014年4月

オンプレミスの SQL Server データベースを Azure SQL データベース (SQL データベース) に移行する場合、よくある質問は、ユーザーのミス、アプリケーションのエラー、ハードウェアの障害、自然災害によるデータ センターのシャットダウン、およびその他のデータベース障害からデータを守るために、バックアップと復元の方法をどのように実装すればよいかということです。オンプレミス配置と異なり、SQL データベースは、物理データベース ファイルの管理と操作をデータベース管理者からマスクするように設計されています。SQL データベース サーバーがデータベースのグループを定義する論理サーバーであることに注目してください。使用している SQL データベース サーバーに関連付けられているデータベースは、マイクロソフトのデータ センターに置かれた別々の物理コンピューターに存在している可能性があります。個々の論理データベースは、単一の物理データベースの領域を別の論理データベースと共有している可能性があります。マルチテナントの Azure 環境では、従来の SQL Server のバックアップ ツールや復元ツールは使用できません。

作成者: Kun Cheng、Selcin Turkarslan
校閲者: Steve Howard、Adrian Bethune

各 SQL データベース インスタンスは、1 つのデータセンター内の 3 つの異なる物理コンピューターに 3 つのレプリカ (1 つのプライマリ レプリカと 2 つのセカンダリ レプリカ) を持っています。すべての読み取りと書き込みはプライマリ レプリカを経由し、すべての変更はセカンダリ レプリカに非同期でレプリケートされます。

SQL データベースでは、クォーラムベースのコミット方法を使用します。この方法では、書き込みがプライマリ レプリカと 1 つのセカンダリ レプリカに対して完了した後で、トランザクションがコミットされたと見なされます。プライマリ レプリカでハードウェア障害が発生した場合、SQL データベース ファブリックはその障害を検出し、セカンダリ レプリカの 1 つにフェールオーバーします。したがって、データ センターにはトランザクションに関して一貫性のある物理的なデータのコピーが少なくとも 2 つ存在することになります。Microsoft Azure SQL データベース インスタンスごとに 3 つのレプリカが存在することにより、個々のサーバー、デバイス、またはネットワーク接続の障害からデータが保護されます。重複するレプリカに加え、Microsoft Azure SQL データベース ファブリックは、データ センター内のすべてのデータベースについて 5 分ごとに作成された特定の数のバックアップを維持します。これらのバックアップは、ハードウェアとシステムの障害が同時に発生した場合や致命的な障害が発生した場合に対する保護手段としてデータ センターに格納されます。

SQL データベース環境は、ハードウェア障害が発生した場合にサーバーの可用性とデータの整合性を維持するように設計されています。フェールオーバー時には、SQL データベース インスタンスはごく短時間アクセスできなくなることがあります。アプリケーションには、このようなフェールオーバー イベントを処理する再試行ロジックが必要です。ただし、セカンダリ レプリカにフェールオーバーした後、同じ接続文字列を使用して接続を再確立することができます。接続損失エラーの処理方法の詳細については、TechNet Wiki の記事「Azure SQL データベースのリソース管理」を参照してください。

ユーザーまたはアプリケーションのエラーは、多くのソフトウェア アプリケーションにおけるデータの損失または破損の最も一般的なシナリオの 1 つです。ユーザーは、テーブルまたはアプリケーションを誤って破棄したり、トランザクションを 2 回送信したりする可能性があります。この種のミスは、制御が難しく、復旧も容易ではありません。これらの問題に対処するには、次のサービスとツールを使用します。

  • セルフ サービスの復元サービス (Premium/Standard/Basic SKU)

  • データベース コピー

  • SQL データベースのインポートおよびエクスポート サービス

  • Bcp および SQL Server Integration Services

セルフサービスによる復元: SQL データベースの現在のプレビューでは、個々のデータベースを特定の時間枠内の時点に復元できます。時間枠は日単位で、最大 35 日です。詳細については、「Azure SQL データベースのバックアップと復元」を参照してください。

データベース コピーを使用すると、同じサーバー内または同じデータ センターの異なるサーバー内にデータベースのコピーを作成できます。データベース コピーは、オンラインで非同期に実行されるトランザクション一貫性のある操作です。非同期操作であるため、コピー コマンドを発行し、その後 sys.dm_database_copies (SQL データベース) システム ビューをクエリすることによって進捗状況を監視できます。

SQL データベース インスタンスをコピーするには、使用するログインがコピー先サーバーのサーバー レベル dbmanager ロールのメンバーであり、コピー元サーバーのソース データベースの DBO である必要があります。ログインは、両方の SQL データベース サーバー (コピー元とコピー先) でログイン名とパスワードが同じである必要があります。データベースをコピーする頻度は一律ではなく、ビジネス ニーズによって異なります。ユーザー エラーまたはアプリケーション エラーからの復旧が目的の場合は、毎日コピーを作成し、新しいコピーが完了した後で最も古いコピーを削除して、2 個または 3 個の有効なコピーを輪番で維持することをお勧めします。

お勧めするのは 1 日 1 回のコピーですが、データベースをコピーする頻度をさらに増やすこともできます。データベース コピー操作は、1 時間に 1 回以上の頻度で実行しないことをお勧めします。それぞれのデータベース コピー プロセスは、他のすべてのデータベース コピー プロセスから独立して実行されますが、コピー プロセスの終了時点でトランザクション一貫性を備えたデータベースのコピーを生成します。各コピーは、SQL データベースごとのデータベース制限である 150 個のデータベースの 1 つとしてカウントされ、独立したデータベースとして課金されます。したがって、コピーの回数が多すぎると、アカウントで使用できるデータベースを使い果たし、ほぼ同一のデータベース コピーに対して不要な費用を支払うことになりかねません。詳細については、SQL データベース MSDN ライブラリの「データベースをコピーする方法」を参照してください。

データベース コピーに加えて、SQL Database Import/Export Serviceを使用することもできます。このサービスを使用すると、拡張子 .bacpac が付いたパッケージでデータとスキーマの両方をインポートまたはエクスポートできます。このパッケージは、テーブル、ビュー、インデックス、制約、トリガー、ストアド プロシージャ、ログイン、ユーザーなど、すべての SQL データベース互換オブジェクトを含む圧縮形式になっています。このサービスを使用すると、SQL データベース インスタンスと Azure BLOB ストレージの間で BACPAC ファイルのインポートとエクスポートを直接実行できます。インポートおよびエクスポート サービスには、Azure Management Portal を通じてアクセスできます。Azure BLOB ストレージを使用せずに、オンプレミス SQL Server と SQL データベースの間でインポートまたはエクスポートを直接行う場合、Microsoft.SqlServer.Dac 名前空間で提供されているクラスを使用します。

データベース コピーとは異なり、インポートおよびエクスポート サービスでは、トランザクション一貫性のあるバックアップは生成されません。バックアップを行うには、データベースをロック ダウンし、トランザクションを停止してからデータとスキーマをエクスポートするか、まずデータベース コピーを使用してトランザクション一貫性のあるコピーを作成し、そのコピーからエクスポートすることをお勧めします。インポート/エクスポートの詳細については、「データベースをインポート/エクスポートする方法」を参照してください。

Bulk copy utility (BCP.exe)SQL Server Integration Services (SSIS)、および System.Data.SqlClient.SqlBulkCopyImport/Export Serviceに似ています。現在、SQL データベースは、データの移動用に BCP、一括コピー API、および SSIS をサポートしています。データを読み込む前に、SQL データベースでスキーマ オブジェクトを作成する必要があります。一括コピーのメカニズムとして BCP または SSIS を使用すると、データベース内から移動するオブジェクトと、それらのオブジェクトから移動するデータを制御できます。また、バッチ サイズ、パケット サイズ、ストリーム数などのさまざまなパラメーターを指定して、ネットワークの帯域幅および遅延に応じた最良のスループットを実現することができます。

災害時のデータ センターの損失を防ぐには、データ センターの外部にオフサイトのデータベース バックアップ ストレージを作成し、そこにデータベース アプリケーションを配置します。これを実現するには、次の方法を使用することをお勧めします。

  • Premium および Standard SKU の場合は、geo レプリケーション

  • Basic SKU の場合は、代替 Azure 地域への復元

  • Web または Business SKU の場合は、データベース コピーと SQL データベース インポート/エクスポート サービス (前のセクションを参照)

geo レプリケーションの詳細については、「Azure SQL データベースのアクティブな geo レプリケーション」を参照してください。Web および Business エディションの Azure データベースの場合は、次に提案するツールを使用してバックアップと復元の全体的な方法を管理することをお勧めします。

  • ユーザーおよびアプリケーションのエラーを処理するためにバックアップと復元の方法を実装するには、次のツールを使用します。

    • データベース コピー

    • SQL データベースのインポートおよびエクスポート サービス

    • Bcp または SQL Server Integration Services

  • 広範囲にわたるデータ センター機能の損失に対処するために高度なバックアップと復元の方法を実装するには、次のツールを使用します。

    • インポートおよびエクスポート サービスを使用してデータベース コピーを 1 つ以上のセカンダリ データ センターにコピーし、必要に応じて独自のオンプレミス SQL Server 内にもコピーします。

Microsoft Azure のバックアップ、復元、および災害復旧オプションの詳細については、MSDN ライブラリの記事「Azure SQL データベースのビジネス継続性」と「Microsoft Azure のビジネス継続性に関するテクニカル ガイダンス」を参照してください。

この情報は役に立ちましたか。
(残り 1500 文字)
フィードバックをいただき、ありがとうございました
表示:
© 2014 Microsoft