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

  • [アーティクル]

適用対象: Azure SQL Managed Instance

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

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

可用性のチェックリスト

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

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

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

  • SQL Managed Instance で使用できる場合、ゾーン冗長を有効にするとゾーンでの障害から確実に回復できます。

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

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

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

  • インスタンスのフェールオーバー グループを有効にします。
    • アプリケーション 接続文字列で読み取り/書き込みおよび読み取り専用リスナー エンドポイントを使用して、アプリケーションがプライマリであるインスタンスに自動的に接続できるようにします。
    • フェールオーバー ポリシーをカスタマー マネージドに設定します。
  • geo セカンダリ インスタンスが、プライマリ インスタンスと同じサービス レベル、ハードウェア世代、コンピューティング サイズで作成されていることを確認します。
  • スケールアップするときは、まず 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 リストアを使用して別のデータ領域への復元を正常に行うには、別のリージョンにセカンダリ Azure SQL Managed Instance を用意する必要があります。 このセカンダリ インスタンスは、必要に応じて新しいプライマリ インスタンスとすることができます。 また、スムーズな回復を実現するために、明確に定義した手順を文書化し、テストしておく必要があります。 この準備手順を次に示します。

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

関連するコンテンツ

詳細については、次を参照してください。