高可用性とディザスター リカバリーを構成する

SQL Server でディザスター リカバリーと高可用性ソリューションを構成する主な部分は、Azure 仮想マシンで実行されている SQL Server でも変わりません。 高可用性ソリューションは、障害が原因でコミットされたデータが失われないことを保証し、ワークロードがメンテナンス操作の影響を受けず、データベースがソフトウェア アーキテクチャの単一障害点にならないことを保証するように設計されています。

ほとんどの Azure SQL サービス レベルでは、ローカル冗長モデルからゾーン冗長モデルまで、の高可用性オプションの範囲が提供されています。

次に、Azure の PaaS オファリングのディザスター リカバリーと高可用性のための特定のソリューションについて説明します。

継続的バックアップ

Azure SQL Database では、データベース の定期的なバックアップと の継続的バックアップが保証され、読み取りアクセス geo 冗長ストレージ (RA-GRS) にレプリケートされます。

週単位の完全バックアップ、12 ~ 24 時間ごとの差分バックアップ、5 分から 10 分ごとのトランザクション ログ バックアップは、自動バックアップ戦略の一部です。 バックアップの可用性を延長する場合 (最大 10 年間)、単一データベースとプールされたデータベースの両方に対して長期リテンション期間 (LTR) を構成できます。

長期保有 (LTR)

Azure には、通常の制限を超えて設定できるアイテム保持ポリシーが用意されています。これは、長期的な保持 必要とするシナリオに役立ちます。 保持ポリシーは最大 10 年間まで設定できます。このオプションは既定で無効になっています。

この画像は、Azure portal で長期保有ポリシーを設定する方法を示しています。 データベースを選択すると、画面の右側にパネルが表示され、既定の設定を変更できます。

長期的なリテンション期間の詳細については、「長期リテンション期間 - Azure SQL Database と Azure SQL Managed Instance」を参照してください。

geo リストア

既定では、SQL Database と SQL Managed Instance のバックアップは geo 冗長です。 これにより、データベースを別の地理的リージョンに簡単に復元できます。これは、あまり厳格でないディザスター リカバリー シナリオに役立つ機能です。

バックアップ ストレージは、通常のデータベース ファイル ストレージとは別に課金されます。 ただし、SQL Database をプロビジョニングする場合、バックアップ ストレージは、追加コストなしでデータベース用に選択されたデータ層の最大サイズで作成されます。

geo リストア操作の期間は、データベースのサイズ、復元操作に関係するトランザクション ログの数、ターゲット リージョンで同時に処理される復元要求の量など、いくつかの基になるコンポーネントによって影響を受ける可能性があります。

ポイントインタイム復元 (PITR)

定義されたリテンション期間に従ってデータベースを特定の時点に復元できますが、PITR は、バックアップが開始されたのと同じサーバー内のデータベースを復元する場合にのみサポートされます。 Azure portal、Azure PowerShell、Azure CLI、または REST API のいずれかを使用して、SQL Database を復元できます。

アクティブ geo レプリケーション

Azure SQL Database の可用性を向上させる方法の 1 つは、アクティブ geo レプリケーション 使用することです。 アクティブ geo レプリケーションでは、セカンダリ データベースのレプリカが別のリージョンに作成され、非同期的に最新の状態に保たれます。

このレプリカは、SQL Server の AlwaysOn 可用性グループと同様に読み取り可能です。 Azure では、この機能を維持するために可用性グループが使用されているため、一部の用語は似ています。

アクティブ geo レプリケーションは、大規模な災害時にプライマリ データベースをセカンダリ リージョンにプログラムまたは手動でフェールオーバーすることで、ビジネス継続性を実現しています。

geo レプリケーションのリレーションシップに関わるすべてのデータベースは、同じサービス レベルを持つ必要があります。 さらに、書き込みワークロードの負荷が高いため、レプリケーションのパフォーマンスの問題を防ぐために、プライマリと同じコンピューティング サイズでセカンダリ レプリカを構成することをお勧めします。

Azure SQL Database の geo レプリケーションを手動で構成するには、データベースのブレードにアクセスし、[データ管理] セクションで [レプリカ] を選択し、[+ レプリカの作成] をします。

セカンダリ レプリカが確立されたら、フェールオーバーを手動で開始するオプションがあります。 このプロセスでは、ロールは元に戻されます。セカンダリ レプリカはプライマリの役割を引き受け、元のプライマリはセカンダリになります。

サブスクリプション間 geo レプリケーション

シナリオによっては、プライマリ データベースとは異なるサブスクリプションでセカンダリ レプリカを構成する必要があります。 ここで、サブスクリプション間 geo レプリケーションの機能が機能します。

サブスクリプション間 geo レプリケーションを構成するために必要な手順の詳細については、「サブスクリプション間 geo レプリケーションの」を参照してください。

自動フェールオーバー グループ

自動フェールオーバー グループ は、Azure SQL Database と Azure SQL Managed Instance の両方でサポートされる高可用性機能です。 自動フェールオーバー グループを使用すると、データベースを別のリージョンにレプリケートする方法と、フェールオーバーが発生する方法を管理できます。 自動フェールオーバー グループに割り当てられる名前は、*.database.windows.net ドメイン内で一意である必要があります。

自動フェールオーバー グループには、複数のデータベースを含めることができます。 プライマリとセカンダリのデータベース サイズはどちらも同じです。

自動フェールオーバー グループは、リスナーと呼ばれる AG に似た機能を提供します。これにより、読み取りおよび書き込みアクティビティと読み取り専用アクティビティの両方が可能になります。 リスナーには、読み取り/書き込み用と読み取り専用トラフィック用の 2 種類があります。 フェールオーバーのバックグラウンドで DNS が更新されるため、クライアントは抽象化されたリスナー名を指し示すことができ、他の情報を知る必要はありません。 読み取りおよび書き込みコピーを含むデータベース サーバーがプライマリであり、プライマリからトランザクションを受信しているサーバーがセカンダリです。

自動フェールオーバー グループには、2 つの異なるポリシーがあります。

フェールオーバーは、自動フェールオーバーが有効になっている場合でも、手動で開始できるプロセスです。 ただし、フェールオーバーの種類は、データ損失が発生するかどうかに影響を与える可能性があります。 たとえば、計画外のフェールオーバーが強制され、セカンダリ データベースがプライマリと完全に同期されていない場合、データが失われる可能性があります。

GracePeriodWithDataLossHours では、Azure がフェールオーバーを開始するまでの待機時間が決定され、既定値は 1 時間に設定されます。 目標復旧ポイント (RPO) が厳しく、データ損失がオプションでない場合は、この値を高く設定できます。 これは、フェールオーバーを開始する前に Azure の待機時間が長くなることを意味しますが、セカンダリ データベースがプライマリと完全に同期する時間が長くなるため、データ損失を減らす可能性があります。

Azure SQL Database の高可用性とディザスター リカバリーの詳細については、azure SQL Database の高可用性とディザスター リカバリーのチェックリスト を参照してください。