次の方法で共有

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

  • [アーティクル]

適用対象: Azure SQL データベース

Azure SQL データベース サービスは、すべてのデータベースがオンラインであり、正常であることを自動的に確認しており、公開されている 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 のセキュリティに関する記事を参照してください。
  • 更新して新しいプライマリにマップする必要があるアラート ルールを特定します。
  • 現在のプライマリ サーバーでの監査構成 を文書化し、セカンダリ サーバーで同じものを適用します。

関連するコンテンツ