投稿日：2025/01/30

はじめに

　オンプレのSQL ServerをAzureのPaaSへ移行する有力な候補としてAzure SQL Managed Instanceが挙げられます。気を付けなければいけないのはAzure SQL Managed Instanceを手動でリストアする際、完全バックアップからしか行えず、差分・ログバックアップではリストアできない点です。
　基本的なバックアップやリストアは前回のブログで紹介していますので、気になる方がいれば見てみてください。

　移行シナリオにおいてダウンタイムを許容できないシステムもあるかと思います。その際、上記の課題を解決する方法として「Azure Database Migration Service」と「Log Replay Service（以降LRSと記載）」が用意されています。

　今回はコマンドベースで差分移行を行える LRS についての調査と検証を紹介します。

LRSの概要

　LRSではSQL Serverのバックアップファイルをリストアできます。これを使用することで、任意の場所で動作するSQL Server（オンプレミスまたは他のクラウド）から、PowerShell・Azure CLI・APIを用いてAzure SQL Managed Instanceへのデータベース移行を手動で構築および調整することが可能です。LRSを使用するケースはこちらの情報を参考にしてください。

LRSのワークフロー

　公式ドキュメントの図がわかりやすいので、以下に貼り付けます。

　まずはSQL Serverからバックアップファイルを取得します。バックアップファイルはBlobストレージに格納します。格納方法としては、SQL Serverから直接格納する方法と、手動で格納する方法の2つがあります。今回の検証では、直接格納する方法を使用します。

　その後、LRSを実行し、LRSがBlobストレージに格納されているバックアップファイルをAzure SQL Managed Instanceに自動的にリストアします。このとき、Azure SQL Managed Instanceに存在するリストア中のデータベースは使用できません。

　最後にリストアが終了すると、LRSの操作を完了し、Azure SQL Managed Instanceのデータベースがオンライン状態に切り替わることで、データベースを使用できるようになります。

　なお、LRSには「オートコンプリートモード」と「連続モード」が存在しますが、今回の検証では「連続モード」を使用します。2つの違いについては、こちらを参考にしてください。

前提条件

　移行をスムーズに行うためには、いくつかの前提条件を確認しておく必要があります。詳細はこちらに記載されていますが、いくつか抜粋します。

SQL Serverの要件

• 完全復旧モデルで運用されていること
• バージョンは2008から2022が対象
• 2008から2016の場合は、ローカル環境でバックアップを作成し、それをBlobストレージにアップロードする必要があります。
• 2016以降はBlobストレージに直接バックアップできます。

Azure環境の要件

• PowerShell Az.SQL モジュール バージョン 4.0.0 以降 ※1
• Blob用に生成された Read と List のアクセス許可が付与されている Shared Access Signature (SAS)

　　※1 今回の検証ではPowerShellを使用しますが、Azure CLIを利用することも可能です。Azure CLIを使用する場合は、Azure CLI バージョン 2.42.0 以降が必要です。

LRSの検証

　今回はLRSの動作確認を行うことが目的ですので、Azure SQL Managed InstanceやBlobのネットワーク設定はパブリックとしています。また、差分移行の確認を行うためのテーブルと資格情報は以下となります。

-- ソース（SQL Server）にて実行
CREATE TABLE LRSCHECK(id int);
INSERT INTO LRSCHECK VALUES(1);

-- ソース（SQL Server）にて実行
CREATE CREDENTIAL [https://lrsblobtest.blob.core.windows.net/lrscontainer] 
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',  
SECRET = '<SASトークン>';

　資格情報が作成できたら、SQL Serverのデータベースのバックアップを取得します。GUI上で操作する場合、対象となるデータベースにて右クリックし、[タスク] > [バックアップ]を選択します。

　バックアップの種類は「完全」とし、バックアップ先としてURLを指定します。AzureストレージコンテナにはURLを指定し、バックアップファイル名は任意の名前で問題ありません。

　GUIで問題なくバックアップファイルが作成されたことを確認した後、Azure SQL Managed InstanceからBlobストレージのバックアップファイルが操作できるかを確認します。ソースと同様に資格情報を作成します（SQLは同一のもののため割愛）。

　次にRESTOREコマンドを使って、バックアップファイルの操作が可能かを確認します。

-- ターゲット（Azure SQL Managed Instance）にて実行
RESTORE HEADERONLY  FROM URL = 'https://lrsblobtest.blob.core.windows.net/lrscontainer/lrstest_full.bak'

　完全バックアップは問題なく作成できているので、新規にデータを1件挿入した後に差分バックアップ・トランザクションログのバックアップを取得してみます。

-- ソース（SQL Server）にて実行
INSERT INTO LRSCHECK VALUES(2);
-- 差分バックアップの取得
INSERT INTO LRSCHECK VALUES(3);
-- トランザクションログのバックアップを取得

　この操作にてBlobストレージには、

• 完全バックアップ（lrstest_full.bak）
• 差分バックアップ（lrstest_diff.bak）
• トランザクションログ（lrstest_log01.trn）
  

の3ファイルが存在する状態となります。

　まず、Azure SQL Managed Instanceが作成されているAzureへサインインします。

-- ソース（SQL Server）にて実行
Login-AzAccount

　次にLRSを開始します。

-- ソース（SQL Server）にて実行
Start-AzSqlInstanceDatabaseLogReplay 
 -ResourceGroupName <リソースグループ名>
 -InstanceName <インスタンス名>
 -Name <リストアするデータベース名>
 -StorageContainerUri "https://lrsblobtest.blob.core.windows.net/lrscontainer" 
 -StorageContainerSasToken <SASトークン>

　LRSの進行状況は、Get-AzSqlInstanceDatabaseLogReplayで確認できます。

-- ソース（SQL Server）にて実行
Get-AzSqlInstanceDatabaseLogReplay
 -ResourceGroupName <リソースグループ名>
 -InstanceName <インスタンス名>
 -Name <リストアするデータベース名>

　特に注目すべき項目は以下の通りです。

• NumberOfFilesQueued ・・・ リストア待ちのファイル数
• NumberOfFilesRestored ・・・ リストア済みのファイル数
• LastUploadedFileName ・・・ リストアに使用した最後のファイル名

　数秒待ってから、再度進行状況を確認してみると全てのファイルがリストアされたことが確認できます。

　LRSは継続的にリストアを行っているので、ターゲットのデータベースは使用することができません。最後にソース側にて追加のログバックアップを取得し、Azure SQL Managed Instanceに適用されるか確認します。

-- ソース（SQL Server）にて実行
INSERT INTO LRSCHECK VALUES(4);
-- トランザクションログのバックアップを取得

　
　この操作にてBlobストレージに新たにトランザクションログ（lrstest_log02.trn）が追加されます。それでは、Get-AzSqlInstanceDatabaseLogReplayでLRSの進行状況を確認してみましょう。

　lrstest_log02.trnの適用が終わったら、ターゲットデータベースをOPENします。LRSの適用完了は、Complete-AzSqlInstanceDatabaseLogReplayを実行します。

-- ソース（SQL Server）にて実行
Complete-AzSqlInstanceDatabaseLogReplay
 -ResourceGroupName <リソースグループ名>
 -InstanceName <インスタンス名>
 -Name <リストアするデータベース名>
 -LastBackupName "lrstest_log02.trn"

　Azure SQL Managed Instanceにて、検証用のテーブルに1から4のデータが格納されているので、差分移行は完了していますね。

まとめ

　完全バックアップのみの一括移行がシンプルかつ安全な移行方法になりますが、システムの停止を許容できないといった要件は多くのお客様が抱えています。

　いかにシステム停止時間を抑えて移行ができるかは今後も求められるものなので、それらを実現可能にするソリューションのキャッチアップだけでなく実機検証は引き続き行っていきたいですね。