Azure SQL Database と SQL Managed Instance の高可用性High availability for Azure SQL Database and SQL Managed Instance

適用対象: Azure SQL Database Azure SQL Managed Instance

Azure SQL Database と SQL Managed Instance での高可用性アーキテクチャの目的は、メンテナンス操作や障害の影響を心配せずに、データベースの稼働および実行の時間が 99.99% 以上になるように保証することです (さまざまなレベルに固有の SLA の詳細については、Azure SQL Database と SQL Managed Instance の SLA に関するページを参照してください)。The goal of the high availability architecture in Azure SQL Database and SQL Managed Instance is to guarantee that your database is up and running minimum of 99.99% of time (For more information regarding specific SLA for different tiers, Please refer SLA for Azure SQL Database and SQL Managed Instance), without worrying about the impact of maintenance operations and outages. Azure では、パッチ適用、バックアップ、Windows および Azure SQL のアップグレードなどの重要なサービス タスクに加えて、基本となるハードウェア、ソフトウェア、またはネットワークのエラーなどの計画外のイベントを自動的に処理します。Azure automatically handles critical servicing tasks, such as patching, backups, Windows and Azure SQL upgrades, as well as unplanned events such as underlying hardware, software, or network failures. Azure SQL Database の基本となるデータベースがパッチを適用されるか、またはフェールオーバーした場合、お使いのアプリで再試行ロジックを使用していれば、ダウンタイムは認識されません。When the underlying database in Azure SQL Database is patched or fails over, the downtime is not noticeable if you employ retry logic in your app. SQL Database と SQL Managed Instance は、クリティカルな状況であっても迅速な復旧が可能であるため、データが常に使用可能であることが保証されます。SQL Database and SQL Managed Instance can quickly recover even in the most critical circumstances ensuring that your data is always available.

高可用性ソリューションは、コミットされたデータが障害によって失われないこと、メンテナンス操作がワークロードに影響を及ぼさないこと、また、データベースがソフトウェア アーキテクチャでの単一障害点にならないことを保証するように設計されています。The high availability solution is designed to ensure that committed data is never lost due to failures, that maintenance operations do not affect your workload, and that the database will not be a single point of failure in your software architecture. データベースのアップグレードやメンテナンスを行うときでも、ワークロードの停止が必要なメンテナンス期間やダウンタイムは発生しません。There are no maintenance windows or downtimes that should require you to stop the workload while the database is upgraded or maintained.

高可用性アーキテクチャ モデルには、次の 2 つがあります。There are two high availability architectural models:

  • 計算とストレージの分離に基づく Standard 可用性モデルStandard availability model that is based on a separation of compute and storage. リモート ストレージ層の高可用性と信頼性に依存します。It relies on high availability and reliability of the remote storage tier. このアーキテクチャでは、メンテナンス作業中に一定のパフォーマンス低下を許容できる予算重視のビジネス アプリケーションを対象とします。This architecture targets budget-oriented business applications that can tolerate some performance degradation during maintenance activities.
  • データベース エンジン プロセスのクラスターに基づく Premium 可用性モデルPremium availability model that is based on a cluster of database engine processes. 利用可能なデータベース エンジン ノードのクォーラムが常にあるという事実に依存します。It relies on the fact that there is always a quorum of available database engine nodes. このアーキテクチャでは、高い IO パフォーマンス、高いトランザクション レートを備えたミッション クリティカル なアプリケーションを対象とし、メンテナンス作業中のワークロードに対するパフォーマンスの影響を最小限に抑えることを保証します。This architecture targets mission critical applications with high IO performance, high transaction rate and guarantees minimal performance impact to your workload during maintenance activities.

SQL Database と SQL Managed Instance は、どちらも最新の安定したバージョンの SQL Server データベース エンジンおよび Windows オペレーティング システム上で実行されています。また、ほとんどのユーザーが認識することなく、アップグレードが継続的に実行されています。SQL Database and SQL Managed Instance both run on the latest stable version of the SQL Server database engine and Windows operating system, and most users would not notice that upgrades are performed continuously.

Basic、Standard、および General Purpose サービス レベルのローカル冗長可用性Basic, Standard, and General Purpose service tier locally redundant availability

Basic、Standard、および General Purpose サービス レベルでは、サーバーレス コンピューティングとプロビジョニングされたコンピューティングの両方で、標準の可用性アーキテクチャを利用します。The Basic, Standard, and General Purpose service tiers leverage the standard availability architecture for both serverless and provisioned compute. 次の図は、計算レイヤーとストレージ レイヤーが分離されている4 つの異なるノードを示しています。The following figure shows four different nodes with the separated compute and storage layers.

計算とストレージの分離

Standard 可用性モデルには、次の 2 つのレイヤーがあります。The standard availability model includes two layers:

  • ステートレス計算レイヤー。sqlservr.exe プロセスを実行しており、一時的なデータとキャッシュ データのみ (TempDB、アタッチされた SSD 上のモデル データベース、およびメモリ内のプラン キャッシュ、バッファー プール、列ストア プールなど) が含まれています。A stateless compute layer that runs the sqlservr.exe process and contains only transient and cached data, such as TempDB, model databases on the attached SSD, and plan cache, buffer pool, and columnstore pool in memory. このステートレス ノードは、sqlservr.exe の初期化、ノードの正常性の制御、および他のノードへのフェールオーバーを必要に応じて実行する Azure Service Fabric によって操作されます。This stateless node is operated by Azure Service Fabric that initializes sqlservr.exe, controls health of the node, and performs failover to another node if necessary.
  • ステートフル データ レイヤー。データベース ファイル (.mdf/.ldf) は Azure BLOB ストレージに保存されています。A stateful data layer with the database files (.mdf/.ldf) that are stored in Azure Blob storage. Azure BLOB ストレージには、組み込みのデータ可用性と冗長性の機能があります。Azure blob storage has built-in data availability and redundancy feature. sqlservr.exe プロセスがクラッシュした場合でも、ログ ファイル内のすべてのレコードまたはデータ ファイル内のすべてのページが保持されることを保証します。It guarantees that every record in the log file or page in the data file will be preserved even if sqlservr.exe process crashes.

データベース エンジンまたはオペレーティング システムがアップグレードされた場合、あるいは障害が検出された場合、Azure Service Fabric は常に、ステートレス sqlservr.exe プロセスを十分な空き容量がある別のステートレス計算ノードに移行します。Whenever the database engine or the operating system is upgraded, or a failure is detected, Azure Service Fabric will move the stateless sqlservr.exe process to another stateless compute node with sufficient free capacity. Azure BLOB ストレージ内のデータは移行による影響を受けず、データ/ログ ファイルは、新しく初期化された sqlservr.exe プロセスにアタッチされます。Data in Azure Blob storage is not affected by the move, and the data/log files are attached to the newly initialized sqlservr.exe process. このプロセスでは 99.99% の可用性が保証されますが、新しい sqlservr.exe プロセスがコールド キャッシュを使用して起動されるため、負荷の高いワークロードによって移行中にパフォーマンスの低下が発生する可能性があります。This process guarantees 99.99% availability, but a heavy workload may experience some performance degradation during the transition since the new sqlservr.exe process starts with cold cache.

General Purpose サービス レベルのゾーン冗長可用性 (プレビュー)General Purpose service tier zone redundant availability (Preview)

General Purpose サービス レベルのゾーン冗長構成では、Azure Availability Zones  を利用して、Azure リージョン内の複数の物理的な場所にデータベースをレプリケートします。Zone redundant configuration for the general purpose service tier utilizes Azure Availability Zones  to replicate databases across multiple physical locations within an Azure region. ゾーン冗長を選択することで、アプリケーション ロジックを変更することなく、データセンターの壊滅的な障害を含む、大規模な障害から新規および既存の汎用単一データベースやエラスティック プールを回復できるようになります。 By selecting zone redundancy, you can make your new and existing general purpose single databases and elastic pools resilient to a much larger set of failures, including catastrophic datacenter outages, without any changes of the application logic.

General Purpose レベル向けのゾーン冗長構成には、次の 2 つの層があります。Zone redundant configuration for the general purpose tier has two layers:

  • ステートフル データ レイヤー。データベース ファイル (.mdf/.ldf) は ZRS PFS (ゾーン冗長ストレージ Premium ファイル共有) に保存されています。A stateful data layer with the database files (.mdf/.ldf) that are stored in ZRS PFS (zone-redundant storage premium file share. ゾーン冗長ストレージを使用すると、データとログ ファイルは、物理的に分離された 3 つの Azure 可用性ゾーン間で同期的にコピーされます。Using zone-redundant storage the data and log files are synchronously copied across three physically-isolated Azure availability zones.
  • ステートレス コンピューティング レイヤー。sqlservr.exe プロセスを実行しており、一時的なデータとキャッシュ データのみ (TempDB、アタッチされた SSD 上のモデル データベース、およびメモリ内のプラン キャッシュ、バッファー プール、列ストア プールなど) が含まれています。A stateless compute layer that runs the sqlservr.exe process and contains only transient and cached data, such as TempDB, model databases on the attached SSD, and plan cache, buffer pool, and columnstore pool in memory. このステートレス ノードは、sqlservr.exe の初期化、ノードの正常性の制御、および他のノードへのフェールオーバーを必要に応じて実行する Azure Service Fabric によって操作されます。This stateless node is operated by Azure Service Fabric that initializes sqlservr.exe, controls health of the node, and performs failover to another node if necessary. ゾーン冗長 General Purpose データベースの場合、予備の容量があるノードをフェールオーバーのために他の Availability Zones ですぐに使用できます。For zone redundant general purpose databases, nodes with spare capacity are readily available in other Availability Zones for failover.

ゾーン冗長による General Purpose サービス レベル向けの高可用性アーキテクチャを、次の図に示します。The zone redundant version of the high availability architecture for the general purpose service tier is illustrated by the following diagram:

General Purpose 向けのゾーン冗長構成

重要

ゾーン冗長データベースがサポートされているリージョンの最新情報については、「リージョン別のサービスのサポート」を参照してください。For up to date information about the regions that support zone redundant databases, see Services support by region. ゾーン冗長構成は Gen5 コンピューティング ハードウェアが選択されている場合のみ利用できます。Zone redundant configuration is only available when the Gen5 compute hardware is selected. この機能は、SQL Managed Instance では使用できません。This feature is not available in SQL Managed Instance.

注意

80 個の仮想コアを備えたサイズの General Purpose データベースでは、ゾーン冗長構成によるパフォーマンスの低下が発生する可能性があります。General Purpose databases with a size of 80 vcore may experience performance degradation with zone redundant configuration. また、バックアップ、復元、データベース コピー、Geo DR のリレーションシップの設定などの操作では、1 TB を超える単一データベースのパフォーマンスが低下する可能性があります。Additionally, operations such as backup, restore, database copy, and setting up Geo-DR relationships may experience slower performance for any single databases larger than 1 TB.

Premium および Business Critical サービス レベルのローカル冗長可用性Premium and Business Critical service tier locally redundant availability

Premium および Business Critical サービス レベルでは、Premium 可用性モデルを利用します。1 つのノード上で、計算リソース (sqlservr.exe プロセス) とストレージ (ローカルに接続されている SSD) を統合します。Premium and Business Critical service tiers leverage the Premium availability model, which integrates compute resources (sqlservr.exe process) and storage (locally attached SSD) on a single node. 高可用性は、3 から 4 つのノードでクラスターを形成している追加ノードに計算とストレージの両方をレプリケートすることで、実現されます。High availability is achieved by replicating both compute and storage to additional nodes creating a three to four-node cluster.

データベース エンジン ノードのクラスター

基になるデータベース ファイル (.mdf/.ldf) は、非常に低い待機時間の IO をワークロードに提供するために、アタッチされている SSD ストレージ上に配置されています。The underlying database files (.mdf/.ldf) are placed on the attached SSD storage to provide very low latency IO to your workload. 高可用性は、SQL Server Always On 可用性グループと同様のテクノロジを使用して実装されます。High availability is implemented using a technology similar to SQL Server Always On availability groups. クラスターには、読み取り/書き込みの顧客ワークロードにアクセス可能な単一のプライマリ レプリカと、データのコピーを格納する最大 3 つのセカンダリ レプリカ (計算とストレージ) が含まれます。The cluster includes a single primary replica that is accessible for read-write customer workloads, and up to three secondary replicas (compute and storage) containing copies of data. プライマリ ノードは常にセカンダリ ノードへ順番に変更をプッシュし、各トランザクションをコミットする前に少なくとも 1 つのセカンダリ レプリカにデータが同期されるようにします。The primary node constantly pushes changes to the secondary nodes in order and ensures that the data is synchronized to at least one secondary replica before committing each transaction. このプロセスによって、何らかの理由でプライマリ ノードがクラッシュした場合に、フェールオーバー先となる完全に同期されたノードが常に用意されている状態が保証されます。This process guarantees that if the primary node crashes for any reason, there is always a fully synchronized node to fail over to. フェールオーバーは、Azure Service Fabric によって開始されます。The failover is initiated by the Azure Service Fabric. セカンダリ レプリカが新しいプライマリ ノードになると、もう 1 つのセカンダリ レプリカが作成され、クラスターに十分な数のノード (クォーラム セット) がある状態が保証されます。Once the secondary replica becomes the new primary node, another secondary replica is created to ensure the cluster has enough nodes (quorum set). フェールオーバーが完了すると、Azure SQL 接続は新しいプライマリ ノードに自動的にリダイレクトされます。Once failover is complete, Azure SQL connections are automatically redirected to the new primary node.

その他の利点としては、Premium 可用性モデルには、セカンダリ レプリカの 1 つに読み取り専用の Azure SQL 接続をリダイレクトする機能が含まれています。As an extra benefit, the premium availability model includes the ability to redirect read-only Azure SQL connections to one of the secondary replicas. この機能は、読み取りスケールアウトと呼ばれます。追加料金なしで 100% の追加のコンピューティング容量を提供し、分析ワークロードなどの読み取り専用の操作をプライマリ レプリカからオフロードします。This feature is called Read Scale-Out. It provides 100% additional compute capacity at no extra charge to off-load read-only operations, such as analytical workloads, from the primary replica.

Premium および Business Critical サービス レベルのゾーン冗長可用性Premium and Business Critical service tier zone redundant availability

既定では、Premium 可用性モデル用のノードのクラスターは、同じデータ センター内に作成されます。By default, the cluster of nodes for the premium availability model is created in the same datacenter. Azure Availability Zones の導入によって、SQL Database では同じリージョン内のさまざまな可用性ゾーンに対する Business Critical データベースのさまざまなレプリカを配置できます。With the introduction of Azure Availability Zones, SQL Database can place different replicas of the Business Critical database to different availability zones in the same region. 単一障害点をなくすため、制御リングも複数のゾーンで 3 つのゲートウェイ リング (GW) として複製できます。To eliminate a single point of failure, the control ring is also duplicated across multiple zones as three gateway rings (GW). 特定のゲートウェイ リングへのルーティングは Azure Traffic Manager (ATM) によって制御されます。The routing to a specific gateway ring is controlled by Azure Traffic Manager (ATM). Premium または Business Critical サービス レベルでのゾーン冗長構成では、追加のデータベース冗長性を作成しないため、追加料金なしで使用できます。Because the zone redundant configuration in the Premium or Business Critical service tiers does not create additional database redundancy, you can enable it at no extra cost. ゾーン冗長構成を選択することで、アプリケーション ロジックにまったく変更を加えずに、データセンターの壊滅的な障害などの極めて大規模な障害に対して、Premium または Business Critical データベースが回復性を備えることができます。By selecting a zone redundant configuration, you can make your Premium or Business Critical databases resilient to a much larger set of failures, including catastrophic datacenter outages, without any changes to the application logic. また、既存の Premium または Business Critical データベース、あるいはプールをゾーン冗長構成に変換することもできます。You can also convert any existing Premium or Business Critical databases or pools to the zone redundant configuration.

ゾーン冗長データベースでは、離れた距離に位置するさまざまなデータセンターにレプリカがあるため、ネットワーク待機時間が長くなるとコミット時間が増大し、一部の OLTP ワークロードのパフォーマンスに影響を及ぼす可能性があります。Because the zone redundant databases have replicas in different datacenters with some distance between them, the increased network latency may increase the commit time and thus impact the performance of some OLTP workloads. いつでもゾーン冗長設定を無効にして単一ゾーン構成に戻ることができます。You can always return to the single-zone configuration by disabling the zone redundancy setting. このプロセスはオンライン操作であり、通常のサービス レベル更新プログラムと似ています。This process is an online operation similar to the regular service tier upgrade. プロセスの最後に、データベースまたはプールがゾーン冗長リングから単一ゾーン リングに (または逆方向に) 移行されます。At the end of the process, the database or pool is migrated from a zone redundant ring to a single zone ring or vice versa.

重要

Business Critical レベルを使用している場合、ゾーン冗長構成は Gen5 コンピューティング ハードウェアが選択されている場合のみ利用できます。When using the Business Critical tier, zone redundant configuration is only available when the Gen5 compute hardware is selected. ゾーン冗長データベースがサポートされているリージョンの最新情報については、「リージョン別のサービスのサポート」を参照してください。For up to date information about the regions that support zone redundant databases, see Services support by region.

注意

この機能は、SQL Managed Instance では使用できません。This feature is not available in SQL Managed Instance.

ゾーン冗長による高可用性アーキテクチャを、次の図に示します。The zone redundant version of the high availability architecture is illustrated by the following diagram:

高可用性アーキテクチャのゾーン冗長

Hyperscale サービス レベルの可用性Hyperscale service tier availability

ハイパースケール サービス レベルのアーキテクチャは「分散機能アーキテクチャ」で説明されており、現在は SQL Managed Instance ではなく SQL Database でのみ使用できます。The Hyperscale service tier architecture is described in Distributed functions architecture and is only currently available for SQL Database, not SQL Managed Instance.

Hyperscale 機能のアーキテクチャ

Hyperscale の可用性モデルには、次の 4 つのレイヤーが含まれます。The availability model in Hyperscale includes four layers:

  • ステートレス計算レイヤー。sqlservr.exe プロセスを実行しており、一時的なデータとキャッシュ データのみ (カバーしない RBPEX キャッシュ、TempDB、アタッチされた SSD 上のモデル データベースなど、およびメモリ内のプラン キャッシュ、バッファー プール、列ストア プールなど) が含まれています。A stateless compute layer that runs the sqlservr.exe processes and contains only transient and cached data, such as non-covering RBPEX cache, TempDB, model database, etc. on the attached SSD, and plan cache, buffer pool, and columnstore pool in memory. このステートレス レイヤーには、プライマリ計算レプリカと、必要に応じて、フェールオーバー ターゲットとして機能できる多くのセカンダリ計算レプリカが含まれています。This stateless layer includes the primary compute replica and optionally a number of secondary compute replicas that can serve as failover targets.
  • ページ サーバーによって形成されるステートレス ストレージ レイヤー。A stateless storage layer formed by page servers. このレイヤーは、計算レプリカで実行されている sqlservr.exe プロセス用の分散ストレージ エンジンです。This layer is the distributed storage engine for the sqlservr.exe processes running on the compute replicas. 各ページ サーバーには、アタッチされた SSD 上のカバーする RBPEX キャッシュ、メモリにキャッシュされたデータ ページなど、一時的なデータとキャッシュされたデータのみが含まれます。Each page server contains only transient and cached data, such as covering RBPEX cache on the attached SSD, and data pages cached in memory. 各ページ サーバーでは、負荷分散、冗長性、高可用性を提供するためのアクティブ/アクティブ構成にペアのページ サーバーがあります。Each page server has a paired page server in an active-active configuration to provide load balancing, redundancy, and high availability.
  • ステートフルなトランザクション ログのストレージ レイヤー。ログ サービス プロセス、トランザクション ログのランディング ゾーン、およびトランザクション ログの長期保存を実行する計算ノードによって形成されます。A stateful transaction log storage layer formed by the compute node running the Log service process, the transaction log landing zone, and transaction log long term storage. ランディング ゾーンと長期保存では Azure Storage を使用します。これにより、トランザクション ログの可用性と冗長性が提供され、コミットされたトランザクションのデータの持続性が確保されます。Landing zone and long term storage use Azure Storage, which provides availability and redundancy for transaction log, ensuring data durability for committed transactions.
  • ステートフルなデータ ストレージ レイヤー。Azure Storage に格納され、ページ サーバーによって更新される、データベース ファイル (.mdf/.ndf) が含まれます。A stateful data storage layer with the database files (.mdf/.ndf) that are stored in Azure Storage and are updated by page servers. このレイヤーでは、Azure Storage のデータの可用性と冗長性の機能を使用します。This layer uses data availability and redundancy features of Azure Storage. これにより、Hyperscale アーキテクチャの他のレイヤーのプロセスがクラッシュした場合や、計算ノードで障害が発生した場合でも、データ ファイル内のすべてのページが保持されることが保証されます。It guarantees that every page in a data file will be preserved even if processes in other layers of Hyperscale architecture crash, or if compute nodes fail.

すべての Hyperscale レイヤー内の計算ノードは、Azure Service Fabric で実行されます。これにより、各ノードの正常性が制御され、必要に応じて使用できる正常なノードへのフェールオーバーが行われます。Compute nodes in all Hyperscale layers run on Azure Service Fabric, which controls health of each node and performs failovers to available healthy nodes as necessary.

Hyperscale の高可用性の詳細については、「ハイパースケールでのデータベースの高可用性」を参照してください。For more information on high availability in Hyperscale, see Database High Availability in Hyperscale.

高速データベース復旧 (ADR)Accelerated Database Recovery (ADR)

高速データベース復旧 (ADR) は、特に実行時間の長いトランザクションがある場合に、データベースの可用性を大幅に向上させる、新しいデータベース エンジン機能です。Accelerated Database Recovery (ADR) is a new database engine feature that greatly improves database availability, especially in the presence of long running transactions. ADR は、現時点では Azure SQL Database、Azure SQL Managed Instance、および Azure Synapse Analytics (旧称 SQL Data Warehouse) で使用できます。ADR is currently available for Azure SQL Database, Azure SQL Managed Instance, and Azure Synapse Analytics (formerly SQL Data Warehouse).

アプリケーションの障害回復性のテストTesting application fault resiliency

高可用性は、データベース アプリケーションに対して透過的に機能する SQL Database と SQL Managed Instance のプラットフォームの基礎となる部分です。High availability is a fundamental part of the SQL Database and SQL Managed Instance platform that works transparently for your database application. しかし、計画済みまたは計画外のイベント時に開始された自動フェールオーバー操作がアプリケーションに与える影響をテストしてから、運用環境にデプロイする必要があると Microsoft は認識しています。However, we recognize that you may want to test how the automatic failover operations initiated during planned or unplanned events would impact an application before you deploy it to production. 特別な API を呼び出してデータベース、エラスティック プール、またはマネージド インスタンスを再起動することにより、手動でフェールオーバーをトリガーできます。You can manually trigger a failover by calling a special API to restart a database, an elastic pool, or a managed instance. ゾーン冗長データベースまたはエラスティック プールの場合、API 呼び出しによって、クライアント接続が、古いプライマリの可用性ゾーンとは異なる可用性ゾーン内の新しいプライマリにリダイレクトされます。In the case of a zone redundant database or elastic pool, the API call would result in redirecting client connections to the new primary in an Availability Zone different from the Availability Zone of the old primary. そのため、フェールオーバーが既存のデータベース セッションにどのように影響するかをテストするだけでなく、ネットワーク待機時間の変化によってエンドツーエンドのパフォーマンスを変化させるかどうかを確認することもできます。So in addition to testing how failover impacts existing database sessions, you can also verify if it changes the end-to-end performance due to changes in network latency. 再起動操作が影響を及ぼし、その多くがプラットフォームに負荷をかける可能性があるため、各データベース、エラスティック プール、またはマネージド インスタンスに対しては、15 分ごとに 1 つのフェールオーバー呼び出しのみが許可されます。Because the restart operation is intrusive and a large number of them could stress the platform, only one failover call is allowed every 15 minutes for each database, elastic pool, or managed instance.

フェールオーバーは、PowerShell、REST API または Azure CLI を使用して開始できます。A failover can be initiated using PowerShell, REST API, or Azure CLI:

デプロイの種類Deployment type PowerShellPowerShell REST APIREST API Azure CLIAzure CLI
データベースDatabase Invoke-AzSqlDatabaseFailoverInvoke-AzSqlDatabaseFailover データベース フェールオーバーDatabase failover Azure CLI から REST API 呼び出しを呼び出すために az rest が使用できますaz rest may be used to invoke a REST API call from Azure CLI
エラスティック プールElastic pool Invoke-AzSqlElasticPoolFailoverInvoke-AzSqlElasticPoolFailover エラスティック プールのフェールオーバーElastic pool failover Azure CLI から REST API 呼び出しを呼び出すために az rest が使用できますaz rest may be used to invoke a REST API call from Azure CLI
マネージド インスタンスManaged Instance Invoke-AzSqlInstanceFailoverInvoke-AzSqlInstanceFailover マネージド インスタンス - フェールオーバーManaged Instances - Failover az sql mi failoveraz sql mi failover

重要

フェールオーバー コマンドは、ハイパースケール データベースの読み取り可能なセカンダリ レプリカでは使用できません。The Failover command is not available for readable secondary replicas of Hyperscale databases.

まとめConclusion

Azure SQL Database と Azure SQL Managed Instance の特徴は、Azure プラットフォームと緊密に統合される、組み込みの高可用性ソリューションです。Azure SQL Database and Azure SQL Managed Instance feature a built-in high availability solution, that is deeply integrated with the Azure platform. これは、障害の検出と復旧に Service Fabric を、データ保護に Azure BLOB ストレージを、フォールト トレランスを高めるために Availability Zones を活用しています (ドキュメントの冒頭に記載のあるとおり、これは Azure SQL Managed Instance には適用されません)。It is dependent on Service Fabric for failure detection and recovery, on Azure Blob storage for data protection, and on Availability Zones for higher fault tolerance (as mentioned earlier in document not applicable to Azure SQL Managed Instance yet). さらに、SQL Database と SQL Managed Instance では、レプリケーションとフェールオーバーのために、SQL Server インスタンスから Always On 可用性グループのテクノロジを活用しています。In addition, SQL Database and SQL Managed Instance leverage the Always On availability group technology from the SQL Server instance for replication and failover. これらのテクノロジを組み合わせることで、アプリケーションでは混合ストレージ モデルを最大限に活用して、高要件の SLA にも対応できます。The combination of these technologies enables applications to fully realize the benefits of a mixed storage model and support the most demanding SLAs.

次のステップNext steps