次の方法で共有


LRS と Managed Instance の比較リンク

適用対象:Azure SQL Managed Instance

この記事では、Azure SQL Managed Instance に移行するときに、Log Replay Service (LRS)Managed Instance のリンクを比較します。

概要

Log Replay Service (LRS) は、2018 年 11 月にサービスが開始されて以来、Azure SQL Managed Instance への移行に使用されています。 LRS は内部的には、 ログ配布の実装に依存しています。ログ配布は 、Azure Database Migration Service (DMS) と Azure Data Studio 用 の Azure SQL 移行拡張機能 にも利用されます。

2022 年 3 月、Managed Instance のリンク (MI リンク) は、可能な限り最小限のダウンタイム移行を約束する、よりパフォーマンスの高い移行オプションとして導入されました。 Managed Instance リンクは 、分散型 Always On 可用性グループ テクノロジを使用して、SQL Server から Azure SQL Managed Instance にほぼリアルタイムでデータをレプリケートします。 このリンクを使用すると、移行保険ポリシーとして SQL Managed Instance から SQL Server 2022 以降 オンラインでフォールバックすることもできます。

LRS と MI リンクは、各テクノロジが異なるビジネス ニーズに合わせて、機能でお互いを補完します。 各ツールの機能を確認して、特定の状況に基づいて移行に最適なツールを決定します。

LRS と MI リンクの基本的な違いは、基になるテクノロジに由来します。 LRS はログ配布に基づいているため、差分とトランザクション ログのバックアップは SQL Server から継続的に取得され、Azure Blob Storage にアップロードされ、SQL Managed Instance に復元されます。 ファイルのバックアップ、アップロード、復元には時間がかかるため、プロセスはリアルタイムではありません。 LRS のパフォーマンスは、バックアップ チャンクのサイズに基づきます。

これに対し、MI リンクでは Always On 可用性グループ テクノロジを使用して、SQL Server から SQL Managed Instance にほぼリアルタイムでトランザクション ログ レコードを送信するため、よりパフォーマンスの高い移行ソリューションになります。 ただし、MI リンクを構成するには、SQL Server と SQL Managed Instance の間に VPN を設定し、ファイアウォールで適切なポートを開く必要があります。一方、LRS はパブリック エンドポイントを使用してすぐに動作します。 LRS は SQL Server 2008 以降のすべてのエディションで使用できますが、MI リンクは SQL Server 2016 以降、Standard、Enterprise、Developer の各エディションでのみ使用できます。

SQL Server 2025 プレビューでは、SQL Server の Enterprise Developer エディションと Standard Developer エディションが個別に導入されています。

MI リンクの主な利点は、LRS では不可能な SQL Server 2022 以降への逆移行を実行できることです。 MI リンクを使用して移行するもう 1 つの主な利点は、移行の進行中に SQL Managed Instance 上のデータベースを読み取り専用ワークロードに使用できることです。 移行が完了するまでデータベースは復元状態であるため、LRS ではこの機能を使用できません。 同様に、SQL Server 2022 以降への逆移行を実行すると、移行の進行中に SQL Server の読み取り専用ワークロードに対してデータベースにアクセスできます。

次の表では、LRS と MI の両方のリンクをより詳細に比較しています。

機能 Managed Instance リンク (MI リンク) ログ再生サービス (LRS) メモ
基盤となるテクノロジ 分散型可用性グループ (AG) ログ配布 MI リンクでは、レプリケーションに分散型可用性グループが使用されます。これは、LRS で使用されるログ配布テクノロジと比較すると、より新しく高度です。
レプリケーションのパフォーマンス ほぼリアルタイム。 数分ごとに復元します。 MI リンクを使用してデータをレプリケートする方が、LRS でトランザクション ログ バックアップを適用するよりもパフォーマンスが大幅に向上します。
サポートされる最小ソース バージョン SQL Server 2016 以降 SQL Server 2008 以降 LRS では、MI リンクよりもはるかに古い SQL Server バージョンをサポートできます。
サポートされている Windows Server の最小バージョン Windows Server 2012 R2 Windows Server 2008 LRS では、MI リンクよりもはるかに古いバージョンの Windows Server をサポートできます。
読み取り専用セカンダリ サポート対象。 サポートされていません。 レプリケーションの進行中は、リンクを介してレプリケートされた SQL Managed Instance データベースを読み取り専用ワークロードに使用できます。これにより、切り捨て前に移行をテストしたり、Azure に移行する前にデータベースを使用したりできます。 同様に、SQL Server 2022 以降への逆移行を実行すると、移行の進行中に SQL Server の読み取り専用ワークロードに対してデータベースにアクセスできます。 この機能は LRS では使用できません。
TDE で暗号化されたデータベースのレプリケーション はい。SQL Managed Instance にセキュリティ キーをインポートする必要があります。 はい。SQL Managed Instance にセキュリティ キーをインポートする必要があります。 移行を開始する前に、対応する暗号化証明書を SQL Server から SQL マネージド インスタンスに移行する要件と手順は、両方の移行オプションで同じです。
ネットワーク接続の種類 - プライベート エンドポイント
- 受信ポートと送信ポートの両方で構成された VPN
パブリック エンドポイント MI リンクは追加のセキュリティ レイヤーを提供し、オプションとして VPN を提供しますが、LRS と比較してネットワークの構成は困難です。

既定では、LRS は簡略化されたエクスペリエンスを提供するため、ネットワークまたは VPN 構成なしですぐに使用できます。 LRS は既定でパブリック エンドポイントを使用します。これは MI リンクで使用される VPN よりも安全性が低く、SQL Managed Instance に復元される前にデータを保存するための仲介役としてパブリックに公開された Azure Blob Storage アカウントを使用するため、最も要求の厳しいセキュリティ要件の一部を満たさない可能性があります。 LRS でプライベート エンドポイントを使用してデータの転送をセキュリティで保護することは可能ですが、初期構成の複雑さが増します。
転送中のデータ暗号化 - AES で暗号化されたデータ
- SSL は、データ転送の暗号化に使用されます。
SSL は、データ転送の暗号化に使用されます。 MI リンクでは、追加のデータ AES 暗号化レイヤーが使用されます。 SSL は、移行ツールのデータ転送に使用されます。
レプリケーションの認証 信頼された機関 (CA) によって署名された証明書 マネージド ID または SAS トークン MI リンクでは、認証のために証明書に署名するために証明機関 (CA) が必要です。 LRS の場合、マネージド ID の使用は、自己生成 SAS トークンを使用するよりも安全です。
システムの更新またはフェールオーバーの影響を受けます いいえ、短いフェールオーバーによる最小限の中断を除いて。 - General Purpose インスタンスの場合、移行は中断後に自動的に一時停止され、再開されます。
- Business Critical インスタンスの場合、移行プロセスは中断のために取り消され、手動で再起動する必要があります。
MI リンクは回復性があり、移行は SQL Managed Instance のフェールオーバーの影響を受けません。

逆に、LRS の移行は、General Purpose サービス レベルの SQL マネージド インスタンスの再起動またはフェールオーバーによって遅延され、Business Critical サービス レベルのインスタンスに対して移行が再開されます。
レプリケーションの期間 リンクを使って無制限にレプリケーションが可能な時間(数か月、さらには数年間)。 LRS ジョブは最大 30 日間実行できます。 MI リンクは、無制限の時間実行できます。

LRS は最大 30 日間の継続的なログ配布に制限されており、その後、移行は自動的に停止され、最初から再起動する必要があります。
移行の種類 短いフェールオーバーのみを使用した真のオンライン移行 (秒単位)。 - カットオーバー中に、想定されるダウンタイム (最後のバックアップ ファイルの復元にかかる時間) を伴うオンライン移行。
- Business Critical サービス レベルでのインスタンスの場合、カットオーバーは大幅に長い時間がかかります。
MI リンクは、すべての SQL Managed Instance サービス レベルの最小ダウンタイム ソリューション (<1 分) を提供する唯一のソリューションです。

LRS では、最後のバックアップ ファイルはカットオーバー中も引き続き復元されるため、最後のバックアップ ファイルのサイズと復元にかかる時間に基づいて、データベースが SQL Managed Instance で使用できるようになるまでかなりの待ち時間が発生する可能性があります。

LRS を使用して Business Critical サービス レベルに移行する場合、データベースがプライマリ上のワークロードで使用できるようになる前に、データベース全体をプライマリ ノードからセカンダリ ノードにレプリケートする必要があり、移行の一括ダウンタイムが大幅に長くなる可能性があります。 データベースの全体的なサイズによっては、他のノードへのレプリケーションが数時間かかることがあり、その間ダウンタイムが発生する場合があります。

そのため、LRSを使用した場合、データベースがオンラインになるまでの時間が大幅に遅くなる可能性があり、MIリンクを使用するとほぼ瞬時にオンラインになります。
ソースで必要なメンテナンス はい。通常のトランザクション ログ バックアップです。 いいえ。 MI リンクでは、トランザクション ログを切り捨て、ディスク領域が不足しないように、移行中にソース SQL Server インスタンスの通常のトランザクション ログ バックアップが必要です。

逆に、LRS のメンテナンスは必要ありません。
回復性 SQL Server が再起動すると、リンク レプリケーションが自動的に再開されます。 - バックアップ チェーンが壊れている場合、または最後のバックアップ ファイルが正しく指定されていない場合、移行がストールします。
- 同じフォルダー内の複数のデータベースからのバックアップ ファイルはサポートされていません (移行は失敗します)。
MI リンクは LRS よりも回復性が高くなります。これは、問題 (予期しないダウンタイム、アップグレード、ネットワーク接続の損失など) が解決された後にレプリケーションが自動的に再開されるためです。 さらに、MI リンクは、SQL MI フェールオーバーまたはサービスの更新に対する回復性があります。

特定の条件において、LRS は停止します。 General Purpose サービス レベルへの移行が中断された場合、LRS の移行は自動的に再起動されますが、Business Critical サービス レベルへの移行が中断された場合は再起動する必要があります。
SQL MI から SQL Server への逆移行 SQL Server 2022 以降へのオフラインおよびオンライン移行がサポートされています。 サポートされていません。 MI リンクは、SQL Server 2022 以降のバージョンへのオンラインおよびオフラインの逆移行を提供する唯一のソリューションです。以前のバージョンの SQL Server では、逆移行を使用できません。

何を選びますか?

LRS と MI リンクの選択は、状況とビジネス ニーズによって異なります。 移行ソリューションの主な違いはパフォーマンスです。 LRS の初期セットアップが簡単になり、迅速に移行できます。 MI リンクの初期構成はより複雑ですが、回復性、セキュリティ、柔軟性が向上します。

さらに、MI リンクによりカットオーバー時間が大幅に短縮され、多くのお客様にとって大きな利点となります。 実際、LRS を使用して Business Critical サービス レベルに移行するときの潜在的に大きいダウンタイムは、MI リンクが Business Critical サービス レベルへの唯一の "真のオンライン" 移行と呼ばれる理由です。

最後に、移行の進行中に移行先の読み取り専用ワークロードでデータベースにアクセスできる必要がある場合、または SQL Server 2022 以降への逆移行を実行する必要がある場合は、MI リンクのみがこれらのシナリオをサポートするオプションです。