リンクを使用して移行する - Azure SQL Managed Instance

適用対象:Azure SQL Managed Instance

この記事では、Managed Instance リンクを使用して、SQL Server データベースをAzure SQL Managed Instanceに移行する方法について説明します。

詳細な移行ガイドについては、「migrate to Azure SQL Managed Instanceを確認してください。 移行ツールを比較するには、Compare LRS と Managed Instance リンク を確認>。

メモ

Azure Arcで有効になっているSQL Server インスタンスを、Azure ポータルから直接Azure SQL Managed Instanceに移行できるようになりました。 詳細については、「migrate to Azure SQL Managed Instance」を参照してください。

概要

Managed Instance リンクを使用すると、任意の場所でホストされているSQL ServerからAzure SQL Managed Instanceに移行できます。 このリンクでは、Always On 可用性グループ テクノロジを使用して、プライマリ SQL Server インスタンスからセカンダリ SQL Managed Instanceにほぼリアルタイムで変更をレプリケートします。 唯一のダウンタイムはターゲットの SQL マネージド インスタンスへの切り替えのみであるため、このリンクは SQL Server と Azure SQL マネージド インスタンスの間で真のオンライン移行オプションを提供します。

リンクを使用した移行でできることを次に示します。

  • Azureへの移行を完了する前に、SQL Managed Instanceで読み取り専用ワークロードをテストする機能。
  • 必要な期間、数週間、さらには数か月の間、リンクと移行を継続的に実行する機能。
  • Azureに最も高速に使用可能なデータ レプリケーションを提供するデータのほぼリアルタイムのレプリケーション。
  • 現在利用可能な他のすべてのソリューションと比較して、最小のダウンタイムでの移行。
  • ターゲット SQL Managed Instance への即時移行。
  • 準備ができたらいつでも移行できる機能。
  • 単一または複数のSQL Server インスタンスから、Azure内の同じまたは複数の SQL マネージド インスタンスに単一または複数のデータベースを移行する機能。
  • Business Critical サービス レベルへの唯一の真のオンライン移行。

メモ

リンクごとに移行できるデータベースは 1 つだけですが、同じSQL Server インスタンスから同じSQL Managed Instanceに複数のリンクを確立できます。

カットオーバー動作

カットオーバーの動作は、移行するSQL Serverのバージョンと、ターゲット SQL Managed Instanceの更新ポリシーによって異なります。

  • SQL Server 2016から SQL Server 2019 の場合、SQL Managed Instanceへのカットオーバーによってリンクが削除されます。
  • SQL Server 2022 以降では、SQL Managed Instance へのカットオーバー時に、フェールオーバー時の選択に応じて、リンクを削除することも維持することもできます。 リンクを保持することを選択し、SQL マネージド インスタンスが一致する更新ポリシーで構成されている場合は、必要に応じてSQL Serverに戻すことができます。

移行の場合は、リンクを削除することをお勧めします。 リンクを保持するが、後で削除する場合は、フェールオーバー後にデータベースの最初の完全バックアップが完了するまでAzure待ってからリンクを削除します。 この手順により、データベースが正常で、SQL Managed Instanceで完全に機能することが保証されます。 また、リンクがあまりに早く削除された場合に、サーバーの再起動後にデータベースが一時的に利用できなくなることがある、まれに発生する既知の問題を回避するのにも役立ちます。 詳細については、「 MI リンクのフェールオーバー後にサーバーの再起動後にデータベースが使用できなくなる」を参照してください。

移行を元に戻す

SQL マネージド インスタンスの update ポリシーによっては、Azure SQL Managed InstanceからSQL Serverへの逆移行がサポートされる場合があります。 例えば次が挙げられます。

  • SQL Server 2022 更新ポリシー: SQL Server 2022 更新ポリシーで構成されたインスタンスのデータベースは、SQL Server 2022 インスタンスに復元できます。
  • SQL Server 2025 更新ポリシー: SQL Server 2025 更新ポリシーで構成されたインスタンスからのデータベースは、SQL Server 2025 インスタンスに復元できます。
  • Always-up-to-date 更新ポリシー: Always-up-to-date 更新ポリシーで構成されたインスタンスからのデータベースをSQL Serverに復元することはできません。

ソース SQL Server バージョンが 2022 SQL Serverより前の場合、逆移行はできません。 SQL Managed Instanceにデータベースを移行すると、以前のバージョンのSQL Serverバージョンと互換性のない新しいデータベース バージョンへの内部アップグレードが行われます。 逆移行データベースの互換性は、対応する更新ポリシーでSQL Managed Instanceが構成されている場合にのみ使用できます。

前提条件

移行にAzure SQL Managed Instanceリンクを使用するには、次の前提条件が必要です。

評価と検出

ソース環境がサポートされていることを確認した後、移行前ステージから開始します。 既存のデータ ソースをすべて検出し、移行が可能かどうかを評価し、移行の阻害要素となる可能性のある問題を特定します。 検出フェーズで、ネットワークをスキャンして、組織で使用されているすべてのSQL Serverインスタンスと機能を特定します。

次のツールを使用すると、環境内の SQL ソースを検出できます。

  • SQL Server Azure Arc で有効: Azure Arcによって有効になっているSQL Serverは、Azureへの移行の評価を自動的に生成し、移行の検出プロセスと準備の評価を簡略化します。
  • Azure Migrate オンプレミス サーバーの移行適合性を評価し、パフォーマンスベースのサイズ設定を実行し、Azureで実行するためのコスト見積もりを提供します。
  • Microsoft Assessment and Planning Toolkit ("MAP Toolkit") 現在の IT インフラストラクチャを評価します。 ツールキットには、移行計画のプロセスを簡略化するための強力なインベントリ、評価、およびレポート ツールが用意されています。

データ ソースが検出されたら、Azure SQL Managed Instanceに移行できるオンプレミスのSQL Server インスタンスを評価して、移行の阻害要因や互換性の問題を特定します。

マイグレーション準備評価を使用して、ソース SQL Server インスタンスを評価できます。

詳細なガイダンスについては、移行前を確認してください。

ターゲット インスタンスを作成する

既存の環境を評価し、ターゲット SQL マネージド インスタンスの適切なサービス レベルとハードウェア構成を決定したら、Azure portal、PowerShell、または Azure CLI を使用してターゲット インスタンスをデプロイします。

ターゲット SQL マネージド インスタンスが作成されたら、SQL Server インスタンス上のデータベースとAzure SQL Managed Instanceの間のリンクを構成します。 まず、環境を準備しSQL Server Management Studio (SSMS) または scripts を使用してリンクを構成します。

レプリケーションのラグを確認する

計画的な移行フェールオーバーを実行する前に、セカンダリ レプリカがプライマリ レプリカに追いつくことが重要です。 セカンダリ レプリカがプライマリ レプリカから大幅に遅れている場合、計画されたフェールオーバーはタイムアウトになり、失敗する可能性があります。

レプリカ間のレプリケーションのラグを監視するには、SQL ServerとSQL Managed Instanceの両方で次の T-SQL クエリを使用します。

-- Execute on SQL Server and SQL Managed Instance 
USE master
DECLARE @link_name varchar(max) = '<DAGname>'
SELECT
   ag.name [Link name], 
   ars1.role_desc [Link role],
   ars2.connected_state_desc [Link connected state],
   ars2.synchronization_health_desc [Link sync health],
   drs.secondary_lag_seconds [Link replication latency (seconds)]
FROM
   sys.availability_groups ag 
   JOIN sys.dm_hadr_availability_replica_states ars1
   ON ag.group_id = ars1.group_id
   JOIN sys.dm_hadr_availability_replica_states ars2
   ON ag.group_id = ars2.group_id
   JOIN sys.dm_hadr_database_replica_states drs
   ON ars2.replica_id = drs.replica_id
WHERE 
   ag.is_distributed = 1 AND ag.name = @link_name AND ars1.is_local = 1 AND ars2.is_local = 0
GO

レプリケーションのラグが大きい場合は、セカンダリ レプリカがプライマリ レプリカに追いつくのを待ちます。 プライマリ レプリカでのワークロードの一時停止、2 つのインスタンス間のリンク ネットワーク スループットの向上、セカンダリ レプリカのリソース容量の増加など、ラグが続く場合は、追加のトラブルシューティング手順を実行することが必要になる場合があります。 SQL Serverプライマリ レプリカでワークロードを停止する最も簡単な方法は、インスタンスへのアプリケーション接続を切断することです。

複数のデータベースを移行する

パフォーマンスと予測可能性を最適化するために、同じサーバー上のインスタンスから複数のデータベースを移行する場合は、インスタンスごとに 8 つのデータベースを一度に移行します。 たとえば、それぞれ 32 個のリンクされたデータベースを含む 10 個のインスタンスがある場合は、計画されたフェールオーバーを使用して各インスタンスから一度に 8 つのデータベースを移行し、すべてのデータベースが移行されるまでプロセスを繰り返します。

データの同期と切り替え

リンクが確立され、移行する準備ができたら、次の手順に従います (主にメンテナンス期間中)。

  1. プライマリ SQL Server データベースのワークロードを停止して、SQL Managed Instanceのセカンダリ データベースが追いつくようにします。 SQL Serverプライマリ レプリカでワークロードを停止する最も簡単な方法は、インスタンスへのアプリケーション接続を切断することです。
  2. すべてのデータが、SQL Managed Instance上のセカンダリ データベースに渡されたことを検証します。 レプリケーションのラグを確認して、セカンダリ レプリカがプライマリ レプリカに追いついているかどうかを確認します。
  3. 計画フェールオーバーを選択して、セカンダリ SQL Managed Instance へリンクをフェールオーバーします。
  4. (必要に応じて) フェールオーバーが成功した後にリンクを削除 するチェック ボックスをオンにして、フェールオーバーが一方向であり、リンクが削除されていることを確認します。
  5. (必要に応じて)対応する SQL Managed Instance update ポリシー でサポートされているSQL Server バージョンを使用している場合は、フェールオーバー後もリンクを保持して、必要に応じて移行を取り消すことができます。 特定のバージョンの詳細については移行の取り消しセクションを確認してください。
  6. アプリケーションをカットオーバーし、SQL Managed Instance エンドポイントに接続します。
  7. (必要に応じて)フェールオーバー中にリンクを削除することを選択しなかった場合は、不要になったら、カットオーバー後にリンクを削除できます。

移行を検証する

SQL Managed Instance ターゲットにカットオーバーした後、アプリケーションを監視し、パフォーマンスをテストし、問題を修復します。

詳細については、移行後を確認してください。

移行に関する既知の問題

リンクを使用して、移行に関連する次の既知の問題を確認します。

まれに、リンクのフェールオーバー後にサーバーが再起動した後、SQL Managed Instanceでデータベースが一時的に使用できなくなる可能性があります。 この既知の問題は、AzureがSQL Managed Instanceへの初期フェールオーバー後にデータベースの完全バックアップを完了する前にリンクを削除するときに発生します。

データベースはMicrosoftの介入後に自動的に復旧されますが、この復旧には時間がかかる場合があります。

この問題を回避するには、SQL ServerからSQL Managed Instanceへのフェールオーバー後に最初の完全バックアップが完了するまでリンクを削除しないでください。 詳細については、「 サーバーの再起動後にデータベースを使用できない」を参照してください。

SQL Managed Instance に移行した後の復元操作の失敗

高速データベース復旧を有効にして SQL Server 2019 以降のバージョンから Azure SQL Managed Instance にデータベースを移行し、永続的バージョン ストア (PVS) を PRIMARY ファイル グループ以外に設定して構成した場合、ターゲット SQL マネージド インスタンスで復元操作エラーが発生する可能性があります。

この問題を回避するには、SQL Managed Instance に移行する前に、ソース SQL Server データベースの 永続バージョン ストア (PVS) を PRIMARY に設定してください。 PVS を PRIMARY に設定せずにデータベースを既に移行している場合は、ソース SQL Server データベースでデータベースを設定してから、データベースを SQL Managed Instance に再移行できます。

SQL Managed Instance に移行した後に高速データベース復旧を使用できない

SQL Server 2019以降では、データベースをAzure SQL マネージド インスタンスに移行する際、ソースデータベースで高速データベース復旧が無効になっている場合は、ターゲットのSQL マネージド インスタンスで高速データベース復旧を使用することはできません。

この問題を回避するには、SQL Managed Instance に移行する前に、ソース SQL Server データベースで高速データベース復旧を有効にしてください。 データベースの高速復旧を有効にせずに既にデータベースを移行している場合は、ソース SQL Server データベースでデータベースを有効にしてから、データベースを SQL マネージド インスタンスに再移行できます。

SQL Server 2017 以前のバージョンでは高速データベース復旧がサポートされていないため、この問題は、これらのバージョンのSQL Serverから移行されたデータベースには適用されません。

SQL Managed Instanceに移行した後に Service Broker を使用できない

データベースを Azure SQL Managed Instance に移行し、 ソース データベースで Service Broker が無効になっている場合、ターゲット SQL マネージド インスタンスで Service Broker を使用することはできません。

この問題を回避するには、SQL Managed Instanceに移行する前に、ソース SQL Server データベースで Service Broker を有効にしてください。 Service Broker を有効にせずにデータベースを既に移行している場合は、ソース SQL Server データベースでデータベースを有効にしてから、データベースを SQL Managed Instance に再移行できます。

関連するコンテンツ

リンクの使用については、以下を参照してください。

リンクの詳細については、以下を参照してください。

他のレプリケーションおよび移行シナリオについては、以下を検討してください。

  • Last updated on