Azure SQL Managed Instance は、サービスとしてのフル マネージド プラットフォーム (PaaS) データベース エンジンです。 SQL Serverとほぼ 100% 機能の互換性を提供します。 Azure SQL Managed Instanceは、アップグレード、修正プログラムの適用、バックアップ、監視など、ほとんどのデータベース管理機能をユーザーの関与なしに処理します。 これは、SQL Server データベース エンジンの最新の安定したバージョンと、組み込みの高可用性を備えた修正プログラムが適用されたオペレーティング システムで実行されます。
Azureを使用する場合、信頼性は共有責任です。 Microsoft では、回復性と回復性をサポートするさまざまな機能を提供しています。 使用するすべてのサービスでこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を達成するために必要な機能を選択する必要があります。
この記事では、一時的な障害、可用性ゾーンの停止、リージョンの停止など、さまざまな潜在的な障害や問題に対してAzure SQL Managed Instance回復性を確保する方法について説明します。 また、バックアップを使用して他の種類の問題から復旧する方法、サービスメンテナンスを処理する方法、およびAzure SQL Managed Instanceサービス レベル アグリーメント (SLA) に関するいくつかの重要な情報を強調表示します。
信頼性のための運用環境のデプロイに関する推奨事項
SQL Managed Instanceのほとんどの運用環境のデプロイでは、次の推奨事項を検討してください。
- 高可用性とディザスター リカバリー (DR) チェックリストに記載されているガイダンスに従ってください。
- ゾーン冗長を有効にします。
- 自動バックアップを構成し、バックアップにはゾーン冗長ストレージ (ZRS) または geo 冗長ストレージ (GRS) を使用します。
- バックアップと復元のプロセスを定期的にテストする計画を立てます。
信頼性アーキテクチャの概要
General Purpose SQL マネージド インスタンスは、Azure Service Fabricが管理する単一のノードで実行されます。 データベース エンジンまたはオペレーティング システムがアップグレードされたとき、または障害が検出されるたびに、SQL Managed Instanceは Service Fabric と連携して、ステートレス データベース エンジン プロセスを、十分な空き容量を持つ別のステートレス コンピューティング ノードに移動します。 データベース ファイルは、冗長性機能が組み込まれているAzure Blob Storageに格納されます。 データとログ ファイルは元の計算ノードからデタッチされ、新しく初期化されたデータベース エンジン プロセスにアタッチされます。
Business Critical SQL マネージド インスタンスは、クラスター内の複数のレプリカを使用します。 クラスターには、次の 2 種類のレプリカが含まれています。
読み取り/書き込み顧客ワークロードにアクセスできる 1 つのプライマリ レプリカ
データのコピーを含む最大 5 つの セカンダリ レプリカ (コンピューティングとストレージ)
プライマリ レプリカは継続的かつ順番に変更をセカンダリ レプリカにプッシュします。これにより、各トランザクションをコミットする前に、十分な数のセカンダリ レプリカにデータが保持されます。 このプロセスにより、プライマリ レプリカまたは読み取り可能なセカンダリ レプリカが使用できなくなった場合、完全に同期されたレプリカが常にフェールオーバーに使用できるようになります。
SQL Managed Instanceと Service Fabric レプリカ間のフェールオーバーを開始します。 セカンダリ レプリカが新しいプライマリ レプリカになると、クォーラムを維持するのに十分な数のレプリカがクラスターに確保されるように、別のセカンダリ レプリカが作成されます。 フェールオーバーが完了すると、Azure SQL接続は、接続文字列に基づいて、新しいプライマリ レプリカまたは読み取り可能なセカンダリ レプリカに自動的にリダイレクトされます。
冗長性
既定では、SQL Managed Instanceは、コンピューティング ノードとデータをプライマリ リージョンの 1 つのデータセンター全体に分散することで冗長性を実現します。 この方法では、次の予期されるダウンタイムと予期しないダウンタイム中にデータを保護します。
お客様が開始した 管理操作 により、短時間のダウンタイムが発生する
サービス メンテナンス業務
小規模なネットワークまたは電源障害
次のコンポーネントに関連する問題とデータセンターの停止:
サービスを支えるマシンが稼働しているラック
SQL データベース エンジンを実行している仮想マシン (VM) をホストする物理マシン。
SQL データベース エンジンを実行する VM
SQL データベース エンジンに関する問題
想定外に局地的な停止が発生する可能性
SQL Managed Instanceが冗長性を提供する方法の詳細については、「ローカルとゾーンの冗長性による可用性を参照してください。
一時的な障害に対する回復性
一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションで一時的な障害を処理できることは重要です。通常は、影響を受ける要求を再試行します。
クラウドでホストされているすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure一時的な障害処理ガイダンスに従う必要があります。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。
SQL Managed Instanceは、修正プログラムの適用、バックアップ、Windows、SQL データベース エンジンのアップグレードなど、重要なサービス タスクを自動的に処理します。 また、基になるハードウェア、ソフトウェア、ネットワーク障害などの計画外のイベントも処理します。 SQL Managed Instanceは、最も重大な状況でも迅速に復旧できます。これにより、データが常に使用可能になります。 ほとんどのユーザーは、アップグレードが継続的に実行されていることに気付きません。
インスタンスに修正プログラムが適用されたり、フェールオーバーされたりすると、アプリケーションで 再試行ロジックを使用 した場合のダウンタイムの影響は最小限になります。 一時的な障害に対するアプリケーションの回復性をテストできます。
可用性ゾーンの障害に対する回復性
注
現在、次世代 General Purpose サービス レベルではゾーン冗長を使用できません。
Availability zones は、Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。
ゾーン冗長構成を有効にすると、アプリケーション ロジックを変更することなく、データセンターの壊滅的な停止などの一連の大規模な障害に対して SQL マネージド インスタンスの回復性を確保できます。
SQL Managed Instanceは、ステートレス コンピューティング ノードをさまざまな可用性ゾーンに配置することで、ゾーンの冗長性を実現します。 現在アクティブな SQL データベース エンジン プロセスを含むノードにアタッチされたステートフル ZRS に依存します。 障害が発生した場合、SQL データベース エンジン プロセスはステートレス コンピューティング ノードのいずれかでアクティブになり、ステートフル ストレージ内のデータにアクセスします。
SQL Managed Instanceは、複数の可用性ゾーンにSQL managed instanceのレプリカを配置することで、ゾーンの冗長性を実現します。 単一障害点をなくすため、制御リングも複数のゾーンで複製されます。 コントロール プレーンのトラフィックは、可用性ゾーン全体にデプロイされたロード バランサーにルーティングされます。 Azure Traffic Managerは、コントロール プレーンからロード バランサーへのトラフィック ルーティングを制御します。
Requirements
Region support: SQL Managed Instance のゾーン冗長は、一部のリージョンでサポートされます。 詳細については、「サポートされているリージョン」を参照してください。
バックアップ ストレージの冗長性: SQL マネージド インスタンスのゾーン冗長を有効にするには、バックアップ ストレージの冗長性を ZRS または Geo ゾーン冗長ストレージ (GZRS) に設定します。
費用
ゾーン冗長を有効にすると、SQL マネージド インスタンスとゾーン冗長バックアップに対して追加コストが発生します。 詳細については、価格に関するページをご覧ください。
Business Critical サービス レベルのゾーン冗長インスタンスを含むコンピューティング リソースを一定期間割引料金で使用することをコミットすることで、コストを節約できます。 詳細については、「reservations for SQL Managed Instance」を参照してください。
可用性ゾーンのサポートを設定する
このセクションでは、SQL マネージド インスタンスの可用性ゾーンのサポートを構成する方法について説明します。
ゾーン冗長を有効にする: 新規および既存のインスタンスでゾーン冗長を構成する方法については、「 ゾーン冗長の構成」を参照してください。
ゾーンの冗長性の有効化を含め、SQL Managed Instanceのすべてのスケーリング操作はオンライン操作であり、ダウンタイムを最小限に抑える必要はありません。 詳細については、「 管理操作の期間」を参照してください。
ゾーン冗長を無効にする: ゾーン冗長を有効にするときと同じ手順で、ゾーン冗長を無効にすることができます。 このプロセスはオンライン操作であり、サービス レベルの通常の目標アップグレードと似ています。 このプロセスを終了すると、インスタンスはゾーン冗長インフラストラクチャから単一ゾーン インフラストラクチャに移行されます。
すべてのゾーンが正常な場合の動作
このセクションでは、SQL マネージド インスタンスがゾーン冗長として構成されていて、すべての可用性ゾーンが動作している場合に想定される内容について説明します。
ゾーン間のTraffic ルーティング: 通常の操作中に、SQL Managed Instanceコンピューティング レイヤーを実行するノードに要求がルーティングされます。
ゾーン間のデータ レプリケーション: データベース ファイルは、アクティブな SQL データベース エンジン プロセスが現在含まれているノードにアタッチされている ZRS を使用して、Azure Storageに格納されます。
書き込み操作は同期的であり、データがすべての可用性ゾーンに正常にレプリケートされるまでは完了とは見なされません。 この同期レプリケーションにより、ゾーン障害時の強力な一貫性とデータ損失がゼロになります。 ただし、ローカル冗長ストレージと比較して書き込み待機時間が若干長くなる可能性があります。
ゾーン間のトラフィック ルーティング: 通常の運用中、要求は SQL マネージド インスタンスのプライマリ レプリカにルーティングされます。
ゾーン間のデータ レプリケーション: プライマリ レプリカは、異なる可用性ゾーンにあるセカンダリ レプリカに変更を継続的かつ順番にプッシュします。 このプロセスにより、各トランザクションをコミットする前に、十分な数のセカンダリ レプリカにデータが保存されます。 これらのレプリカは異なる可用性ゾーンに配置されています。 このプロセスにより、プライマリ レプリカまたは読み取り可能なセカンダリ レプリカが何らかの理由で使用できなくなった場合でも、完全に同期されたレプリカが常にフェールオーバー用として使用できるようになります。
ゾーン冗長インスタンスは異なるデータセンターにレプリカを持ち、その間に距離があるため、ネットワーク待ち時間が長くなると、トランザクションのコミット時間が長くなる可能性があります。 この増加は、一部のオンライン トランザクション処理 (OLTP) ワークロードのパフォーマンスに影響する可能性があります。 ほとんどのアプリケーションは、この追加の待機時間の影響を受けません。
ゾーン障害時の動作
このセクションでは、SQL マネージド インスタンスがゾーン冗長として構成されていて、1 つ以上の可用性ゾーンが使用できない場合に想定される内容について説明します。
- Detection and response: SQL Managed Instance は、可用性ゾーンでの障害の検出と対応を担当します。 ゾーンのフェールオーバーを開始するために何もする必要はありません。
- 通知: ゾーンがダウンしても、Microsoft から自動的に通知されることはありません。 ただし、Azure Resource Health を使用して個々のリソースの正常性を監視したり、Resource Healthアラートを設定して問題を通知することができます。 また、Azure Service Health を使用して、ゾーンエラーを含むサービスの全体的な正常性を把握し、Service Health アラートを設定して問題を通知することもできます。
- アクティブな要求: 可用性ゾーンが使用不能になると、障害の発生した可用性ゾーン内で処理中の要求はすべて終了されるので、再試行する必要があります。 これらの種類の問題に対するアプリケーションの回復性を高める方法については、 一時的な障害に対する回復性に関するガイダンスを 参照してください。
Traffic rerouting: SQL Managed Instance は Service Fabric と連携して、データベース エンジンを別の可用性ゾーンにあり、十分な空き容量を持つ適切なステートレス コンピューティング ノードに移動します。 フェールオーバーが完了すると、新しい接続は新しいプライマリ計算ノードに自動的にリダイレクトされます。
負荷の高いワークロードでは、新しいデータベース エンジン プロセスがコールド キャッシュで開始されるため、1 つのコンピューティング ノードからもう一方のコンピューティング ノードへの移行中にパフォーマンスが低下する可能性があります。
- Traffic rerouting: SQL Managed Instance は Service Fabric と連携して、別の可用性ゾーン内の適切なレプリカを選択してプライマリ レプリカになります。 セカンダリ レプリカが新しいプライマリ レプリカになると、クォーラムを維持するのに十分な数のレプリカがクラスターに確保されるように、別のセカンダリ レプリカが作成されます。 フェールオーバーが完了すると、新しい接続は、接続文字列に基づいて、新しいプライマリ レプリカまたは読み取り可能なセカンダリ レプリカに自動的にリダイレクトされます。
予想されるダウンタイム: 可用性ゾーンのフェールオーバー中に、わずかなダウンタイムが発生する可能性があります。 ダウンタイムは通常 30 秒未満です。これは、 一時的な障害に対する回復性 のガイダンスに従う場合にアプリケーションが許容する必要があります。
予想されるデータ損失: 可用性ゾーンのフェールオーバー中にコミットされたトランザクションのデータ損失は予想されません。 進行中のトランザクションを再試行する必要があります。
ゾーンの回復
可用性ゾーンが復旧すると、SQL Managed Instanceは Service Fabric と連携して、復旧されたゾーンの操作を復元します。 お客様の介入は必要ありません。
ゾーンエラーのテスト
SQL Managed Instance プラットフォームは、ゾーン冗長インスタンスのトラフィック ルーティング、フェールオーバー、フェールバックを管理します。 この機能は完全に管理されているため、可用性ゾーンの障害プロセスを開始または検証する必要はありません。 ただし、 アプリケーションのエラー処理を検証できます。
リージョン全体の障害に対する回復性
個々のSQL Managed Instanceは、1 つのリージョン内にデプロイされます。 ただし、セカンダリ SQL マネージド インスタンスを別のAzure リージョンにデプロイし、failover グループを構成できます。
フェールオーバー グループ
フェールオーバー グループはデータを地理的に自動レプリケートし、フェールオーバー ポリシーに基づき、リージョンの障害が発生した場合は自動または手動でフェールオーバーできます。
このセクションでは、フェールオーバー グループに関する重要な情報をまとめますが、 フェールオーバー グループの概要とベスト プラクティス を確認して、そのしくみと構成方法の詳細を確認することが重要です。
フェールオーバー ポリシー
フェールオーバー グループを作成するときは、フェールオーバー ポリシーを選択します。ここで、障害を検出してフェールオーバーを実行する責任者を指定します。 次の 2 種類のフェールオーバー ポリシーを構成できます。
カスタマー マネージド フェールオーバー (推奨): カスタマー マネージド フェールオーバー ポリシーを使用する場合は、データ損失が発生しない フェールオーバーを実行するか、 強制フェールオーバーを実行するかを決定できます。この場合、データ損失が発生する可能性があります。 強制フェールオーバーは、プライマリ インスタンスにアクセスできない停止中の復旧方法として使用されます。
Microsoft マネージド フェールオーバー: Microsoft マネージド フェールオーバーは、強制フェールオーバーをトリガーする例外的な状況でのみ使用されます。
Important
カスタマー マネージド フェールオーバー オプションを使用して、DR プランを開発、テスト、実装します。 Microsoft マネージド フェールオーバーに頼らないでください。これが使われる可能性があるのは、極端な状況のみです。 Microsoft マネージド フェールオーバーは、リージョン全体に対して開始される可能性があります。 個々のフェールオーバー グループ、SQL マネージド インスタンス、サブスクリプション、またはお客様に対して開始することはできません。 フェールオーバーは、Azure サービスごとに異なる時間に発生する可能性があります。 カスタマーマネージド フェールオーバーを使うことをお勧めします。
Requirements
- Region support: フェールオーバー グループ内の SQL マネージド インスタンスの任意のAzure リージョンを選択できます。 ワイド エリア ネットワークの待機時間が長いため、geo レプリケーションでは非同期レプリケーション メカニズムが使用されます。 ネットワークの遅延を減らすには、接続の待機時間が短いリージョンを選択します。 Azure リージョン間の待機時間の詳細については、「Azureネットワークラウンドトリップ待機時間の統計情報を参照してください。
費用
異なるリージョンに複数の SQL マネージド インスタンスを作成すると、SQL マネージド インスタンスごとに課金されます。
ただし、セカンダリ インスタンスに読み取りワークロードやアプリケーションが接続されていない場合は、レプリカをスタンバイ インスタンスとして指定することでライセンス コストを節約できます。 詳細については、「
SQL Managed Instance の価格の詳細については、「サービスの価格情報」を参照してください。
複数リージョンのサポートを構成する
フェールオーバー グループを構成する方法については、「
容量の計画と管理
フェールオーバー中、トラフィックはセカンダリ SQL マネージド インスタンスにリダイレクトされます。 セカンダリ SQL マネージド インスタンスがトラフィックを受け入れ可能な状態であることが重要です。 プライマリ インスタンスと同じサービス レベル、ハードウェア世代、コンピューティング サイズを持つセカンダリ SQL マネージド インスタンスを作成します。
フェールオーバー グループ内の SQL マネージド インスタンスのスケーリングの詳細については、「インスタンスの スケーリング」を参照してください。
すべてのリージョンが正常な場合の動作
このセクションでは、複数リージョンのフェールオーバー グループを使用するように SQL マネージド インスタンスを構成し、すべてのリージョンが運用可能な場合に想定される内容について説明します。
リージョン間のトラフィック ルーティング: 通常の運用中、読み取り/書き込み要求はプライマリ リージョン内の 1 つのプライマリ インスタンスに送信されます。
フェールオーバー グループは、個別の読み取り専用リスナー エンドポイントも提供します。 通常の操作中、このエンドポイントはセカンダリ インスタンスに接続して、接続文字列で指定された読み取り専用トラフィックをルーティングします。
フェールオーバー グループが各インスタンスにトラフィックを送信する方法と、読み取り専用リスナー エンドポイントにトラフィックを送信する方法の詳細については、「 フェールオーバー グループの概要とベスト プラクティス」を参照してください。
リージョン間のデータ レプリケーション: 既定では、データはプライマリ インスタンスからセカンダリ SQL マネージド インスタンスに非同期的にレプリケートされます。
geo レプリケーションは非同期であるため、強制フェールオーバーを実行すると、データ損失が発生する可能性があります。 強制フェールオーバー中に発生する可能性のあるデータ損失を把握するために、レプリケーションの遅延を監視することができます。 詳細については、 DR チェックリストを参照してください。
フェールオーバー中の非同期レプリケーションによるデータ損失を排除する必要がある場合は、セカンダリ データベースのトランザクション ログで最後にコミットされたトランザクションが送信および強化されたことを確認するまで、呼び出し元のスレッドをブロックするようにアプリケーションを構成します。 この方法ではカスタム開発が必要であり、アプリケーションのパフォーマンスが低下します。 詳細については、「 重要なデータの損失を防ぐ」を参照してください。
リージョン障害時の動作
このセクションでは、SQL マネージド インスタンスが複数リージョンのフェールオーバー グループを使用するように構成されていて、プライマリ リージョンで障害が発生した場合に想定される内容について説明します。
検出と応答: 検出と応答の責任は、フェールオーバー グループが使用するフェールオーバー ポリシーによって異なります。
お客様管理のフェールオーバー ポリシー: リージョン内の障害を検出し、フェールオーバー グループ内のセカンダリ インスタンスへのフェールオーバーまたは強制フェールオーバーをトリガーするのはお客様の責任です。
フェールオーバーを実行する場合、SQL Managed Instanceはデータがセカンダリ インスタンスに同期されるまで待機してから、フェールオーバー手順を実行します。
強制フェールオーバーを実行する場合、SQL Managed Instanceは、最近の変更がプライマリから反映されるのを待たずに、セカンダリ インスタンスをすぐにプライマリ ロールに切り替えます。 この種のフェールオーバーではデータ損失が発生する可能性があります。
Microsoft 管理のフェールオーバー ポリシー: Microsoft 管理のフェールオーバーは、例外的な状況下で実行されます。 Microsoft がフェールオーバーをトリガーすると、フェールオーバー グループにより、フェールオーバー グループ内のセカンダリ インスタンスへの強制フェールオーバーが自動実行されます。 ただし、フェールオーバーが発生するタイミングを制御できるように、運用ワークロードにはカスタマー マネージド フェールオーバー ポリシーを使用することをお勧めします。
- 通知: ゾーンがダウンしても、Microsoft から自動的に通知されることはありません。 ただし、Azure Resource Health を使用して個々のリソースの正常性を監視したり、Resource Healthアラートを設定して問題を通知することができます。 また、Azure Service Health を使用して、ゾーンエラーを含むサービスの全体的な正常性を把握し、Service Health アラートを設定して問題を通知することもできます。
アクティブな要求: フェールオーバーが発生すると、処理中のすべての要求が終了し、再試行する必要があります。 これらの種類の問題に対するアプリケーションの回復性を高める方法については、「 一時的な障害に対する回復性」を参照してください。
予想されるデータ損失: データ損失の量は、アプリケーションの構成方法によって異なります。 詳細については、「 フェールオーバー グループの概要とベスト プラクティス」を参照してください。
予想されるダウンタイム: フェールオーバー グループのフェールオーバー中に、少しのダウンタイムが発生する可能性があります。 通常、ダウンタイムは 60 秒未満です。
トラフィックの再ルーティング: フェールオーバー グループがフェールオーバー プロセスを完了すると、読み取り/書き込みトラフィックが新しいプライマリ インスタンスに自動的にルーティングされます。 接続文字列にフェールオーバー グループのエンドポイントを使用しているアプリケーションの場合、フェールオーバー後に接続文字列を変更する必要はありません。
リージョンの復旧
フェールオーバー グループは、復元時にプライマリ リージョンに自動的にフェールバックされないため、お客様がフェールバックを開始する必要があります。
カスタマー マネージド フェールオーバー グループの場合は、プライマリ リージョンの復元時にフェールバックを開始できます。 Microsoft が管理するフェールオーバー グループの場合、フェールバック プロセスは自動的に行われます。 詳細については、「 プライマリ リージョンへのフェールバック」を参照してください。
リージョン障害のテスト
フェールオーバー グループのフェールオーバーをテストできます。
フェールオーバー グループのテストは、DR ドリルの実行の 1 つの部分にすぎません。 詳細については、「 DR ドリルの実行」を参照してください。
バックアップと復元
データの損失など、さまざまなリスクから保護するために、データベースのバックアップを作成します。 バックアップは、偶発的なデータ損失、破損、またはその他の問題から復旧するために復元できます。 バックアップは geo レプリケーションと同じではなく、目的が異なり、さまざまなリスクが軽減されます。
SQL Managed Instanceは、データベースの完全バックアップ、差分バックアップ、トランザクション ログ バックアップを自動的に取得します。 バックアップの種類、頻度、復元機能、ストレージ コスト、バックアップ暗号化の詳細については、「
SQL Managed Instanceは、組み込みの自動バックアップを提供し、ユーザー データベースのユーザーが開始するコピーのみのバックアップもサポートします。 詳細については、「コピーのみのバックアップ」を参照してください。
バックアップのレプリケーション
SQL マネージド インスタンスの自動バックアップを構成するときに、バックアップをレプリケートする方法を指定できます。 ZRS に格納するように構成されているバックアップの回復性は高くなります。 次のいずれかのストレージの種類を使用するようにバックアップを構成することをお勧めします。
リージョンに可用性ゾーンがある場合、ZRS は地域内の回復性を確保します
リージョンに可用性ゾーンがあり、別のリージョンとペアになっている場合に、リージョン間のバックアップの回復性を向上させる GZRS
可用性ゾーンをサポートしていないが、ペアリージョンが存在するあなたのリージョンの場合は、GRS を使用してください。
さまざまなストレージの種類とその機能の詳細については、「 バックアップ ストレージの冗長性」を参照してください。
geo リストア
geo リストア機能は、バックアップ コピーを別のAzure リージョンに復元できる基本的な DR ソリューションです。 通常、geo バックアップにはかなりのダウンタイムとデータ損失が発生します。 リージョンの中断が発生した場合に高いレベルの回復性を実現するには、 フェールオーバー グループを構成する必要があります。
geo-restore を使用する場合は、セカンダリリージョンでバックアップを利用可能にする方法を検討する必要があります。
プライマリ リージョンがペアになっている場合は、ペアになっているリージョンへの geo リストアをサポートするために、GZRS または GRS バックアップ ストレージを使用します。
プライマリ リージョンがペアになっていない場合は、カスタム ソリューションを構築してバックアップを別のリージョンにレプリケートできます。 ユーザー開始のコピーのみのバックアップを使用してストレージ アカウントに保存し、BLOB オブジェクトのレプリケーションを使用して別のリージョンのストレージ アカウントにレプリケートすることを検討してください。
サービス メンテナンスに対する回復性
SQL Managed Instanceがインスタンスのメンテナンスを実行すると、SQL managed instanceは完全に使用可能なままになりますが、短い再構成の対象になる可能性があります。 メンテナンス イベントが発生すると、クライアント アプリケーションで短時間の接続中断が発生する場合があります。 クライアント アプリケーションは、影響を最小限 に抑えるために、一時的な障害に対する回復性 のガイダンスに従う必要があります。
SQL Managed Instanceを使用すると、サービスのアップグレードやその他のメンテナンス操作に一般的に使用されるメンテナンス期間を指定できます。 メンテナンス期間を構成すると、営業時間内の自動フェールオーバーなどの副作用を最小限に抑えることができます。 計画メンテナンスの事前通知を受け取ることもできます。
詳細については、SQL Managed InstanceMaintenance ウィンドウ>を参照してください。
サービス水準合意書
Azure サービスのサービス レベル アグリーメント (SLA) では、各サービスの予想される可用性と、その可用性の期待を達成するためにソリューションが満たす必要がある条件について説明します。 詳細については、オンラインサービスのSLAを参照してください。
SQL Managed Instanceの場合、可用性 SLA は、管理トラフィックを妨げないように、Azure仮想ネットワークが正しく構成されている場合にのみ適用されます。 この構成には、サブネット サイズ、ネットワーク セキュリティ グループ (NSG)、ユーザー定義ルート (UDR)、DNS 構成、ネットワーク リソースの管理と使用に影響するその他のリソースが含まれます。 SQL Managed Instanceに必要なネットワーク構成の詳細については、「Network の要件>」を参照してください。
関連コンテンツ
SQL Managed Instance - 高可用性とディザスター リカバリー チェックリスト
- Azure での信頼性