Azure SQL Managed Instance のフェールオーバー グループを構成する

適用対象:Azure SQL Managed Instance

• Azure SQL Database
• Azure SQL Managed Instance

この記事では、Azure portal と Azure PowerShell を使用して、Azure SQL Managed Instance のフェールオーバー グループを構成する方法について説明します。

フェールオーバー グループ内に両方のインスタンスを作成するエンド ツー エンドの PowerShell スクリプトについては、「フェールオーバー グループにインスタンスを追加する」を参照してください。

前提条件

次の前提条件を考慮してください。

• セカンダリ マネージド インスタンスは空である、つまりユーザー データベースを含んでいない必要があります。
• SQL Managed Instance の 2 つのインスタンスは同じサービス レベルである必要があり、ストレージ サイズも同じである必要があります。 必須ではありませんが、セカンダリ インスタンスがプライマリ インスタンスからレプリケートされる変更を持続して処理できるように (ピーク アクティビティの期間を含む)、2 つのインスタンスのコンピューティング サイズを等しくすることを強くお勧めします。
• プライマリ インスタンスの仮想ネットワークの IPアドレス範囲 は、作成する予定のセカンダリ マネージド インスタンスの仮想ネットワークのアドレス範囲、およびプライマリまたはセカンダリ仮想ネットワークとピアリングされたその他の仮想ネットワークと重複してはなりません。
• セカンダリ マネージド インスタンスを作成するときは、DnsZonePartner パラメーターの値としてプライマリ インスタンスの DNS ゾーン ID を指定する必要があります。 DnsZonePartnerに値を指定しない場合、ゾーンIDは各仮想ネットワークで最初のインスタンスが作成されるときにランダムな文字列として生成され、同じサブネット内の他のすべてのインスタンスに同じIDが割り当てられます。 一度割り当てられると、DNS ゾーンは変更できません。
• サブネット ホスティング インスタンス上のネットワーク セキュリティ グループ (NSG) 規則には、他のマネージド インスタンスをホストするサブネットとの間で受信と送信の接続が可能なポート 5022 (TCP) とポート範囲 11000-11999 (TCP) が開いている必要があります。 これは、プライマリとセカンダリのインスタンスをホストする両方のサブネットに適用されます。
• セカンダリのマネージド インスタンスの照合順序とタイムゾーンは、プライマリのマネージド インスタンスと一致している必要があります。
• パフォーマンス上の理由から、マネージド インスタンスはペアのリージョンにデプロイする必要があります。 geo ペア リージョンに存在するマネージド インスタンスは、ペアになっていないリージョンと比較して、geo レプリケーション速度が大幅に向上します。

アドレス空間の範囲

プライマリ インスタンスのアドレス空間をチェックするには、プライマリ インスタンスの仮想ネットワーク リソースに移動し、設定の [アドレス空間] を選択します。 [アドレス範囲] の範囲を確認します。

プライマリ インスタンスのゾーン ID を指定する

セカンダリ インスタンスを作成するときは、プライマリ DnsZonePartnerインスタンスのゾーン ID を .

ポータル

Azure portal でセカンダリ インスタンスを作成する場合は、[追加の設定]] タブの [geo レプリケーション] で、[はい] を選択して[フェールオーバー セカンダリ]として使用し、ドロップダウンからプライマリ インスタンスを選択します。

PowerShell

Azure PowerShell を使用してセカンダリ インスタンスを作成する場合は、プライマリ インスタンスの ゾーン ID を DnsZonePartner パラメーターに指定してください。

Get-AzSqlInstance コマンドを使用してプライマリ インスタンスの DNS ゾーン ID をパラメーター化し、New-AzSqlInstance コマンドの DnsZonePartner パラメーターに渡すことができます。

# Get the DNS zone ID of the primary instance
$primaryManagedInstanceId = Get-AzSqlInstance -Name $primaryInstance -ResourceGroupName $resourceGroupName | Select-Object Id

# Create the secondary managed instance
New-AzSqlInstance -Name $secondaryInstance `
                  -ResourceGroupName $resourceGroupName `
                  -Location $drLocation `
                  -SubnetId $secondaryMiSubnetConfigId `
                  -AdministratorCredential $mycreds `
                  -StorageSizeInGB $maxStorage `
                  -VCore $vCores `
                  -Edition $edition `
                  -ComputeGeneration $computeGeneration `
                  -LicenseType $license `
                  -DnsZonePartner $primaryManagedInstanceId.Id
Write-host "Secondary SQL Managed Instance created successfully."

インスタンス間の接続の有効化

プライマリとセカンダリのインスタンスをホストする仮想ネットワーク サブネット間の接続は、geo レプリケーショントラフィック フローが中断しないように確立する必要があります。 異なる Azure リージョン内のマネージド インスタンス間の接続を確立するには、次のように複数の方法があります。

• グローバル仮想ネットワーク ピアリング
• Azure ExpressRoute
• VPN ゲートウェイ

グローバル仮想ネットワークピアリングは、フェイルオーバーグループ内のインスタンス間の接続を確立する最もパフォーマン スが高く堅牢な方法として推奨されます。 グローバル仮想ネットワーク ピアリングにより、マイクロソフトバックボーン インフラストラクチャを使用して、ピアリングされた仮想ネットワーク間に低遅延で高帯域幅のプライベート接続が提供されます。 ピアリングされた仮想ネットワーク間の通信では、パブリック インターネット、ゲートウェイ、追加の暗号化が必要ありません。

重要

追加のネットワーク デバイスを含むインスタンスを接続する別の方法では、接続またはレプリケーション速度の問題のトラブルシューティングが複雑になり、ネットワーク管理者の積極的な関与が必要になり、解決時間が大幅に延長される可能性があります。

接続メカニズムに関係なく、geo レプリケーション トラフィックを流すために満たす必要がある要件があります。

• マネージド インスタンス サブネットに割り当てられたルート テーブルとネットワーク セキュリティ グループは、ピアリングされた 2 つの仮想ネットワーク間で共有されません。
• プライマリ インスタンスをホストするサブネットのネットワーク セキュリティ グループ (NSG) 規則では、次が許可されます。
  • セカンダリ インスタンスをホストするサブネットからの、ポート 5022 とポート範囲 11000-11999 の受信トラフィック。
  • セカンダリ インスタンスをホストするサブネットへの、ポート 5022 とポート範囲 11000-11999 の送信トラフィック。
• セカンダリ インスタンスをホストするサブネットのネットワーク セキュリティ グループ (NSG) ルールでは、次が許可されます。
  • プライマリ インスタンスをホストするサブネットからの、ポート 5022 とポート範囲 11000-11999 の受信トラフィック。
  • プライマリ インスタンスをホストするサブネットへの、ポート 5022 とポート範囲 11000-11999 の送信トラフィック。
• プライマリとセカンダリのインスタンスをホストする VNet の IP アドレス範囲は重複してはなりません。
• プライマリとセカンダリのインスタンスをホストする VNet、またはローカル仮想ネットワーク ピアリングなどの手段を介してピアリングされるその他の VNet 間で、IP アドレス範囲の間接的な重複があってはなりません。

さらに、インスタンス間の接続を提供するために推奨されるグローバル仮想ネットワーク ピアリングとは異なる他のメカニズムを使用している場合は、次のことを確認する必要があります。

• ファイアウォールやネットワーク・バーチャル・アプライアンス（NVA）などのネットワーク・デバイスを使用しても、前述のポートのトラフィックはブロックされません。
• ルーティングが適切に構成され、非対称ルーティングが回避されている。
• ハブアンドスポーク ネットワーク トポロジのクロスリージョンにフェールオーバー グループをデプロイする場合、レプリケーション トラフィックは、ハブ ネットワーク経由ではなく、2 つのマネージド インスタンス サブネット間を直接移動する必要があります。 接続とレプリケーション速度の問題を回避するのに役立ちます。

ポータル

1. Azure portal で、プライマリ マネージド インスタンスの仮想ネットワーク リソースに移動します。
2. [設定] の [ピアリング] を選択してから、[+ 追加] を選択します。

1. 次の設定の値を入力または選択します。

   設定	説明
   この仮想ネットワーク
   [Peering link name](ピアリング リンク名)	ピアリングの名前は、仮想ネットワーク内で一意である必要があります。
   [Traffic to remote virtual network](リモート仮想ネットワークへのトラフィック)	既定の VirtualNetwork フローを通過する 2 つの仮想ネットワーク間の通信を有効にするには、[許可 (既定)] を選択します。 仮想ネットワーク間の通信を有効にすると、各仮想ネットワークに接続されているリソースは、同じ仮想ネットワークに接続されている場合と同様に、同じ帯域幅と待機時間で相互に通信できます。 2 つの仮想ネットワーク内のリソース間のすべての通信は、Azure プライベート ネットワーク経由で行われます。
   [Traffic forwarded from remote virtual network](リモート仮想ネットワークから転送されるトラフィック)	このチュートリアルでは、[許可 (既定)] と [ブロック] オプションの両方が機能します。 詳細については、「ピアリングの作成」を参照してください
   仮想ネットワーク ゲートウェイまたは Route Server	[なし] を選択します。 使用できるその他のオプションの詳細については、「ピアリングの作成」を参照してください。
   リモート仮想ネットワーク
   [Peering link name](ピアリング リンク名)	セカンダリ インスタンスをホストする仮想ネットワークで使用される同じピアリングの名前。
   仮想ネットワークのデプロイ モデル	[リソース マネージャー] を選択します。
   リソース ID を知っている	このチェック ボックスはオフのままにします。
   サブスクリプション	ピアリングするセカンダリ インスタンスをホストしている仮想ネットワークの Azure サブスクリプションを選択します。
   仮想ネットワーク	ピアリングするセカンダリ インスタンスをホストしている仮想ネットワークを選択します。 仮想ネットワークが一覧に表示されていても、淡色表示されている場合、仮想ネットワークのアドレス空間がこの仮想ネットワークのアドレス空間と重複している可能性があります。 仮想ネットワークのアドレス空間が重複している場合は、それらの仮想ネットワークをピアリングすることはできません。
   [Traffic to remote virtual network](リモート仮想ネットワークへのトラフィック)	[許可 (既定)] を選択します
   [Traffic forwarded from remote virtual network](リモート仮想ネットワークから転送されるトラフィック)	このチュートリアルでは、[許可 (既定)] と [ブロック] オプションの両方が機能します。 詳細については、「ピアリングの作成」を参照してください。
   仮想ネットワーク ゲートウェイまたは Route Server	[なし] を選択します。 使用できるその他のオプションの詳細については、「ピアリングの作成」を参照してください。

2. [追加] を選択して、選択した仮想ネットワークとのピアリングを構成します。 数秒後、 [更新] ボタンを選択すると、ピアリングの状態が [更新中] から [接続済み] に変わります。

   

PowerShell

プライマリとセカンダリ マネージドインスタンスをホストする仮想ネットワーク間にグローバル仮想ネットワーク ピアリングを設定します。

# Create global virtual network peering
$primaryVirtualNetwork  = Get-AzVirtualNetwork `
                  -Name $primaryVNet `
                  -ResourceGroupName $resourceGroupName

$secondaryVirtualNetwork = Get-AzVirtualNetwork `
                  -Name $secondaryVNet `
                  -ResourceGroupName $resourceGroupName
                  
Write-host "Peering primary VNet to secondary VNet..."
Add-AzVirtualNetworkPeering `
 -Name primaryVnet-secondaryVNet1 `
 -VirtualNetwork $primaryVirtualNetwork `
 -RemoteVirtualNetworkId $secondaryVirtualNetwork.Id
 Write-host "Primary VNet peered to secondary VNet successfully."

Write-host "Peering secondary VNet to primary VNet..."
Add-AzVirtualNetworkPeering `
 -Name secondaryVNet-primaryVNet `
 -VirtualNetwork $secondaryVirtualNetwork `
 -RemoteVirtualNetworkId $primaryVirtualNetwork.Id
Write-host "Secondary VNet peered to primary VNet successfully."

Write-host "Checking peering state on the primary virtual network..."
Get-AzVirtualNetworkPeering `
-ResourceGroupName $resourceGroupName `
-VirtualNetworkName $primaryVNet `
| Select PeeringState

Write-host "Checking peering state on the secondary virtual network..."
Get-AzVirtualNetworkPeering `
-ResourceGroupName $resourceGroupName `
-VirtualNetworkName $secondaryVNet `
| Select PeeringState

このコード スニペットでは、次のコマンドを使用します。

コマンド	メモ
1. Get-AzVirtualNetwork	リソース グループ内の仮想ネットワークを取得します。
2. Add-AzVirtualNetworkPeering	仮想ネットワークにピアリングを追加します。
3. Get-AzVirtualNetworkPeering	仮想ネットワークのピアリングを取得します。

フェールオーバー グループを作成する

Azure portal または PowerShell を使用して、マネージド インスタンスのフェールオーバー グループを作成します。

ポータル

Azure portal を使用して、SQL Managed Instance のフェールオーバー グループを作成します。

1. Azure portal の左側のメニューで [Azure SQL] を選択します。 [Azure SQL] が一覧にない場合は、 [すべてのサービス] を選択し、検索ボックスに「Azure SQL」と入力します。 (省略可能) [Azure SQL] の横にある星を選択し、左側のナビゲーションにお気に入りの項目として追加します。

2. フェールオーバー グループに追加するプライマリ マネージド インスタンスを選択します。

3. [設定] で [インスタンスのフェールオーバー グループ] に移動し、[グループの追加] を選択してインスタンスのフェールオーバー グループの作成ページを開きます。

   

4. [インスタンスのフェールオーバー グループ] ページで、フェールオーバー グループの名前を入力し、ドロップダウンからセカンダリ マネージド インスタンスを選択します。 [作成] を選択して、フェールオーバー グループを作成します。

   

5. フェールオーバー グループのデプロイが完了すると、[フェールオーバー グループ] ページに戻ります。

PowerShell

New-AzSqlDatabaseInstanceFailoverGroup を使用して、PowerShell を使用しながらマネージド インスタンスのフェールオーバー グループを作成します。

# Create failover group
Write-host "Creating the failover group..."
$failoverGroup = New-AzSqlDatabaseInstanceFailoverGroup -Name $failoverGroupName `
     -Location $location -ResourceGroupName $resourceGroupName -PrimaryManagedInstanceName $primaryInstance `
     -PartnerRegion $drLocation -PartnerManagedInstanceName $secondaryInstance `
     -FailoverPolicy Manual -GracePeriodWithDataLossHours 1
$failoverGroup

[テスト フェールオーバー]

Azure portal または PowerShell を使用して、フェールオーバー グループのフェールオーバーをテストします。

ポータル

Azure portal を使用して、フェールオーバー グループのフェールオーバーをテストします。

1. Azure portal 内の セカンダリ マネージド インスタンスに移動し、[設定] で [インスタンスのフェールオーバー グループ] を選択します。

2. プライマリとセカンダリのロールのマネージド インスタンスに注意してください。

3. [フェールオーバー] を選択し、切断中の TDS セッションに関する警告で [はい] を選択します。

   

4. プライマリとセカンダリのロールのマネージド インスタンスに注意してください。 フェールオーバーが成功した場合は、2 つのインスタンスのロールが切り替わっているはずです。

   

重要

ロールが切り替わらなかった場合は、インスタンスと関連する NSG の間の接続とファイアウォール規則を確認します。 次のステップに進むのは、ロールが切り替わった後にしてください。

1. 新しい "セカンダリ" マネージド インスタンスに移動し、もう一度 [フェールオーバー] を選択して、プライマリ インスタンスをプライマリの役割にフェールバックします。

PowerShell

セカンダリ レプリカにフェイルオーバーし、その後フェイルバックして、計画フェールオーバーをテストします。

各サーバーのロールを確認する

Get-AzSqlDatabaseInstanceFailoverGroup コマンドを使用して、各サーバーの役割を確認します。

# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName

セカンダリ サーバーにフェールオーバーする

Switch-AzSqlDatabaseFailoverGroup を使用して、セカンダリ サーバーにフェールオーバーします。

# Failover the primary managed instance to the secondary role
Write-host "Failing primary over to the secondary location"
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $drLocation -Name $failoverGroupName | Switch-AzSqlDatabaseInstanceFailoverGroup
Write-host "Successfully failed failover group to secondary location"

# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $drLocation -Name $failoverGroupName

フェールオーバー グループをプライマリ サーバーに戻す

Switch-AzSqlDatabaseFailoverGroup コマンドを使用して、プライマリ サーバーにフェールバックします。

# Fail primary managed instance back to primary role
Write-host "Failing primary back to primary role"
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName | Switch-AzSqlDatabaseInstanceFailoverGroup
Write-host "Successfully failed failover group to primary location"

# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName

各サーバーのロールを確認する

Get-AzSqlDatabaseFailoverGroup コマンドを使用して、各サーバーの役割を確認します。

# Check role of secondary replica
Write-host "Confirming the secondary replica is secondary...." 
(Get-AzSqlDatabaseFailoverGroup `
   -FailoverGroupName $failoverGroupName `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName).ReplicationRole

セカンダリ サーバーにフェールオーバーする

Switch-AzSqlDatabaseFailoverGroup を使用して、セカンダリ サーバーにフェールオーバーします。

# Failover to secondary server
Write-host "Failing over failover group to the secondary..." 
Switch-AzSqlDatabaseFailoverGroup `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName `
   -FailoverGroupName $failoverGroupName
Write-host "Failed failover group successfully to" $drServerName 

Write-host "Confirming the secondary server is now primary...." 
(Get-AzSqlDatabaseFailoverGroup `
   -FailoverGroupName $failoverGroupName `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName).ReplicationRole

フェールオーバー グループをプライマリ サーバーに戻す

Switch-AzSqlDatabaseFailoverGroup コマンドを使用して、プライマリ サーバーにフェールバックします。

# Revert failover to primary server
Write-host "Failing over failover group to the primary...." 
Switch-AzSqlDatabaseFailoverGroup `
   -ResourceGroupName $resourceGroupName `
   -ServerName $serverName `
   -FailoverGroupName $failoverGroupName
Write-host "Failed failover group successfully back to" $serverName

リスナー エンドポイントを特定する

フェールオーバー グループを構成したら、アプリケーションのリスナー エンドポイントへの接続文字列を更新します。 これで、アプリケーションから、プライマリ データベース、エラスティック プール、またはインスタンス データベースではなく、フェールオーバー グループ リスナーへの接続が維持されます。 このようにすると、データベース エンティティがフェールオーバーするたびに接続文字列を手動で更新する必要がありません。また、トラフィックは、その時点でプライマリであるエンティティにルーティングされます。

リスナー エンドポイントは fog-name.database.windows.net という形式であり、Azure portal でフェールオーバー グループを表示すると確認できます。

異なるサブスクリプションのインスタンス間にグループを作成する

サブスクリプションが同じ Microsoft Entra テナントに関連付けられている限り、2 つの異なるサブスクリプションの SQL Managed Instances 間でフェールオーバー グループを作成できます。

• PowerShell API を使用する場合は、セカンダリ SQL Managed Instance の PartnerSubscriptionId パラメーターを指定することでこれを実行できます。
• パラメーターをREST API、パラメーターに含まれる各インスタンス ID properties.managedInstancePairs に独自のサブスクリプション ID を設定できます。
• Azure portal では、異なるサブスクリプション間でのフェールオーバー グループの作成はサポートされません。

重要

Azure Portal では、異なるサブスクリプション間でのフェールオーバー グループの作成はサポートされません。 異なるサブスクリプション間やリソース グループ間のフェールオーバー グループの場合、プライマリ SQL マネージド インスタンスから Azure portal を介して手動でフェールオーバーを開始することはできません。 代わりに、geo セカンダリ インスタンスから開始してください。

重要なデータが失われないようにする

ワイドエリアネットワークの待機時間が長いため、geo レプリケーションは非同期レプリケーションメカニズムを使用します。 非同期レプリケーションを使用すると、プライマリに障害が発生した場合にデータ損失が回避される可能性があります。 重要なトランザクションをデータ損失から保護するために、アプリケーション開発者はトランザクションをコミットした直後に sp_wait_for_database_copy_sync ストアドプロシージャを呼び出すことができます。 sp_wait_for_database_copy_sync を呼び出すと、最後にコミットされたトランザクションが転送され、セカンダリデータベースのトランザクションログに書き込まれるまで、呼び出し元のスレッドがブロックされます。 ただし、転送されたトランザクションがセカンダリで再生 (再実行) されるのを待つことはありません。 sp_wait_for_database_copy_sync は、特定の geo レプリケーションリンクにスコープが設定されています。 プライマリ データベースへの接続権限を持つユーザーが、このプロシージャを呼び出すことができます。

Note

sp_wait_for_database_copy_sync は、特定のトランザクションの geo フェールオーバー後のデータ損失を防ぎますが、読み取りアクセスの完全同期は保証しません。 sp_wait_for_database_copy_sync プロシージャ呼び出しによって発生する遅延は大きくなる可能性があり、呼び出し時のプライマリでまだ転送されていないトランザクションログのサイズによって異なります。

セカンダリ リージョンを変更する

インスタンス A がプライマリ インスタンス、インスタンス B が既存のセカンダリ インスタンス、インスタンス C が 3 番目のリージョン内の新しいセカンダリ インスタンスであるとします。 移行を行うには、次の手順を実行します。

1. 同じ DNS ゾーン内で、A と同じサイズのインスタンス C を作成します。
2. インスタンス A と B の間のフェールオーバー グループを削除します。この時点で、フェイルオーバーグループリスナーの SQL エイリアスが削除され、ゲートウェイがフェイルオーバーグループ名を認識できないため、サインインに失敗し始めます。 セカンダリ データベースはプライマリから切断され、読み取り/書き込みデータベースになります。
3. フェイルオーバーグループの構成ガイドの指示に従って、インスタンス A と C の間に同じ名前のフェイルオーバー・グループを作成します。 これはデータ サイズに左右される操作であり、インスタンス A のすべてのデータベースがシード処理され、同期されると完了します。
4. 不要な料金が発生しないように、インスタンス B が不要であれば削除してください。

Note

手順 2 の後、手順 3 が完了するまでは、インスタンス A のデータベースは、インスタンス A の致命的な障害から保護されないままになります。

プライマリ リージョンを変更する

インスタンス A がプライマリ インスタンス、インスタンス B が既存のセカンダリ インスタンス、インスタンス C が 3 番目のリージョン内の新しいプライマリ インスタンスであるとします。 移行を行うには、次の手順を実行します。

1. 同じ DNS ゾーン内で、B と同じサイズのインスタンス C を作成します。
2. インスタンス B に接続し、手動でフェールオーバーしてプライマリ インスタンスを B に切り替えます。インスタンス A が自動的に新しいセカンダリ インスタンスになります。
3. インスタンス A と B の間のフェールオーバー グループを削除します。この時点では、フェールオーバー グループ エンドポイントを使用したログイン試行は失敗し始めます。 のセカンダリデータベースはプライマリから切断され、読み取り/書き込みデータベースになります。
4. インスタンス B と C の間に同じ名前のフェールオーバー グループを作成します。マネージド インスタンスを使用したフェールオーバー グループのチュートリアルの指示に従ってください。 これはデータ サイズに左右される操作であり、インスタンス A のすべてのデータベースがシード処理され、同期されると完了します。 この時点で、ログイン試行は失敗しなくなります。
5. C インスタンスをプライマリ ロールに切り替えるには、手動でフェールオーバーします。 インスタンス B が自動的に新しいセカンダリ インスタンスになります。
6. 不要な料金が発生しないように、インスタンス A が不要であれば削除してください。

注意

手順 3 の後、手順 4 が完了するまでは、インスタンス A のデータベースは、インスタンス A の致命的な障害から保護されないままになります。

重要

フェールオーバー グループを削除すると、リスナー エンドポイントの DNS レコードも削除されます。 この時点で、他のユーザーが同じ名前でフェールオーバー グループを作成している可能性はゼロではありません。 フェールオーバーグループ名はグローバルに一意である必要があるため、同じ名前を再度使用することはできません。 このリスクを最小限に抑えるには、汎用フェールオーバーグループ名を使用しないでください。

システム データベースのオブジェクトに依存するシナリオを実現させる

システム データベースは、フェールオーバー グループのセカンダリ インスタンスにはレプリケートされません。 システム データベースのオブジェクトに依存するシナリオを実現するには、セカンダリ インスタンスに同じオブジェクトを作成し、プライマリ インスタンスとの同期を維持する必要があります。

たとえば、セカンダリ インスタンスで同じログインを使用する予定の場合は、必ず、同じ SID でそれらを作成してください。

-- Code to create login on the secondary instance
CREATE LOGIN foo WITH PASSWORD = '<enterStrongPasswordHere>', SID = <login_sid>;

詳細については、「ログインとエージェント ジョブのレプリケーション」を参照してください。

インスタンスのプロパティと保持ポリシーのインスタンスを同期する

フェールオーバーグループ内のインスタンスは個別の Azure リソースを保持します。プライマリインスタンスの構成に対して行われた変更は、セカンダリインスタンスに自動的にレプリケートされません。 プライマリ インスタンスとセカンダリ インスタンスの両方で、関連するすべての変更を実行する必要があります。 たとえば、プライマリ インスタンスでバックアップ ストレージの冗長性または長期的なバックアップ保持ポリシーを変更した場合は、セカンダリ インスタンスでも必ず変更してください。

インスタンスのスケーリング

プライマリとセカンダリのインスタンスを、同じサービス レベル内の別のコンピューティング サイズ、または異なるサービス レベルにスケールアップまたはスケールダウンできます。 同じサービス レベル内でスケールアップするときは、最初に geo セカンダリをスケールアップしてから、プライマリをスケールアップすることをお勧めします。 同じサービス レベル内でスケールダウンするときは、順序を逆にします。つまり最初にプライマリをスケールダウンしてから、セカンダリをスケールダウンします。 インスタンスを異なるサービス レベルにスケーリングするときは、この推奨事項が適用されます。

下位の SKU の geo セカンダリが過負荷になり、アップグレードまたはダウングレード プロセス中に再シードする必要があるという問題を回避するために、このシーケンスが特に推奨されます。

アクセス許可

フェールオーバー グループに対するアクセス許可は、Azure ロールベースのアクセス制御 (Azure RBAC) によって管理されます。

フェールオーバー グループを作成および管理するには、Azure RBAC 書き込みアクセスが必要です。 SQL Managed Instance 共同作成者ロールには、フェールオーバー グループを管理するために必要なすべてのアクセス許可があります。

次の表に、Azure SQL Managed Instance の具体的なアクセス許可のスコープを示します。

操作	権限	スコープ
フェールオーバー グループの作成	Azure RBAC 書き込みアクセス	プライマリのマネージド インスタンス セカンダリのマネージド インスタンス
フェイルオーバー グループを更新する	Azure RBAC 書き込みアクセス	フェイルオーバー グループ マネージド インスタンス内のすべてのデータベース
フェールオーバー グループをフェールオーバーする	Azure RBAC 書き込みアクセス	新しいプライマリ マネージド インスタンスのフェールオーバー グループ

制限事項

次の制限事項に注意してください。

• 同じ Azure リージョン内の 2 つのインスタンス間で、フェールオーバー グループを作成することはできません。
• フェールオーバー グループの名前を変更することはできません。 グループを削除し、別の名前で再作成する必要があります。
• フェールオーバー グループには、必ず 2 つのマネージド インスタンスが含まれています。 フェールオーバー グループにインスタンスを追加することはサポートされていません。
• インスタンスは、いつでも 1 つのフェールオーバー グループにのみ参加できます。
• 異なる Azure テナントに属する 2 つのインスタンス間でフェールオーバー グループを作成することはできません。
• 異なる Azure サブスクリプションに属する 2 つのインスタンス間のフェールオーバー グループは、Azure portal または Azure CLI を使用して作成することはできません。 このようなフェールオーバー グループを作成するには、代わりに Azure PowerShell または REST API を使用します。 作成されると、サブスクリプション間フェールオーバー グループは Azure portal に定期的に表示され、フェールオーバーを含むすべての後続の操作は、Azure portal または Azure CLI から開始できます。
• データベース名の変更は、フェールオーバー グループ内のデータベースではサポートされていません。 データベース名を変更するには、フェールオーバー グループを一時的に削除する必要があります。
• システム データベースは、フェールオーバー グループのセカンダリ インスタンスにはレプリケートされません。 したがって、Server LoginsやAgentジョブといったシステムデータベースのオブジェクトに依存するシナリオでは、オブジェクトをセカンダリインスタンスで手動で作成する必要があります。また、プライマリインスタンスで行われた変更があれば、手動で同期を保つ必要があります。 唯一の例外は SQL Managed Instance のサービス マスター キー (SMK) で、これはフェールオーバー グループの作成時にセカンダリ インスタンスに自動的にレプリケートされます。 ただし、プライマリ インスタンスでの SMK のその後の変更は、セカンダリ インスタンスにレプリケートされません。 詳細については、「システムデータベースのオブジェクトに依存するシナリオを実現させる方法」を参照してください。
• いずれかのインスタンスがインスタンス プールに存在する場合、インスタンス間にフェールオーバー グループを作成することはできません。

フェールオーバーグループをプログラムで管理する

フェールオーバー グループは、Azure PowerShell、Azure CLI、および REST API を使用してプログラムで管理することもできます。 次の表では、使用できるコマンド セットについて説明します。 フェールオーバーグループには、管理のための Azure Resource Manager API 一式 (Azure SQL データベース REST API、Azure PowerShell コマンドレットなど) が含まれています。 これらの API では、リソース グループを使用する必要があり、Azure のロール ベースのアクセス制御 (Azure RBAC) がサポートされます。 アクセス ロールの実装方法の詳細については、Azure のロール ベースのアクセス制御 (Azure RBAC) に関するページをご覧ください。

PowerShell

コマンドレット	説明
New-AzSqlDatabaseInstanceFailoverGroup	このコマンドはフェールオーバー グループを作成し、それをプライマリとセカンダリの両方のインスタンスに登録します。
Set-AzSqlDatabaseInstanceFailoverGroup	フェールオーバー グループの構成を変更します。
Get-AzSqlDatabaseInstanceFailoverGroup	フェールオーバー グループの構成を取得します。
Switch-AzSqlDatabaseInstanceFailoverGroup	フェールオーバー グループのセカンダリ インスタンスに対するフェールオーバーをトリガーします。
Remove-AzSqlDatabaseInstanceFailoverGroup	フェールオーバー グループを削除します

Azure CLI

コマンド	説明
az sql instance-failover-group create	このコマンドはフェールオーバー グループを作成し、それをプライマリとセカンダリの両方のサーバーに登録します。
az sql instance-failover-group delete	フェールオーバー グループをサーバーから削除します。
az sql instance-failover-group show	フェールオーバー グループの構成を取得します。
az sql instance-failover-group update	フェールオーバー グループの構成の変更や、フェールオーバー グループへの 1 つ以上のデータベースの追加を行います
az sql instance-failover-group set-primary	セカンダリ サーバーへのフェールオーバー グループのフェールオーバーをトリガーします

REST API

API	説明
Create or Update Failover Group	フェールオーバー グループの構成を作成または更新します。
Delete Failover Group	フェールオーバー グループをインスタンスから削除します。
Failover (計画されたフェールオーバー)	完全なデータ同期を行って、現在のプライマリ インスタンスからこのインスタンスへのフェールオーバーをトリガーします。
Force Failover Allow Data Loss	データを同期せずに、現在のプライマリ インスタンスからセカンダリ インスタンスへのフェールオーバーをトリガーします。 この操作を行うとデータが失われる可能性があります。
フェールオーバー グループの取得	フェールオーバー グループの構成を取得します。
List Failover Groups - List By Location	場所ごとにフェールオーバー グループをリストします。

次のステップ

フェールオーバー グループを構成するステップについては、フェールオーバー グループへのマネージド インスタンスの追加に関するガイドを参照してください。

この機能の概要については、フェールオーバー グループに関する記事を参照してください。 ライセンス コストを節約する方法については、スタンバイ レプリカの構成に関する記事をご覧ください。