Always On 可用性グループを Azure SQL Managed Instance に拡張する (プレビュー)

適用対象:Azure SQL Managed Instance

この記事では、Managed Instanceリンクを使ってSQL ServerとAzure SQL Managed Instance間で複数のデータベースを持つAlways Onの可用性グループを拡張する方法を、SQL Server Management Studio(SSMS)、PowerShell、またはAzure CLIを用いる方法を教えます。

この記事では、複数 データベースリンクモードについて説明しています。これは、可用性グループ内のすべてのデータベースを1つのリンクを通じて複製するものです。 シングルデータベースリンクモードは、リンクごとに1つのデータベースを複製します。

概要

SQL ServerとAzure SQL Managed Instance間でAlways Onの可用性グループを拡張すると、複数のデータベースを対象のレプリカにレプリケートするリンクを作成します。 このリンクは分散型可用性グループを用いて、現在のプライマリカからセカンダリカ上の読み取り専用データベースコピーへのほぼリアルタイムの変更をレプリケートします。 これにより、セカンダリ上の読み取り専用コピーはプライマリと最新の状態に保たれます。

既存の可用性グループを使うか、スタンドアロンのデータベースから始めることもできます。 SSMSでスタンドアロンデータベースを選択すると、ウィザードは初期のプライマリに単一ノードの可用性グループを作成し、選択したデータベースを1つのリンクを通じて複製します。

SQL ServerまたはAzure SQL Managed Instanceのいずれかが初期のプライマリとして使えます。 SQL Managed Instance からリンクを作成するには、必要な累積更新プログラムが適用された SQL Server 2022 または SQL Server 2025 と、一致する SQL Managed Instance の 更新ポリシー が必要となります。 この記事の作成例はSQL Serverから始まります。 SQL Managed Instance から作成する手順については説明しません。 SQL ServerとAzure SQL Managed Instance間のロールリバーサルによるフェイルオーバーは、更新ポリシーが一致するインスタンスでサポートされています。

サポータビリティ

プレビュー中に複数データベースリンクを通じて可用性グループを拡張するには、以下の要件が適用されます。 WindowsとLinuxの両方でSQL Serverをサポートしています。 必要な累積更新(CU)をインストールする必要があります。 初期のビルドではこの機能をサポートしていません。

次の点を考慮してください。

• 標準版はサポートされていません。なぜなら、基本的な可用性グループは1つのデータベースのみをサポートしているからです。
• SQL Server 2019以前は、SQL Server 2022で導入された必要な技術がないため、マルチデータベースリンクモードには対応していません。
• SQL Managed InstanceからSQL Server へのリンクを作成する場合も、役割を SQL Server に戻す場合も、SQL Managed Instance では SQL Server のバージョンに一致する更新ポリシーを使用している必要があります。 一方通行レプリケーションおよびSQL Serverからのカットオーバーを行う場合、デスティネーションの更新ポリシーはSQL Serverのバージョンと一致するか、それ以上でなければなりません。
  • SQL Server 2022は、SQL Server 2022、SQL Server 2025、およびAlways-up-to-dateポリシーで設定されたインスタンスへのレプリケーションをサポートしています。
  • SQL Server 2025は、SQL Server 2025およびAlways-up-to-dateポリシーで設定されたインスタンスへのレプリケーションをサポートしていますが、SQL Server 2022は対応していません。 ポリシーが一致していない場合、カットオーバー後にデータをレプリケートしたり、SQL Server にフェイルバックしたりすることはできません。

シングルデータベースリンクをサポートするSQL Serverのバージョンおよびエディションについては、「Managed Instance link version supportability」を参照してください。

前提条件

SQL ServerとAzure SQL Managed Instance間で可用性グループを拡張するには、以下の前提条件が必要です:

• 有効な Azure サブスクリプション。 アカウントがない場合は、無料アカウントを作成してください。
• 必要なサービスアップデートがインストールされたサポート済みSQL Serverのバージョンとエディション。 既存のAlways On可用性グループや、SSMSが新しい単一ノードの可用性グループに配置するスタンドアロンデータベースを使うことができます。 限定された可用性グループはサポートされていません。
• Azure SQL Managed Instanceで、あなたのシナリオに適した更新ポリシーを設定しましょう。 SQL Managed Instanceが初期プライマリの場合やロールリバーサルの場合、マッチングポリシーが必要です。 SQL管理のインスタンスを持っていなければ、まず始めてください。
• SQL Server Management Studio(SSMS)22.10.2以降。
• スクリプト設定の場合は、Azure PowerShell と Az モジュールバージョン 16.3.0 以降、Az.SQL バージョン 7.1.0 以降、または Azure CLI バージョン 2.90.0 以降を選びます。 Azure Cloud Shell を使用することもできます。 インストールされたモジュールやCLIがこれらのバージョン要件を満たしているか確認してください。
• 適切に準備された環境。
• 複数ノードの可用性グループの場合、構成済みの可用性グループ リスナー。 リンク設定時にはリスナーのIPアドレスを使用してください。個々のSQL ServerレプリカのIPアドレスは使いません。 リスナーを使うことで、ローカルの可用性グループのフェイルオーバー後もリンクは動作を続けられます。
• マルチデータベースリンクモードを有効にすると、SQL Serverのレプリカに既存のリンクはありません。 始める前に、古い単一データベースリンクモードを使っているリンクはすべて削除してください。
• 対象管理インスタンスで、可用性グループ内のすべてのデータベースに対して十分な利用可能なデータベース容量とストレージを確保してください。 リソースの制限を見直しましょう。

Permissions

SQL Server の場合は、 sysadmin アクセス許可が必要です。

Azure SQL Managed Instance の場合は、 SQL Managed Instance 共同作成者 ロールのメンバーであるか、次のカスタム ロールのアクセス許可を持っている必要があります。

マルチデータベースリンクモードを有効にする

プレビュー中は複数データベースリンクモードのサポートがデフォルトで無効とされています。 組み込みの sys.sp_multidb_milink ストアドプロシージャを使って、可用性グループ内のすべてのSQL Serverレプリカ、または単一ノードグループを作成する予定のSQL Serverインスタンスで有効化してください。

すべてのSQL Serverレプリカで以下のコマンドを実行して、複数データベースリンクモードを有効にします:

EXEC sys.sp_multidb_milink 1;

この設定はSQL Serverの再起動中も維持されるので、各レプリカで一度だけ有効にすれば十分です。

設定を確認するには、各レプリカにパラメータを持たずにストアドプロシージャを実行します。 有効化すると 1 、無効化すると 0 返します:

EXEC sys.sp_multidb_milink;

ストアドプロシージャが利用できない場合は、レプリカがサポートされているSQL Serverバージョンと累積アップデートがインストールされているか確認してください。

マルチデータベースリンクモードを無効にするには、まずすべてのリンクを削除し、すべてのSQL Serverレプリカに対して以下のコマンドを実行します。

EXEC sys.sp_multidb_milink 0;

可用性グループのデータベースを準備します

複製したいSQL Serverデータベースを完全なリカバリーモデルに設定し、その後フルバックアップを作成します。 既存の可用性グループデータベースも、単独のデータベースもこの準備を必要とします。 リンク設定ガイドの SSMSバックアップ手順 をご利用ください。

SQL Serverデータベースの場合は、TDE証明書をSQL Managed Instanceに移行してください。 SQL Serverにリンクされた暗号化されたSQL Managed Instanceデータベースについては、顧客管理の鍵を使い、宛先のSQL Serverにアクセスできる。 リンクのTDE準備を確認し、各方向の要件を確認してください。

リンクは選択した可用性グループ内のすべてのデータベースを複製します。 サブセットは選べないので、リンクを作成する前にターゲットSQL管理インスタンスの利用可能な容量を確認してください。 宛先には複製したいデータベースと同じ名前のデータベースが含まれてはなりません。 異なる名前の既存のデータベースは、インスタンスの容量制限に従い許可されています。

このリンクでは、ユーザー データベースのレプリケーションのみをサポートしています。 システム データベースのレプリケーションはサポートされていません。 masterまたはmsdbに格納されているインスタンス レベルのオブジェクトをレプリケートするには、それらをスクリプト化し、ターゲット インスタンスで T-SQL スクリプトを実行します。

リスナーと証明書の設定

複数ノードの可用性グループでは、SSMSおよびスクリプトの両方でリスナーのIPアドレスをリンク設定時に使用してください。 リスナーは接続を現在のプライマリレプリカに誘導します。 個々のSQL ServerレプリカのIPアドレスをリンクのパートナーエンドポイントとして使わないでください。 リスナーがいなければ、ローカルの可用性グループのフェイルオーバー後にリンクは動作を続けられません。 SSMSウィザードで作成されたスタンドアロンデータベース用の単一ノード可用性グループの場合は、そのSQL ServerインスタンスのIPエンドポイントを使用します。

SSMSウィザードはAzure SQL Managed Instanceと現在のSQL Serverプライマリレプリカ間で証明書を交換します。 他のSQL Serverレプリカに対して証明書の信頼を設定しません。 ローカルの可用性グループのフェイルオーバー後もリンクが動作し続けるように、他のすべてのSQL Serverレプリカで必要な証明書を手動でコピー・設定する必要があります。 この手動ステップはSSMSとスクリプト設定の両方に適用されます。 証明書交換ステップのために インスタンス間の信頼を確立 する。

スクリプト化されたリンク作成の準備をしましょう

推奨されるセットアップ体験にはSSMSを使いましょう。 ウィザードは多くの設定ステップを自動化します。 スクリプト自動化が不要なら、このセクションを飛ばして「可用性を拡張」グループのSSMSタブに進んでください。

スクリプト設定は、可用性グループ、エンドポイント、証明書の信頼設定の経験を必要とする高度なオプションです。 これらのステップは、PowerShellやAzure CLIをSQL Serverを初期のプライマリとして使っている場合のみ行うべきです。

このチェックリストは既存の可用性グループと独立したデータベースの両方をカバーしています。 データベース、トラスト、エンドポイントを準備した後、既存の可用性グループを再利用するか、ステップ4で作成してください。 次に分散型可用性グループを作成します。 PowerShellやAzure CLIのリンク作成コマンドは、可用性グループを自動で作成しません。

環境に合わせたスクリプトを使えば、SSMSリンクウィザードのサマリーページでスクリプトを選択してください。 生成されたスクリプトを確認し、別途実行してください。

1. すべてのSQL Serverレプリカ、またはスタンドアロンのSQL Serverインスタンスでマルチデータベースリンクモードを有効にし、データベースを準備します。
2. インスタンス間の信頼を確立します。 証明書作成、公開鍵交換、ルート証明書インポート、証明書チェーン検証の手順に従ってください。 複数ノードグループの場合は、証明書要件を現在のプライマリだけでなくすべてのSQL Serverレプリカに適用してください。
3. データベースミラーリングエンドポイントを安全にしてください。 もしあなたのアベイラビリティグループにすでにエンドポイントがある場合は、既存のエンドポイントを新規作成するのではなく、 Alter(変更 )を使いましょう。 リンク作成コマンドのために設定されたエンドポイントポートを保持してください。
4. アベイビリティグループを準備しろ。 複製したいすべてのデータベースを含む可用性グループがすでにある場合は、それを再利用して新しいグループを作成しないようにしましょう。 スタンドアロンのデータベースから始めるなら、まずSQL Serverで可用性グループを作成しましょう。 SQL Server最初のプライマリタブでは、単一ノードCREATE AVAILABILITY GROUP例をCLUSTER_TYPE = NONEで使用し、FOR DATABASE [<DatabaseName>]をFOR DATABASE [DB01], [DB03], [DB05], [DB07]などの完全なデータベースリストに置き換えます。 新しいグループに付けたい名前に <AGNameOnSQLServer> を設定してください。 分散型可用性グループ作成を続ける前に、このスクリプトを実行してください。 既存のグループに対して実行したり、既存のグループのクラスタ構成を変更したりしないでください。
5. SQL Server上で分散型可用性グループを作成します。 SQL Serverの最初のプライマリタブを使い、分散型可用性グループ作成の指示から始めてください。 <AGNameOnSQLServer>、前のステップで再利用または作成した可用性グループに設定してください。 複数ノードグループの場合は、リスナーのIPアドレスを使い <SQLServerIP>。 単一ノードグループの場合は、SQL Serverインスタンスのエンドポイントを使用します。 リンク名として <DAGName> を保持し、下記作成コマンドの管理インスタンス可用性グループ名として <AGNameOnSQLMI> を残してください。
6. SQL Serverで可用性グループを確認してください。 Always Onの可用性グループと分散型可用性グループの両方が存在するか確認してください。 その後、可用性グループの拡張に戻り、PowerShell または Azure CLI を選択して、他のガイドにある単一データベース作成コマンドではなく、この記事の複数データベース作成コマンドを実行してください。

可用性グループを拡張する

シーディングに必要なログレコードを保持するために、推奨される方法は、特に大規模データベースや複数データベースリンクモードで複数のデータベースを組み合わせたデータベースの場合、リンクを作成する前に、サポートされているSQL Serverビルドでトレースフラグ12381を有効にすることです。 ただし、このフラグは必須ではなく、トラブルシューティング エラー1412に記載された代替の緩和策もあります。 フラグが有効化されるとログバックアップは継続できますが、保持されたログレコードは再利用できません。 SQL Serverのログ成長と空きディスク容量を監視し、すべてのリンクのシーディングが完了したらすぐにフラグを無効にしてください。

SSMSを使ってリンク作成を自動化するか、PowerShellやAzure CLIで高度なスクリプト設定を選びましょう。 以下の例では、SQL Serverを初期プライマリとして使用しています。 SQL Managed Instanceからマッチングアップデートポリシーを組み合わせて始めることもできますが、その作成ワークフローはここでは扱っていません。

スクリプト設定の場合は、複製したいすべてのデータベースを含む可用性グループを再利用または作成するためのスクリプト設定ステップを完了し、その後分散型可用性グループを作成し、PowerShellやAzure CLI作成コマンドを実行する前に行います。 あるいは、スタンドアロンデータベースから始める場合、このセクションのSSMS手順によりリンク設定の一環としてシングルノードの可用性グループが自動的に作成されます。

複数データベースリンクモードの場合、スクリプトで MultiDatabase を明示的に指定し、すべての データベース名 を可用性グループに提供してください。 PowerShellは-LinkModeを省略するとデフォルトでSingleDatabaseになります。 PowerShellで-LinkMode MultiDatabaseを使い、Azure CLIで--link-mode MultiDatabaseしてください。

Update-Module -Name Az
Update-Module -Name Az.Sql

Get-InstalledModule -Name Az | Select-Object Name, Version
Get-InstalledModule -Name Az.Sql | Select-Object Name, Version

# Run in Azure Cloud Shell and select PowerShell.
$ManagedInstanceName = "<ManagedInstanceName>"

# Use the distributed availability group name from SQL Server as the link name.
# Use lowercase letters and hyphens, with no leading or trailing hyphen.
# The name must not already identify another link on this managed instance.
$DAGName = "<DAGName>"

# Enter the availability group names from the setup steps.
$AGNameOnSQLServer = "<AGNameOnSQLServer>"
$AGNameOnSQLMI = "<AGNameOnSQLMI>"

# Include every database in the availability group.
$DatabaseNames = @("DB01", "DB03", "DB05", "DB07")

# Use the listener IP for multiple-node AGs or the instance IP for single-node AGs.
$SQLEndpointIP = "<SQLEndpointIP>"
# Use the database mirroring endpoint port, normally 5022 unless customized.
$EndpointPort = "<EndpointPort>"

$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName
$SQLPartnerEndpoint = "TCP://" + $SQLEndpointIP + ":" + $EndpointPort

# Create the multi-database link with SQL Managed Instance as the secondary.
New-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName -PartnerAvailabilityGroupName $AGNameOnSQLServer -InstanceAvailabilityGroupName $AGNameOnSQLMI -Database $DatabaseNames -PartnerEndpoint $SQLPartnerEndpoint -InstanceLinkRole "Secondary" -FailoverMode "Manual" -SeedingMode "Automatic" -LinkMode "MultiDatabase"

# Run in Azure Cloud Shell and select Bash.
ResourceGroupName="<ResourceGroupName>"
ManagedInstanceName="<ManagedInstanceName>"

# Use the distributed availability group name from SQL Server as the link name.
# Use lowercase letters and hyphens, with no leading or trailing hyphen.
# The name must not already identify another link on this managed instance.
DAGName="<DAGName>"

# Enter the availability group names from the setup steps.
AGNameOnSQLServer="<AGNameOnSQLServer>"
AGNameOnSQLMI="<AGNameOnSQLMI>"

# Include every database in the availability group.
DatabaseNames="[{database-name:DB01},{database-name:DB03},{database-name:DB05},{database-name:DB07}]"

# Use the listener IP for multiple-node AGs or the instance IP for single-node AGs.
SQLEndpointIP="<SQLEndpointIP>"
# Use the database mirroring endpoint port, normally 5022 unless customized.
EndpointPort="<EndpointPort>"

SQLPartnerEndpoint="TCP://${SQLEndpointIP}:${EndpointPort}"

# Create the multi-database link with SQL Managed Instance as the secondary.
az sql mi link create --resource-group "$ResourceGroupName" --instance-name "$ManagedInstanceName" --name "$DAGName" --partner-availability-group-name "$AGNameOnSQLServer" --instance-availability-group-name "$AGNameOnSQLMI" --databases "$DatabaseNames" --partner-endpoint "$SQLPartnerEndpoint" --instance-link-role Secondary --failover-mode Manual --seeding-mode Automatic --link-mode MultiDatabase

複製の検証

リンクを作成したりデータベースを追加した後、データは現在のプライマリから現在のセカンダリレプリカへ複製されます。 SQL ServerまたはAzure SQL Managed Instanceのいずれかが初期のプライマリとして使えます。 役割逆転後、データは逆方向に複製されます。 データベースのサイズやネットワーク速度によっては、各データベースがセカンダリプレプリカ上で最初に 復元 状態にある場合があります。 最初のシード処理が終了すると、データベースはセカンダリ レプリカに復元され、読み取り専用ワークロードの準備が完了します。

どちらのレプリカでも、SSMSのオブジェクト エクスプローラーを使って各複製されたデータベースの同期状態を確認できます。 リンク用に作成された分散可用性グループを表示するには、Always On 高可用性 と 可用性グループ を展開します。

SQL Serverがプライマリの場合、対応ビルドでtraceフラグ12381が有効であれば、シーディング中にトランザクションログのバックアップを継続できます。 早期切断を防ぐためにログバックアップを一時停止する場合は、初期シーディング終了後に再開してください。 ログバックアップスケジュールがない各データベースについては、最初の トランザクションログバックアップ は初期シード終了後にのみ行い、シード中は行いません。 すべてのリンクのシードが完了したら、フラグを有効にしていれば無効にし、SQL Serverがプライマリのままのまま定期的にSQL Serverのトランザクションログバックアップを取ります。 Azure SQL Managed Instanceがプライマリの場合、トランザクションログのバックアップを自動的に処理します。 これらのデータベースはSQL Serverが二次的なもので、手動でSQL Serverログバックアップを行う必要はありません。

シーディング中の早期なログ切断は、SQL Managed Instanceエラーログにエラー1408および1412を引き起こすことがあります。 このツールをサポートするビルドでは、trace flag 12381 この切断を防ぎます。 すべてのリンクのシーディングが完了したら無効にし、有効にしている間はトランザクションログの使用状況、成長率、空きディスク容量を監視してください。 必要な記録が保持される間もログのバックアップは継続可能です。 この保持機能はシード後の通常のログバックアップに代わるものではありません。 「 早期ログ切断防止」を参照してください。

データベースを追加する

SSMSウィザードを使って、現在のプライマリ(SQL ServerでもSQL Managed Instanceでも)からデータベースを追加してください。 ウィザードは必要な変更を自動化します。 高度な自動化にはPowerShellかAzure CLIを使いましょう。 データベースの追加は、プライマリ側で単一の操作で済みます。

データベースを追加する前に、既存のリンクが複数データベースリンクモードを使用していること、そして宛先が十分なデータベース容量とストレージを持ち、既存のデータベース名が新しいデータベースと競合していないかを確認してください。 SQL Serverがプライマリの場合、まだ可用性グループに入っていない新しいデータベースをすべて完全なリカバリーモデルに設定し、SSMSバックアップ手順を使ってフルバックアップを作成します。

SSMS対応データベースの追加

既存の複数データベースリンクにデータベースを追加するには、Azure SQL Managed Instance Linkにデータベースを追加するウィザードを使いましょう:

1. SSMSで現在のプライマリに接続してください。 オブジェクト エクスプローラーで「Always On High Availability Groups」と「Availability Groups」を展開します。

2. リンクの分散可用性グループを右クリックし、「Azure SQL Managed Instance」リンクにカーソルを合わせて「Add Database...」を選択してください。

   

3. 導入とAzureログインを進め、その後「選択リンク」ページで複数データベースリンクを選択します。

4. 「 データベース選択 」ページで、追加したいデータベースを選択します。 Ready状態のデータベースのみ追加できます。 リンク内にあるデータベースは 「選択されたリンクの既に一部」として表示されます。 参加資格の問題を解決してから続ける。

   

5. 検証 を完了し、概要を確認します。 変更を実行するには 「Finish 」を選択し、「 Script 」を選択して変更を実行しずにスクリプトを生成し、個別にレビュー・カスタマイズ・実行できます。 ウィザードで変更を実行する場合は、閉じる前に 結果 を確認してください。

スクリプト付きのデータベースを追加

現在のプライマリで追加を実行してください。 その場合の指示に従ってください。

SQL Serverがプライマリの場合

T-SQLを使って 各データベースを可用性グループに追加してください。 リンクは追加内容をSQL Managed Instanceに伝播させます。 SQL Managed Instanceに関しては追加の操作は不要です。 この追加のためにPowerShellやAzure CLIのアップデートを実行しないでください。

SQL Managed Instanceがプライマリの場合

PowerShell または Azure CLI を使って SQL Managed Instance のリンクを更新してください。 リンクは追加されたデータベースを自動的に可用性グループに伝播させます。 SQL Server上で別途ステップを踏む必要はありません。 保持する既存のデータベースすべてと新しいデータベースを含む意図した完全なメンバーシップを指定してください。 提供されたリストは現在の会員に代わるものです。 データベースを省略すると、そのリンクのメンバーシップから除外されます。

例えば、リンクにすでにDB01、DB03、DB05、DB07が含まれている場合、DB09を追加するには、その4つの名前をリストに保持しつつ、リストにDB09も追加してください。 リソース名とデータベース名を自分の価値に置き換えてください。

# Include every existing database to retain and each new database to add.
$DatabaseNames = @("DB01", "DB03", "DB05", "DB07", "DB09")

Update-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName -Database $DatabaseNames

# Include every existing database to retain and each new database to add.
DatabaseNames="[{database-name:DB01},{database-name:DB03},{database-name:DB05},{database-name:DB07},{database-name:DB09}]"

az sql mi link update --resource-group "$ResourceGroupName" --instance-name "$ManagedInstanceName" --name "$DAGName" --databases "$DatabaseNames"

新たに追加された各データベースごとに レプリケーション検証の手順 を繰り返します。 手動ログバックアップの手順は、SQL Serverがプライマリである場合にのみ確認してください。

データベースの削除

現在のプライマリでSSMSウィザードを使って両側の除去を自動化してください。 データベースを削除するには、SQL Managed Instanceのリンクおよび可用性グループからデータベースを削除する必要があります。 片側だけを外しても作業は完了しません。

SSMSでデータベースを削除する

SQL ServerでもSQL Managed Instanceでも、以下の手順が適用されます。

1. SSMSで現在のプライマリに接続してください。 オブジェクト エクスプローラーで「Always On High Availability Groups」と「Availability Groups」を展開します。

2. リンクの分散可用性グループを右クリックし、「Azure SQL Managed Instance」リンクにカーソルを合わせて「データベースを削除...」を選択してください。

   

3. 「Azure SQL Managed Instance Linkからデータベースを除去する」ウィザードで、「Introdus」と「Azure Login」を進み、「Select Link」のリンクを選択します。

4. 「データベース選択」で、削除するデータベースを選択します。 例えば、 DB05 を選択してリンクから削除し、次に 「Next」を選択してください。

   

5. 検証を完了し、Summaryをレビューし、削除を実行するにはFinishを選択し、最初に生成されたコマンドをレビューするためにScriptを選択します。 ウィザードを閉じる前に、 結果が成功 したかどうかを確認してください。

スクリプトを含むデータベースの削除

両方のインスタンスでデータベースを削除してください。 現在のプライマリがどのインスタンスを最初に更新するかを決めます。

PowerShellおよびAzure CLIの例では、以下の変数を使用します:

SQL Serverがプライマリの場合

1. T-SQLを使って 、データベースを可用性グループから削除してください。
2. PowerShellまたはAzure CLIを使って、このセクションに示すようにSQL Managed Instanceのリンクからデータベースを削除してください。

SQL Managed Instanceのステップでは、保持するデータベースの完全なリストを提供し、削除したいものだけを省略します。 例えば、リンクに DB01、 DB03、 DB05、 DB07、 DB09が含まれている場合、次のコマンドで DB05 を削除し、残りの4つを保持します。 リソース名とデータベース名を自分の価値に置き換えてください。

# Include only the databases to retain, excluding DB05.
$DatabaseNames = @("DB01", "DB03", "DB07", "DB09")

Update-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName -Database $DatabaseNames

# Include only the databases to retain, excluding DB05.
DatabaseNames="[{database-name:DB01},{database-name:DB03},{database-name:DB07},{database-name:DB09}]"

az sql mi link update --resource-group "$ResourceGroupName" --instance-name "$ManagedInstanceName" --name "$DAGName" --databases "$DatabaseNames"

SQL Managed Instanceがプライマリの場合

1. PowerShellまたはAzure CLIを使って、このセクションに示すようにSQL Managed Instanceのリンクからデータベースを削除してください。
2. SQL ServerでT-SQLを使って、データベースを可用性グループから削除してください。 このステップを終えるまで除去は完了しません。

SQL Managed Instanceのステップでは、保持するデータベースの完全なリストを提供し、削除したいものだけを省略します。 例えば、リンクに DB01、 DB03、 DB05、 DB07、 DB09が含まれている場合、次のコマンドで DB05 を削除し、残りの4つを保持します。 リソース名とデータベース名を自分の価値に置き換えてください。

# Include only the databases to retain, excluding DB05.
$DatabaseNames = @("DB01", "DB03", "DB07", "DB09")

Update-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName -Database $DatabaseNames

# Include only the databases to retain, excluding DB05.
DatabaseNames="[{database-name:DB01},{database-name:DB03},{database-name:DB07},{database-name:DB09}]"

az sql mi link update --resource-group "$ResourceGroupName" --instance-name "$ManagedInstanceName" --name "$DAGName" --databases "$DatabaseNames"

削除されたデータベースがリンクや可用性グループに属していないか確認してください。 レプリケーションからデータベースを削除することは、保持しているコピーを削除するのとは違います。 不要なコピーを削除するかどうか決める前に、両方のインスタンスのデータベースを確認してください。

Azure にフェールオーバーする、または切り替える

既存のSSMSやスクリプトのフェイルオーバー手順を使って、SQL ServerとAzure SQL Managed Instance間でロールを逆にできます。 ロールリバーサルは、SQL管理インスタンスがSQL Serverのバージョンに合った更新ポリシーを使う必要があります。 一方通行レプリケーションとAzure SQL Managed Instanceへの切り替えを行うには、更新ポリシーがSQL Serverのバージョンと同等かそれ以上でなければなりません。 ポリシーが一致しなければ、データをレプリケートしたりSQL Serverにフェイルバックしたりすることはできません。 サポートされた組み合わせを確認しましょう。 移行および切り替えの指針については、「 リンク付きの移行」をご覧ください。

レプリケーションの監視とトラブルシューティング

SQL Server上の以下の動的管理ビュー(DMV)およびカタログビューを使って、メインの可用性グループ、レプリカ接続性、各データベースのレプリケーションの健全性を確認してください:

SELECT * FROM sys.availability_groups;
SELECT * FROM sys.dm_hadr_availability_replica_states;
SELECT * FROM sys.dm_hadr_database_replica_states;
SELECT * FROM sys.dm_hadr_internal_availability_groups;
SELECT * FROM sys.dm_hadr_internal_availability_replicas;

内部レプリケーション用のDMVが利用できない場合や、sys.sp_multidb_milinkストアドプロシージャの実行で利用できない場合は、そのレプリカでインストールされたSQL Serverバージョンと累積アップデートを確認してください。 一般的な接続性およびレプリケーションのトラブルシューティングについては、「Managed Instance リンクのトラブルシューティング」を参照してください。

制限事項

複数データベースリンクを通じて可用性グループを拡張する際、以下の制限を考慮してください。

• リンク名は小文字でなければなりません。 ハイフンは許可されますが、名前はハイフンで始まったり終わったりすることはできません。
• 複数データベースモードでリンクがアクティブな間は、SQL Server 2022 CU27またはSQL Server 2025 CU9未満のSQL Serverレプリカをダウングレードしないでください。 必要なCUを下回ると、フェイルオーバーがなくても予測不能な問題が発生することがあります。
• 限定された可用性グループはサポートされていません。
• 単一のデータベースリンクと複数のデータベースリンクは、同じSQL Serverインスタンス上で共存することはできません。
• リンクのモードをそのまま変更することはできません。 シングルデータベースとマルチデータベースリンクモードを切り替えるには、既存のリンクをすべて削除し、すべてのSQL Serverレプリカでモードを変更し、新しいモードでリンクを再作成します。
• 既存の可用性グループのリンクを作成する際、そのグループ内のすべてのデータベースを複製しなければなりません。 そのグループ内のデータベースの一部だけを選択することはできません。
• ターゲットとなるSQL管理インスタンスの残りのデータベース容量が、複製できるデータベースの数を制限します。 General Purpose and Business Critical はインスタンスあたり最大100のデータベースをサポートし、Next-gen General Purposeは最大500のデータベースをサポートします。 既存のデータベースもこれらの制限に含まれます。 例えば、100データベースの上限と10の既存データベースを持つインスタンスは、さらに90個のデータベースを管理できます。 詳細については、 リソース制限を参照してください。
• ターゲットのSQL managed instanceの利用可能なデータベース容量を超えたデータベースを可用性グループに追加することはSQL Serverで成功しますが、SQL Managed Instanceへのレプリケーションは失敗します。 この状態はリンクを不整合な状態にし、複製されていないデータベースを可用性グループから手動で削除する必要がある場合があります。
• データベースの追加はリンクを通じて伝播しますが、一方のデータベースを削除しても、もう一方のデータベースが自動的に削除されるわけではありません。 可用性グループからデータベースを削除しても、そのコピーはSQL Managed Instanceに残ります。 SQL Managed Instanceのリンクからデータベースを削除した場合、そのデータベースはリンクを介したレプリケーションなしで可用性グループに残り、手動でクリーンアップする必要があります。
• SSMS経由で既存リンクにデータベースを追加する場合、 Ready 状態のデータベースのみ追加できます。 他の可用性グループに属するデータベースや、宛先に既に存在する名前を持つデータベースを追加することはできません。

関連するコンテンツ

• Managed Instance リンクの概要
• リンクのために環境を準備する
• SSMS を使用してリンクを構成する
• リンクを維持するためのベスト プラクティス
• リンク に関する問題のトラブルシューティング