リンクを使用して移行する - 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に複数のリンクを確立できます。

前提条件

移行に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 マネージド インスタンスの 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 が対応する更新ポリシーで構成されている場合にのみ使用できます。

関連するコンテンツ

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

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

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

  • Last updated on