Azure SQL Managed Instance での Log Replay Service の概要

[アーティクル]
04/08/2024

この記事では、SQL Server から Azure SQL Managed Instance へのデータベースの移行に使用できる、Log Replay Service (LRS) の概要について説明します。 LRS は、Azure SQL Managed Instance で使用できる無料のクラウドサービスであり、SQL Server のログ配布テクノロジに基づいています。

LRS では標準の SQL Server バックアップファイルが復元されるため、これを使用して、任意の場所でホストされている SQL Server (オンプレミスまたは任意のクラウド) から Azure SQL Managed Instance に移行できます。

LRS を使用して移行を開始するには、「Log Replay Service を使用して SQL Server からデータベースを移行する」を参照してください。

Log Replay Service を使用する場合

Azure Database Migration Service、Azure Data Studio 用の Azure SQL 移行拡張機能、および LRS で使用される、基になる移行テクノロジと API はすべて同じです。 LRS を使うと、オンプレミスの SQL Server インスタンスと SQL Managed Instance のデプロイ間で複雑なカスタム移行とハイブリッドアーキテクチャをさらに有効にすることができます。

Azure Database Migration Service または移行用の Azure SQL 拡張機能を使用できない場合、PowerShell、Azure CLI コマンドレット、または API で LRS を直接使用して、SQL Managed Instance へのデータベース移行を手動で構築および調整できます。

次の場合に LRS の使用を検討してください。

データベース移行プロジェクトでより高度な制御が必要。
移行カットオーバーで許容されるダウンタイムの範囲が少ない。
使用環境に Database Migration Service の実行可能ファイルをインストールできない。
Database Migration Service の実行可能ファイルに、データベースのバックアップへのファイルアクセス権がない。
Azure SQL 移行拡張機能は、自分の環境にはインストールできず、データベースのバックアップにもアクセスできません。
ホストオペレーティングシステムにアクセスできない、または管理者特権がない。
使用環境から Azure にネットワークポートを開くことができない。
環境に、ネットワーク調整、またはプロキシに関して障害となっている問題が存在する。
バックアップが、TO URL オプションを通じて Azure Blob Storage アカウントに直接保存されている。
差分バックアップを使用する必要がある。

LRS は標準の SQL Server バックアップファイルを復元することによって機能するため、任意のソースからの移行をサポートする必要があります。テストが完了しているソースは次のとおりです。

オンプレミスの SQL Server/box
SQL Server on Virtual Machines
Amazon EC2 (Elastic Compute Cloud)
SQL Server 用 Amazon RDS (Relational Database Service)
Google Compute Engine
Cloud SQL for SQL Server - GCP (Google Cloud Platform)
Alibaba Cloud RDS for SQL Server

リストにないソースからの移行で予期しない問題が発生した場合は、サポートチケットを開いてサポートを受けてください。

Note

SQL Server から Azure SQL Managed Instance へのデータベースの移行の自動化には、Azure Data Studio 用の Azure SQL 移行拡張機能を使用することをお勧めします。ご自身のシナリオが Azure SQL 移行拡張機能では完全にサポートされない場合は、LRS を使用して移行を調整することを検討してください。
LRS は、マネージドインスタンスで差分バックアップを復元する唯一の方法です。マネージドインスタンスで差分バックアップを手動で復元したり、T-SQL を使用して NORECOVERY モードを手動で設定したりすることはできません。

LRS のしくみ

LRS を使用してクラウドにデータベースを移行するカスタムソリューションを構築するには、このセクションで後述する図と表に示されているオーケストレーション手順を実行する必要があります。

移行は、SQL Server でのデータベースバックアップの作成と、Azure Blob Storage アカウントへのバックアップファイルのコピーで構成されます。完全、ログ、差分のバックアップがサポートされています。その後、LRS クラウドサービスを使って、バックアップファイルを Azure Blob Storage アカウントから SQL Managed Instance に復元します。 Blob Storage アカウントは、SQL Server と SQL Managed Instance 間のバックアップファイルの中間ストレージとして機能します。

LRS によって、Blob Storage アカウントで完全バックアップが復元された後に追加された新しい差分またはログバックアップが監視されます。これらの新しいファイルは、LRS によって自動的に復元されます。このサービスを使用すると、SQL Managed Instance へと復元中のバックアップファイルの進行状況を監視し、必要に応じてプロセスを停止することができます。

LRS では、バックアップファイル固有の名前付け規則は必要ありません。 Azure Blob Storage アカウントに配置されるすべてのファイルがスキャンされ、ファイルヘッダーのみを読み取ってバックアップチェーンが構築されます。データベースは、移行プロセス中は復元中状態になります。データベースは NORECOVERY モードで復元されるため、移行プロセスが完了するまで読み取りまたは書き込みワークロードに使用することはできません。

複数のデータベースを移行する場合は、次のことを行う必要があります。

各データベースのバックアップファイルを、フラットファイル構造の Blob Storage アカウント上の個別のフォルダーに配置します。たとえば、blobcontainer/database1/files、blobcontainer/database2/files などの個別のデータベースフォルダーを使用します。
入れ子になったフォルダー構造はサポートされていないため、データベースフォルダー内の入れ子になったフォルダーは使用しないでください。たとえば、blobcontainer/database1/subfolder/files などのサブフォルダーは使用しないでください。
データベースごとに LRS を個別に開始します。
異なる URI パスを指定して、Blob Storage アカウント上のデータベースフォルダーを分離します。

バックアップに対して CHECKSUM を有効にする必要はありませんが、強くお勧めします。 CHECKSUM なしでのデータベースの復元には時間がかかります。SQL Managed Instance では、CHECKSUM を有効にしないで復元されるバックアップに対して整合性チェックが実行されるためです。

詳細については、「Log Replay Service を使用した SQL Server から SQL Managed Instance へのデータベースの移行」を参照してください。

注意事項

CHECKSUM を有効にしない場合、破損したデータベースを Azure に復元してしまうリスクがあるため、有効にして SQL Server にバックアップを作成することを強くお勧めします。

オートコンプリートと連続モードの移行

LRS は "オートコンプリート" または "連続" モードで開始できます。

事前にバックアップチェーン全体が生成されている場合や、移行が開始された後にファイルを追加する予定がない場合は、"オートコンプリート" モードを使用します。この移行モードは、データのキャッチアップを必要としないパッシブワークロードに推奨されます。すべてのバックアップファイルを Blob Storage アカウントにアップロードし、オートコンプリートモードの移行を開始します。指定した最後のバックアップファイルが復元されると、移行は自動的に完了します。移行されたデータベースは、SQL Managed Instance 上での読み取りと書き込みアクセスができるようになります。

移行の進行中に新しいバックアップファイルを追加し続ける予定がある場合は、"連続" モードを使用します。データのキャッチアップが必要なアクティブワークロードの場合は、このモードをお勧めします。現在使用可能なバックアップチェーンを Blob Storage アカウントにバックアップし、連続モードで移行を開始し、必要に応じてワークロードから新しいバックアップファイルの追加を続けます。システムは定期的に Azure Blob Storage フォルダーをスキャンし、見つかった新しいログまたは差分バックアップファイルを復元します。

一括移行の準備ができたら、SQL Server インスタンスでワークロードを停止し、最後のバックアップファイルを生成した後、アップロードします。最後のログテールバックアップが SQL Managed Instance で復元済みとして表示されていることを確認することで、最後のバックアップファイルが復元されたことを確認します。次に、手動一括移行を開始します。最後の一括移行ステップによって、データベースがオンラインになり、SQL Managed Instance 上での読み取りと書き込みアクセスができるようになります。

オートコンプリートによって自動で、またはカットオーバーによって手動で LRS が停止されると、SQL Managed Instance でオンラインにされたデータベースの復元プロセスは再開できなくなります。たとえば、移行が完了すると、オンラインデータベースの追加の差分バックアップを復元できなくなります。移行の完了後、さらにバックアップファイルを復元するには、マネージドインスタンスからデータベースを削除し、移行を最初からやり直す必要があります。

移行のワークフロー

一般的な移行ワークフローを次の図に示し、大まかなステップを表に示します。

オートコンプリートモードは、すべてのバックアップチェーンファイルが事前に使用できる場合にのみ使用する必要があります。データのキャッチアップが必要ないパッシブワークロードの場合は、このモードをお勧めします。

バックアップチェーン全体が事前に存在しない場合や、移行の進行中に新しいバックアップファイルを追加する予定がある場合は、連続モードの移行を使用してください。データのキャッチアップが必要なアクティブワークロードの場合は、このモードをお勧めします。

SQL Managed Instance に対して行われる Log Replay Service によるオーケストレーション手順を示す図。

操作	詳細
1. SQL Server インスタンスから Blob Storage アカウントにデータベースバックアップをコピーします。	AzCopy または Azure Storage Explorer を使用して、完全バックアップ、差分バックアップ、ログバックアップを SQL Server インスタンスから Blob Storage コンテナーにコピーします。任意のファイル名を使用します。 LRS では固有のファイル名前付け規則は必要ありません。複数のデータベースを移行する場合は、データベースごとに個別のフォルダーを使います。
2.クラウドで LRS を開始します。	サービスを起動するには、PowerShell (start-azsqlinstancedatabaselogreplay) または Azure CLI (az_sql_midb_log_replay_start cmdlets) を使います。オートコンプリートと連続のどちらかの移行モードを選択します。 Blob Storage アカウント上のバックアップフォルダーを指す各データベースで、LRS を個別に開始します。サービスが開始すると、Blob Storage コンテナーからバックアップを取得し、それらの SQL Managed Instance への復元を開始します。オートコンプリートモードで開始すると、LRS は指定された最後のバックアップファイルまですべてのバックアップを復元します。すべてのバックアップファイルを事前にアップロードする必要があり、移行の進行中に新しいバックアップファイルを追加することはできません。このモードは、データのキャッチアップが必要ないパッシブワークロードに推奨されます。連続モードで開始すると、LRS により、最初にアップロードされたすべてのバックアップが復元され、その後はフォルダーにアップロードされた新しいファイルが監視されます。サービスを手動で停止するまで、ログシーケンス番号 (LSN) チェーンに基づいてログが連続して適用されます。データのキャッチアップが必要なアクティブワークロードの場合は、このモードをお勧めします。
2.1. 操作の進行状況を監視する。	実行中の復元操作の進行状況を監視するには、PowerShell (get-azsqlinstancedatabaselogreplay) または Azure CLI (az_sql_midb_log_replay_show cmdlets) を使います。失敗した要求に関する追加の詳細を追跡するには、PowerShell コマンド Get-AzSqlInstanceOperation または Azure CLI コマンド az sql mi op show を使用します。
2.2. 必要に応じて操作を停止する (省略可能)。	移行プロセスを停止する必要がある場合は、PowerShell (stop-azsqlinstancedatabaselogreplay) または Azure CLI (az_sql_midb_log_replay_stop) を使います。操作を停止すると、SQL Managed Instance で復元しようとしているデータベースが削除されます。操作を停止した後に、データベースの LRS を再開することはできません。移行プロセスを最初からやり直す必要があります。
3.準備ができたら、クラウドにカットオーバーします。	LRS をオートコンプリートモードで開始した場合、指定した最後のバックアップファイルが復元されると、移行は自動的に完了します。 LRS が連続モードで開始した場合は、アプリケーションとワークロードを停止します。ログ末尾の最後のバックアップを取得し、Azure Blob Storage デプロイにアップロードします。マネージドインスタンスで最後のログ末尾のバックアップが復元されていることを確認します。カットオーバーを完了するには、PowerShell (complete-azsqlinstancedatabaselogreplay) または Azure CLI (az_sql_midb_log_replay_complete) を使って LRS `complete` 操作を開始します。この操作によって LRS が停止し、データベースがオンラインになり、SQL Managed Instance 上でのワークロードの読み取りと書き込みが可能になります。アプリケーションの接続文字列を SQL Server インスタンスから SQL Managed Instance へと再設定します。このステップは、アプリケーションの接続文字列を手動で変更するか、自動的に変更する (たとえば、アプリケーションでプロパティやデータベースの接続文字列を読み取ることができる場合など) というように、自分で調整する必要があります。

重要

カットオーバーの後、Business Critical サービスレベルでの SQL Managed Instance は、可用性グループに対して 3 つのセカンダリレプリカをシードする必要があるため、利用可能になるまでに General Purpose よりかなり時間がかかることがあります。操作時間は、データのサイズによって異なります。詳細については、管理操作の所要時間に関するセクションを参照してください。

大規模なデータベースの移行

サイズが数テラバイトの大きなデータベースを移行する場合は、次の点を考慮してください。

1 つの LRS ジョブは、最大 30 日間実行できます。この期間が経過すると、ジョブは自動的に取り消されます。
実行時間の長いジョブの場合、システムの更新によって移行ジョブが中断され、延長されます。メンテナンス期間を使用して、計画されたシステム更新をスケジュールすることを強くお勧めします。スケジュールされたメンテナンス期間を中心に移行を計画します。
システム更新によって中断された移行ジョブは、General Purpose マネージドインスタンスでは自動的に一時停止して再開され、Business Critical マネージドインスタンスでは再起動されます。これらの更新は、移行の期間に影響します。
Blob Storage アカウントへの SQL Server バックアップファイルのアップロード速度を上げるには、インフラストラクチャに十分なネットワーク帯域幅がある場合は、複数のスレッドによる並列化を使用することを検討してください。

移行を開始する

移行を開始するには、LRS を起動します。サービスはオートコンプリートまたは連続モードで開始できます。具体的な詳細については、LRS を使用した移行に関する記事をご覧ください。

オートコンプリートモード。オートコンプリートモードを使用する場合、指定した最後のバックアップファイルが復元されると、移行が自動的に完了します。このオプションの特徴:
- バックアップチェーン全体が事前に使用でき、Azure Blob Storage アカウントにアップロードできる必要があります。
- 移行の進行中に新しいバックアップファイルを追加することはできません。
- start コマンドに最後のバックアップファイルのファイル名を指定する必要があります。
データのキャッチアップが必要ないパッシブワークロードの場合は、オートコンプリートモードの使用をお勧めします。
連続モード。連続モードを使うと、サービスは Azure Blob Storage フォルダーを継続的にスキャンし、移行の進行中に追加される新しいバックアップファイルを復元します。

移行は、手動一括移行が要求された後でのみ完了します。

バックアップチェーン全体が事前に存在しない場合や、移行の進行中に新しいバックアップファイルを追加する予定がある場合は、連続モードの移行を使用する必要があります。

データのキャッチアップが必要なアクティブワークロードの場合は、連続モードの使用をお勧めします。

最大 30 日以内に 1 つの LRS 移行ジョブを完了するように計画します。この期間が経過すると、LRS ジョブは自動的に取り消されます。

Note

複数のデータベースを移行する場合、Azure Blob Storage コンテナーと個々のデータベースフォルダーの完全な URI パスを指すデータベースごとに、LRS を個別に開始する必要があります。

LRS の制限事項

LRS の次の制限事項を考慮します。

LRS では、データベースの .bak、.log、および .diff ファイルのみがサポートされています。 dacpac ファイルと bacpac ファイルはサポートされていません。
移行プロセスの最中は、移行中のデータベースを SQL Managed Instance 上での読み取り専用アクセスで使用することはできません。
特定の日と時刻にシステム更新をスケジュールできるように、メンテナンス期間を構成する必要があります。スケジュールされたメンテナンス期間外に移行の実行と完了を計画します。
CHECKSUM なしで作成されたデータベースバックアップの復元は、CHECKSUM が有効なデータベースバックアップより時間がかかります。
LRS によって使用される Shared Access Signature (SAS) トークンは Azure Blob Storage コンテナー全体に対して生成される必要があり、読み取りと一覧表示のアクセス許可のみが付与されている必要があります。たとえば、読み取り、一覧表示、書き込みのアクセス許可を付与した場合、余計な書き込みアクセス許可が原因で LRS を開始できません。
保存されているアクセスポリシーの定義によって設定されたアクセス許可を使用して作成された SAS トークンの使用はサポートされていません。この記事の指示に従って、SAS トークンの読み取りと一覧表示のアクセス許可を手動で指定してください。
異なるデータベースのバックアップファイルは、Blob Storage アカウント上の個別のフォルダーにフラットファイル構造で配置する必要があります。データベースフォルダー内の入れ子になったフォルダーはサポートされていません。
オートコンプリートモードを使用する場合は、Blob Storage アカウントでバックアップチェーン全体を事前に使用できる必要があります。オートコンプリートモードで新しいバックアップファイルを追加することはできません。移行の進行中に新しいバックアップファイルを追加する必要がある場合は、連続モードを使用します。
LRS は、個々のデータベースフォルダーを含む完全な URI パスを指すデータベースごとに個別に開始する必要があります。
backup または backups は予約済みのキーワードであるため、バックアップ URI パス、コンテナー名、またはフォルダー名に含めることはできません。
同じストレージコンテナーをターゲットにして複数のログ再生の復元を並列で開始する場合は、復元操作ごとに同じ有効な SAS トークンが提供されていることを確認します。
LRS は、1 つのマネージドインスタンスごとに最大 100 個の同時復元プロセスをサポートできます。
1 つの LRS ジョブは最大 30 日間実行でき、その後は自動的に取り消されます。
ファイアウォールの内側の Azure ストレージアカウントを使うことはできますが、追加の構成が必要であり、ストレージアカウントとマネージドインスタンスが、同じリージョン内またはペアになった 2 つのリージョンに存在する必要があります。詳しくは、ファイアウォールの構成に関する記事をご覧ください。
並行して復元できるデータベースの最大数は、1 つのサブスクリプションにつき 200 個です。サポートチケットを開くことで、この制限を引き上げることができる場合があります。

ヒント

移行を実行するためのはるかに長い概算時間と最小限のダウンタイムで、移行中にデータベースを読み取り専用アクセス可能にする必要がある場合は、推奨される移行ソリューションとして Azure SQL Managed Instance リンク機能の使用を検討してください。

次の手順

詳細については、「Log Replay Service を使用した SQL Server から SQL Managed Instance へのデータベースの移行」を参照してください。
リンク機能を使用した SQL Managed Instance へのデータベースの移行についての詳細を確認してください。
SQL Server から SQL Managed Instance へのデータベースの移行についての詳細を確認してください。
SQL Server と SQL Managed Instance の違いについての詳細を理解します。
Azure に移行するワークロードのコストとサイズ設定のベストプラクティスについて詳しく学習します。

次の方法で共有