Azure SQL Database の高可用性とディザスター リカバリーのチェックリスト

適用対象:Azure SQL Database

Azure SQL Database サービスは、すべてのデータベースがオンラインであり、正常であることを自動的に確認しており、公開されている SLA を達成するために常に取り組んでいます。

このガイドでは、可用性を最大化し、確実に回復し、Azure の停止に備えるために実行できるプロアクティブな手順を詳細に確認できます。 このガイダンスは、Azure SQL Database のすべての購入モデルとサービス レベルに適用されます。

可用性のチェックリスト

可用性を最大化するための推奨構成を次に示します。

• アプリケーションに再試行ロジックを組み込んで、一時的なエラーを処理します。
• メンテナンス期間を利用して、影響の大きいメンテナンス イベントを予測可能にし、中断を減らします。
• 手動でフェイルオーバーをトリガーして、アプリケーションの障害回復性をテストし、回復性の動作を確認します。

高可用性のチェック リスト

高可用性を実現するために推奨される構成を次に示します。

• データベースまたはエラスティックプールでゾーン冗長を有効にし、ゾーン障害に対する回復力を確保します。

ディザスター リカバリー チェックリスト

Azure SQL データベースは自動的に可用性を維持しますが、高可用性（ゾーンの冗長性）を持っていても、影響を与える障害が地域全体に及ぶため、回復力が保証されない場合があります。 リージョン Azure SQL データベースの停止により、ディザスター リカバリーの開始が必要になることがあります。

ディザスター リカバリーに最適な準備をするには、次の推奨事項に従います。

• データベースのグループに対してフェールオーバー グループを有効にします。
  • アプリケーション 接続文字列で読み取り/書き込みおよび読み取り専用リスナー エンドポイントを使用して、アプリケーションがプライマリであるサーバーとデータベースに自動的に接続できるようにします。
  • フェールオーバー ポリシーをカスタマー マネージドに設定します。
• フェイルオーバー・グループの代わりに、アクティブ geo レプリケーションを有効にして、別の Azure リージョンで読み取り可能なセカンダリー・データベースを持つこともできます。
• geo セカンダリ データベースが、プライマリ データベースと同じサービス レベル、 コンピューティング レベル (プロビジョニング済みまたはサーバーレス) とコンピューティング サイズ (DTU または仮想コア) で作成されていることを確認します。
• スケールアップするときは、まず geo セカンダリをスケールアップしてから、プライマリをスケールアップすることをお勧めします。
• スケールダウンする場合は、順序を逆にします。最初にプライマリをスケールダウンし、次にセカンダリをスケールダウンします。
• 本来、ディザスター リカバリーは、プライマリとセカンダリのリージョン間でデータの非同期レプリケーションを使うように設計されています。 コミットの待機時間が長くなることよりもデータの可用性を優先するには、トランザクションをコミットした直後に sp_wait_for_database_copy_sync ストアド プロシージャを呼び出すことを検討してください。 を呼び出す sp_wait_for_database_copy_sync と、最後にコミットされたトランザクションが転送され、セカンダリデータベースのトランザクションログに書き込まれるまで、呼び出し元のスレッドがブロックされます。
• プライマリ データベース上の sys.dm_geo_replication_link_status 動的管理ビュー (DMV) の replication_lag_sec 列を使って、回復ポイント目標 (RPO) に関する遅延を監視します。 DMV には、プライマリでコミットされたトランザクションとセカンダリでトランザクション ログに書き込まれたトランザクション間のラグが秒単位で表示されます。 例えば、ある時点でタイムラグが1秒だったとします、プライマリが停止の影響を受け、その時点で geo フェールオーバーが開始された場合、最後の 1 秒間にコミットされたトランザクションは失われます。
• フェールオーバー グループまたはアクティブ geo レプリケーションを有効にできない場合は、geo リストア機能を使用するために、バックアップ ストレージ冗長オプションを geo 冗長バックアップ ストレージに設定することを検討してください。
  • このオプションは、リージョン ペアのないリージョンでは使用できません。
• 実際の停止が発生した場合に備えられるように、ディザスター リカバリーの訓練の計画と実施を頻繁に行ってください。

障害に備えセカンダリを準備する

アクティブ geo レプリケーション、フェールオーバー グループ、または geo リストアのいずれかを使って別のデータ リージョンへの回復を成功させるには、別のリージョンにセカンダリ Azure SQL データベース論理サーバーを準備する必要があります。 このセカンダリ サーバーは、必要に応じて新しいプライマリ サーバーとすることができます。 また、スムーズな回復を実現するために、明確に定義した手順を文書化し、テストしておく必要があります。 この準備手順を次に示します。

• geo リストアのために、他のリージョンで新しいプライマリ サーバーとして使うサーバーを特定します。 通常、これはプライマリ データベースが配置されているリージョンのペア リージョンにあるサーバーです。 同じリージョンでサーバーを使用すると、geo リストア操作中に余分なトラフィック コストが削減されます。
• ユーザーを新しいプライマリ サーバーにリダイレクトする方法を決定します。 これを実現するには、アプリケーションの接続文字列または DNS エントリを手動で変更します。 フェールオーバー グループを構成し、アプリケーション接続文字列で読み取り/書き込みと読み取り専用のリスナーを使っている場合、接続は自動的に新しいプライマリに転送されるため、これ以上の操作は必要ありません。
• ユーザーが新しいプライマリ データベースにアクセスするのに必要なファイアウォール規則を特定し、必要に応じて定義します。
• 新しいプライマリ サーバーの master データベースに必要なログインを特定し、必要に応じて作成します。また、master データベースにあるこれらのログインに、適切なアクセス許可が付与されていることを確認します (ある場合)。 詳細については、ディザスター リカバリー後の Azure SQL Database のセキュリティに関する記事を参照してください。
• 更新して新しいプライマリにマップする必要があるアラート ルールを特定します。
• 現在のプライマリで監査の構成を文書化します

関連するコンテンツ

• 「Azure SQL Database のディザスター リカバリー ガイダンス」を確認します。
• Azure SQL Database の SLA を確認します。
• Azure SQL Database 自動バックアップの詳細については、「 SQL Database 自動バックアップ」を参照してください
• ビジネス継続性の設計および復旧シナリオについては、継続性のシナリオに関する記事を参照します。
• 自動バックアップを使用して復旧する方法については、 サービス主導のバックアップからのデータベース復元に関するページをご覧ください
• アクティブ geo レプリケーションの詳細を確認します。
• フェールオーバー グループの詳細を確認します。
• geo リストアの詳細を確認します。
• ゾーン冗長データベースの詳細を確認します。