Log Replay Service を使用して SQL Server からデータベースを移行する - Azure SQL Managed Instance
適用対象:
Azure SQL Managed Instance
この記事では、ログ再生サービス (LRS)を使用してデータベースを Azure SQL Managed Instance に移行する方法について説明します。 LRS は、SQL Server のログ配布テクノロジに基づく無料のクラウド サービスであり、Azure SQL Managed Instance に利用できます。
次のソースがサポートされています。
- 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)
前提条件
始める前に、SQL Server インスタンスと Azure の両方に関する次の要件を検討してください。
SQL Server
SQL Server に関する次の要件を満たしていることを確認します。
- SQL Server バージョン 2008 から 2022。
- SQL Server データベースで完全復旧モデルを使用していること (必須)。
- データベースの完全バックアップ (1 つまたは複数のファイル)。
- 差分バックアップ (1 つまたは複数のファイル)。
- ログ バックアップ (トランザクション ログ ファイル用に分割されていない)。
- SQL Server バージョン 2008 から 2016 の場合は、ローカル環境でバックアップを作成し、それを Azure Blob Storage アカウントに手動でアップロードします。
- SQL Server 2016 以降では、Azure Blob Storage アカウントに直接バックアップすることができます。
CHECKSUM を有効にすることは、バックアップに関しては必要ありませんが、復元操作を高速にするために強くお勧めします。
Azure
Azure に関する次の要件を満たしていることを確認します。
- PowerShell Az.SQL モジュール バージョン 4.0.0 以降 (インストールされているか、Azure Cloud Shell 経由でアクセスできること)。
- Azure CLI バージョン 2.42.0 以降 (インストールされていること)。
- プロビジョニングされた Azure Blob Storage コンテナー。
- Blob Storage コンテナー用に生成された、読み取りと一覧表示のアクセス許可が付与された Shared Access Signature (SAS) セキュリティ トークン、またはそのコンテナーにアクセスできるマネージド ID。
- 個々のデータベースのバックアップ ファイルを、フラットファイル構造を使用してストレージ アカウント内の個別のフォルダー内に配置する (必須)。 データベース フォルダー内の入れ子になったフォルダーはサポートされていません。
Azure RBAC アクセス許可
指定したクライアントを介して LRS を実行するには、次のいずれかの Azure ロールベースのアクセス制御 (RBAC) のロールが必要です。
- SQL Managed Instance 共同作成者ロール
- 次のアクセス許可を持つロール:
Microsoft.Sql/managedInstances/databases/*
ベスト プラクティス
LRS を使用する場合は、次のベスト プラクティスを考慮します。
- Data Migration Assistant を実行して、データベースを SQL Managed Instance に移行する準備ができていることを確認します。
- 1 つのファイルを使用するのではなく、完全バックアップと差分バックアップを複数のファイルに分割します。
- バックアップ圧縮を有効にして、ネットワーク転送速度を向上させます。
- 最新リリースのコマンドレットを使うように常に更新されるため、PowerShell または CLI スクリプトを実行するには Cloud Shell を使います。
- 特定の日と時刻にシステム更新をスケジュールできるように、メンテナンス期間を構成します。 システムのアップグレードによって進行中の移行が中断される可能性があるため、このように構成するとデータベース移行の時間をいっそう予測しやすくなります。
- 最大 30 日以内に 1 つの LRS 移行ジョブを完了するように計画します。 この期間が終了すると、LRS ジョブは自動的に取り消されます。
- データベースの復元を高速化するため、バックアップの作成時に
CHECKSUMを有効にします。CHECKSUMを使わずに SQL Managed Instance でバックアップの整合性チェックを実行すると、復元時間が長くなります。
SQL Managed Instance のシステム更新は、進行中のデータベース移行より優先されます。 インスタンスでのシステム更新の間は、保留中のすべての LRS 移行が中断され、更新が適用された後でのみ再開されます。 このシステム動作によって、特に大規模なデータベースでは、移行時間が長くなる可能性があります。
データベースの移行の時間を予測できるようにするには、特定の日時にシステムの更新がスケジュールされるようにメンテナンス期間を構成することを検討し、指定したメンテナンス期間外に移行ジョブを実行して完了します。
重要
- 移行プロセスが完了するまで、LRS で復元されているデータベースを使うことはできません。
- 移行中のデータベースに対する読み取り専用アクセスは、LRS ではサポートされていません。
- 移行が完了すると、移行プロセスは確定し、追加の差分バックアップを使用して再開することはできません。
複数のデータベースを移行する
同じ Azure Blob Storage コンテナーを使用して複数のデータベースを移行する場合は、異なるデータベースのバックアップ ファイルをコンテナー内の別々のフォルダーに配置する必要があります。 1 つのデータベースのすべてのバックアップ ファイルを、データベース フォルダー内のフラットファイル構造に配置する必要があり、フォルダーを入れ子にすることはできません。 データベース フォルダー内の入れ子になったフォルダーはサポートされていません。
次に示すのは、Azure Blob Storage コンテナー内のフォルダー構造の例であり、LRS を使用して複数のデータベースを移行するために必要な構造です。
-- Place all backup files for database 1 in a separate "database1" folder in a flat-file structure.
-- Don't use nested folders inside the database1 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database1>/<all-database1-backup-files>
-- Place all backup files for database 2 in a separate "database2" folder in a flat-file structure.
-- Don't use nested folders inside the database2 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database2>/<all-database2-backup-files>
-- Place all backup files for database 3 in a separate "database3" folder in a flat-file structure.
-- Don't use nested folders inside the database3 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database3>/<all-database3-backup-files>
ストレージ アカウントの作成
Azure Blob Storage アカウントは、SQL Server インスタンスと SQL Managed Instance デプロイの間の、バックアップ ファイル用の中間ストレージとして使用します。 新しいストレージ アカウントと、ストレージ アカウント内の BLOB コンテナーを作成するには:
- ストレージ アカウントの作成。
- ストレージ アカウント内に BLOB コンテナーを作成します。
ファイアウォールの内側に Azure Storage を構成する
ファイアウォールの内側で保護されている Azure Blob Storage の使用はサポートされていますが、追加の構成が必要です。 Azure Firewall が有効になっている Azure Storage への読み取りと書き込みのアクセスを有効にするには、MI サブネットの委任とストレージ サービス エンドポイントを使って、ストレージ アカウント用の vNet のファイアウォール規則に、SQL マネージド インスタンスのサブネットを追加する必要があります。 ストレージ アカウントとマネージド インスタンスは、同じリージョン内またはペアになった 2 つのリージョンに存在する必要があります。
Azure Storage がファイアウォールの内側にある場合は、SQL マネージド インスタンスのエラー ログに次のメッセージが記録されることがあります。
Audit: Storage access denied user fault. Creating an email notification:
これにより、SQL マネージド インスタンスの監査でストレージ アカウントへの監査ログの書き込みが失敗したことをユーザーに通知するメールが生成されます。 このエラーが表示された場合、またはこのメールを受け取った場合は、このセクションの手順に従ってファイアウォールを構成します。
ファイアウォールを構成するには、次の手順のようにします。
Azure portal でマネージド インスタンスに移動し、サブネットを選んで [サブネット] ページを開きます。
[サブネット] ページで、サブネットの名前を選んでサブネット構成ページを開きます。
[サブネット委任] で、[サブネットをサービスに委任] ドロップダウン メニューから Microsoft.Sql/managedInstances を選びます。 アクセス許可が反映されるまで約 1 時間待ってから、[サービス エンドポイント] の [サービス] ドロップダウンで Microsoft.Storage を選びます。
次に、Azure portal でお使いのストレージ アカウントに移動し、[セキュリティとネットワーク] で [ネットワーク] を選んだ後、[ファイアウォールと仮想ネットワーク] タブを選びます。
ストレージ アカウントの [ファイアウォールと仮想ネットワーク] タブで、[+ 既存の仮想ネットワークを追加する] を選んで [ネットワークの追加] ページを開きます。
ドロップダウン メニューから適切なサブスクリプション、仮想ネットワーク、マネージド インスタンス サブネットを選んでから [追加] を選び、SQL マネージド インスタンスの仮想ネットワークをストレージ アカウントに追加します。
Blob Storage アカウントに対して認証を行う
Azure Blob Storage アカウントにアクセスするには、SAS トークンまたはマネージド ID を使います。
警告
同じストレージ アカウントで SAS トークンとマネージド ID の両方を並行して使用することはできません。 SAS トークン "または" マネージド ID の "いずれか" を使うことはできますが、両方を使うことはできません。
Blob Storage の LRS 用の SAS 認証トークンを生成する
SAS トークンを使って Azure Blob Storage アカウントにアクセスします。
Azure Blob Storage アカウントは、SQL Server インスタンスと SQL Managed Instance デプロイの間の、バックアップ ファイル用の中間ストレージとして使用できます。 読み取りと一覧表示のアクセス許可のみを持つ、LRS 用の SAS 認証トークンを生成します。 このトークンを使うと、LRS で Blob Storage アカウントにアクセスし、バックアップ ファイルを使ってマネージド インスタンスにそれを復元できます。
トークンを生成するには、次の手順を実行します。
Azure portal で Storage Explorer を開きます。
[BLOB コンテナー] を展開します。
BLOB コンテナーを右クリックして、 [Shared Access Signature の取得] を選択します。
トークンの有効期限までの期間を選択します。 移行中、トークンが確実に有効であるようにします。
トークンのタイム ゾーン (UTC または現地時間) を選択します。
重要
トークンとご利用のマネージド インスタンスのタイム ゾーンが一致していない場合があります。 タイム ゾーンを考慮した適切な有効期間を SAS トークンに確実に設定するようにします。 タイム ゾーンの違いを考慮し、有効期間の FROM 値を移行期間の開始よりかなり前に設定し、TO 値を移行の完了予定よりかなり後に設定します。
読み取りとリストのアクセス許可のみを選択します。
重要
他のアクセス許可は選択しないでください。 行うと、LRS は起動しません。 このセキュリティ要件は仕様です。
［作成］ を選択します
指定した有効期限を持つ SAS 認証が生成されます。 次のスクリーンショットに示すように、URI バージョンのトークンが必要です。
Note
現時点では、保存されているアクセス ポリシーの定義によって設定されたアクセス許可で作成された SAS トークンの使用はサポートされていません。 この手順に従って、SAS トークンに読み取りと一覧表示のアクセス許可を手動で指定します。
SAS トークンからパラメーターをコピーする
SAS トークンまたはマネージド ID を使って、Azure Blob Storage アカウントにアクセスします。
SAS トークンを使用して LRS を開始する前に、その構造を理解しておく必要があります。 生成された SAS トークンの URI は、次の例に示すように、疑問符 (?) で区切られた 2 つの部分で構成されています。
https:// から疑問符 (?) までの前半部分は、LRS への入力として指定する StorageContainerURI パラメーターに使用します。 これにより、データベース バックアップ ファイルが格納されているフォルダーの情報が LRS に提供されます。
疑問符 (?) の後から文字列の終わりまでの後半部分は、StorageContainerSasToken パラメーターです。 この部分が実際の署名付き認証トークンで、指定した期間有効です。 この部分は、必ずしも例のように sp= で始まる必要はありません。 シナリオが異なる場合があります。
次のようにパラメーターをコピーします。
https://から疑問符 (?) の前までのトークンの最初の部分をコピーします。 LRS を始めるとき、PowerShell または Azure CLI のStorageContainerUriパラメーターとしてこれを使います。
トークンの疑問符 (
?) の後から文字列の終わりまでの後半部分をコピーします。 LRS を始めるとき、PowerShell または Azure CLI のStorageContainerSasTokenパラメーターとしてこれを使います。
Note
トークンのどちらの部分をコピーする際も、疑問符 (?) は含めないようにしてください。
マネージド インスタンスのストレージ アクセスを検証する
お使いのマネージド インスタンスで Blob Storage アカウントにアクセスできることを検証します。
最初に、full_0_0.bak などのデータベース バックアップを Azure Blob Storage コンテナーにアップロードします。
次に、マネージド インスタンスに接続し、サンプル テスト クエリを実行して、マネージド インスタンスでコンテナー内のバックアップにアクセスできるかどうかを確認します。
ストレージ アカウントに対する認証に SAS トークンを使用している場合は、<sastoken> を自分の SAS トークンに置き換え、自分のインスタンスで次のクエリを実行します。
CREATE CREDENTIAL [https://mitutorials.blob.core.windows.net/databases]
WITH IDENTITY = 'SHARED ACCESS SIGNATURE'
, SECRET = '<sastoken>'
RESTORE HEADERONLY
FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/full_0_0.bak'
Blob Storage アカウントにバックアップをアップロードする
BLOB コンテナーの準備が整い、マネージド インスタンスでそのコンテナーにアクセスできることを確認したら、Blob Storage アカウントへのバックアップのアップロードを開始できます。 次のいずれかを実行できます。
- Blob Storage アカウントにバックアップをコピーします。
- 環境で許される場合は (SQL Server バージョン 2012 SP1 CU2 および SQL Server 2014 以降)、BACKUP TO URL コマンドを使って、SQL Server から Blob Storage アカウントにバックアップを直接作成します。
既存のバックアップを Blob Storage アカウントにコピーする
以前のバージョンの SQL Server を使っている場合、またはお使いの環境で URL への直接バックアップがサポートされていない場合は、通常どおり、SQL Server インスタンスでバックアップを作成し、それを Blob Storage アカウントにコピーします。
SQL Server インスタンスでバックアップを作成する
完全復旧モードに移行するデータベースを、ログ バックアップを許可するように設定します。
-- To permit log backups, before the full database backup, modify the database to use the full recovery
USE master
ALTER DATABASE SampleDB
SET RECOVERY FULL
GO
ローカル ストレージへのデータベースの完全バックアップ、差分バックアップ、ログ バックアップを手動で作成するには、以下の T-SQL サンプル スクリプトを使用します。 CHECKSUM は必須ではありませんが、お勧めします。
次の例では、データベースの完全バックアップをローカル ディスクに作成します。
-- Take full database backup to local disk
BACKUP DATABASE [SampleDB]
TO DISK='C:\BACKUP\SampleDB_full.bak'
WITH INIT, COMPRESSION, CHECKSUM
GO
次の例では、データベースの差分バックアップをローカル ディスクに作成します。
-- Take differential database backup to local disk
BACKUP DATABASE [SampleDB]
TO DISK='C:\BACKUP\SampleDB_diff.bak'
WITH DIFFERENTIAL, COMPRESSION, CHECKSUM
GO
次の例では、データベースのトランザクション ログ バックアップをローカル ディスクに作成します。
-- Take transactional log backup to local disk
BACKUP LOG [SampleDB]
TO DISK='C:\BACKUP\SampleDB_log.trn'
WITH COMPRESSION, CHECKSUM
GO
バックアップを Blob Storage アカウントにコピーする
バックアップの準備が整い、LRS を使用してマネージド インスタンスへのデータベースの移行を開始できるようになったら、次の方法を使って、既存のバックアップを Blob Storage アカウントにコピーできます。
- AzCopy をダウンロードしてインストールします。
- Azure Storage Explorer をダウンロードしてインストールします。
- Azure portal で Storage Explorer を使います。
Note
同じ Azure Blob Storage コンテナーを使用して複数のデータベースを移行するには、個々のデータベースのすべてのバックアップ ファイルをコンテナー内の別のフォルダーに配置します。 各データベース フォルダーにはフラット ファイル構造を使います。 データベース フォルダー内の入れ子になったフォルダーはサポートされていません。
Blob Storage アカウントに直接バックアップする
サポートされているバージョンの SQL Server を使用しており (SQL Server 2012 SP1 CU2 および SQL Server 2014 以降)、企業およびネットワーク ポリシーで許可されている場合は、SQL Server ネイティブの BACKUP TO URL オプションを使って、SQL Server から Blob Storage アカウントに直接バックアップすることができます。 BACKUP TO URL を使用できる場合は、バックアップをローカル ストレージに作成してそれを Blob Storage アカウントにアップロードする必要はありません。
ネイティブのバックアップを Blob Storage アカウントに直接作成するときは、ストレージ アカウントに対する認証を行う必要があります。
次のコマンドを使用して、SAS トークンを SQL Server インスタンスにインポートする資格情報を作成します。
CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<containername>]
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
SECRET = '<SAS_TOKEN>';
SAS トークンを使用する詳細な手順については、Azure Blob Storage と SQL Server の使用に関するチュートリアルを参照してください。
Blob Storage で SQL Server インスタンスを認証するための資格情報を作成したら、BACKUP TO URL コマンドを使用してストレージ アカウントに直接バックアップできます。 CHECKSUM は推奨されますが、必須ではありません。
次の例では、データベースの完全バックアップを URL に作成します。
-- Take a full database backup to a URL
BACKUP DATABASE [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_full.bak'
WITH INIT, COMPRESSION, CHECKSUM
GO
次の例では、データベースの差分バックアップを URL に作成します。
-- Take a differential database backup to a URL
BACKUP DATABASE [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_diff.bak'
WITH DIFFERENTIAL, COMPRESSION, CHECKSUM
GO
次の例では、データベースのトランザクション ログ バックアップを URL に作成します。
-- Take a transactional log backup to a URL
BACKUP LOG [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_log.trn'
WITH COMPRESSION, CHECKSUM
Azure にサインインしてサブスクリプションを選択する
次の PowerShell コマンドレットを使って Azure にサインインします。
Login-AzAccount
次の PowerShell コマンドレットを使って、マネージド インスタンスが存在するサブスクリプションを選びます。
Select-AzSubscription -SubscriptionId <subscription ID>
移行を開始する
移行を開始するには、LRS を開始します。 サービスは "オートコンプリート" または "連続" モードで開始できます。
オートコンプリート モードを使用する場合、指定した最後のバックアップ ファイルが復元されると、移行が自動的に完了します。 このオプションでは、バックアップ チェーン全体を事前に使用でき、Blob Storage アカウントにアップロードできる必要があります。 移行の進行中に新しいバックアップ ファイルを追加することはできません。 このオプションでは、最後のバックアップ ファイルのファイル名を start コマンドで指定する必要があります。 データのキャッチアップが必要ないパッシブ ワークロードの場合は、このモードをお勧めします。
連続モードを使うと、サービスは Azure Blob Storage フォルダーを継続的にスキャンし、移行の進行中に追加される新しいバックアップ ファイルを復元します。 移行は、手動一括移行が要求された後でのみ完了します。 バックアップ チェーン全体が事前に存在しない場合や、移行の進行中に新しいバックアップ ファイルを追加する予定がある場合は、連続モードの移行を使用する必要があります。 データのキャッチアップが必要なアクティブ ワークロードの場合は、このモードをお勧めします。
最大 30 日以内に 1 つの LRS 移行ジョブを完了するように計画します。 この時間が経過すると、LRS ジョブは自動的に取り消されます。
Note
複数のデータベースを移行する場合、LRS は、データベースごとに個別に開始され、Azure Blob Storage コンテナーと個々のデータベース フォルダーの完全な URI パスを指す必要があります。
LRS をオートコンプリート モードで開始する
バックアップ チェーン全体が Azure Blob Storage アカウントにアップロードされていることを確認します。 このオプションでは、移行の進行中に新しいバックアップ ファイルを追加することはできません。
LRS をオートコンプリート モードで開始するには、PowerShell または Azure CLI コマンドを使用します。 -LastBackupName パラメーターを使用して、最後のバックアップ ファイル名を指定します。 最後に指定されているバックアップ ファイルの復元が完了すると、サービスは自動的に一括移行を開始します。
SAS トークンまたはマネージド ID を使って、データベースをストレージ アカウントから復元します。
重要
- オートコンプリート モードで移行を始める前に、バックアップ チェーン全体が Azure Blob Storage アカウントにアップロードされていることを確認します。 このモードでは、移行の進行中に新しいバックアップ ファイルを追加することはできません。
- 最後のバックアップ ファイルが正しく指定されていることと、その後にさらにファイルがアップロードされていないことを確認します。 最後に指定したバックアップ ファイル以降のバックアップ ファイルがシステムによって検出された場合、移行は失敗します。
次の PowerShell の例では、SAS トークンを使ってオートコンプリート モードで LRS を開始します。
Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName" `
-Collation "SQL_Latin1_General_CP1_CI_AS" `
-StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
-StorageContainerSasToken "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D" `
-AutoCompleteRestore `
-LastBackupName "last_backup.bak"
次の Azure CLI の例では、SAS トークンを使ってオートコンプリート モードで LRS を開始します。
az sql midb log-replay start -g mygroup --mi myinstance -n mymanageddb -a --last-bn "backup.bak"
--storage-uri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>"
--storage-sas "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"
LRS を連続モードで開始する
初期バックアップ チェーンを Azure Blob Storage アカウントにアップロードしたことを確認します。
重要
連続モードで LRS を開始した後は、手動一括移行を行うまで、新しいログと差分バックアップをストレージ アカウントに追加できます。 手動一括移行が開始された後では、追加の差分ファイルを追加することも、復元することもできません。
次の PowerShell の例では、SAS トークンを使って連続モードで LRS を開始します。
Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName" `
-Collation "SQL_Latin1_General_CP1_CI_AS" -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
-StorageContainerSasToken "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"
次の Azure CLI 例では、連続モードで LRS を開始します。
az sql midb log-replay start -g mygroup --mi myinstance -n mymanageddb
--storage-uri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>"
--storage-sas "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"
移行ジョブのスクリプトを作成する
連続モードで LRS を開始する PowerShell と Azure CLI クライアントは同期方式です。 このモードの PowerShell と Azure CLI は、API の応答で成功または失敗が報告されるまで待ってから、ジョブを開始します。
この待機中、制御は、コマンドによってコマンド プロンプトに戻されません。 移行操作のスクリプトを作成していて、スクリプトの残りを続行するために、LRS の start コマンドですぐに制御を戻す必要がある場合は、-AsJob スイッチを使って PowerShell をバックグラウンド ジョブとして実行できます。 次に例を示します。
$lrsjob = Start-AzSqlInstanceDatabaseLogReplay <required parameters> -AsJob
バックグラウンド ジョブを開始すると、ジョブが終了するまでに時間がかかる場合でも、ジョブ オブジェクトがすぐに返されます。 ジョブの実行中は、中断されることなく引き続きセッションで作業できます。 PowerShell をバックグラウンド ジョブとして実行する方法の詳細については、PowerShell Start-Job に関するドキュメントを参照してください。
同様に、Linux 上で Azure CLI コマンドをバックグラウンド プロセスとして開始するには、LRS start コマンドの最後にアンパサンド (&) 記号を使用します。
az sql midb log-replay start <required parameters> &
移行の進行状況を監視する
Az.SQL 4.0.0 以降では、詳細な進行状況レポートが提供されます。 サンプル出力については、「マネージド データベースの復元の詳細 - Get」を参照してください。
PowerShell を使用して移行の進行状況を監視するには、次のコマンドを使用します。
Get-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName"
Azure CLI を使用して移行の進行状況を監視するには、次のコマンドを使用します。
az sql midb log-replay show -g mygroup --mi myinstance -n mymanageddb
移行を停止する (省略可能)
移行を停止する必要がある場合は、PowerShell または Azure CLI を使います。 移行を停止すると、マネージド インスタンスで復元しているデータベースが削除されるため、移行を再開することはできません。
PowerShell を使用して移行プロセスを停止するには、次のコマンドを使用します。
Stop-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName"
Azure CLI を使用して移行プロセスを停止するには、次のコマンドを使用します。
az sql midb log-replay stop -g mygroup --mi myinstance -n mymanageddb
移行を完了する (連続モード)
LRS を連続モードで開始する場合は、新しいバックアップ ファイルが生成されないように、アプリケーションと SQL Server ワークロードが停止していることを確認します。 SQL Server インスタンスからの最後のバックアップが Azure Blob Storage アカウントにアップロードされていることを確認します。 マネージド インスタンスで復元の進行状況を監視し、最後のログ末尾のバックアップが復元されたことを確認します。
マネージド インスタンスで最後のログ末尾のバックアップが復元されたら、手動一括移行を開始して移行を完了します。 一括移行が完了すると、データベースはマネージド インスタンスで読み取りおよび書き込みアクセスができるようになります。
PowerShell を使用して LRS 連続モードで移行プロセスを完了するには、次のコマンドを使用します。
Complete-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName" `
-LastBackupName "last_backup.bak"
Azure CLI を使用して LRS 連続モードで移行プロセスを完了するには、次のコマンドを使用します。
az sql midb log-replay complete -g mygroup --mi myinstance -n mymanageddb --last-backup-name "backup.bak"
LRS の問題のトラブルシューティング
LRS を開始した後は、次のいずれかの監視コマンドレットを使って、操作の状態を確認します。
- PowerShell の場合:
get-azsqlinstancedatabaselogreplay - Azure CLI の場合:
az_sql_midb_log_replay_show
しばらくしても LRS が開始できず、エラーが発生する場合は、最も一般的な問題をご確認ください。
- マネージド インスタンス上の既存のデータベースの名前は、SQL Server インスタンスから移行しようとしているものと同じですか? この競合を解決するには、一方のデータベースの名前を変更します。
- SAS トークンには、読み取りと一覧表示のアクセス許可 "のみ" が付与されていますか?
- コピーした LRS の SAS トークンは、疑問符 (
?) の後のsv=2020-02-10...のような内容でしたか? - SAS トークンの有効期間は、移行の開始と完了の時間枠に対して有効ですか? SQL Managed Instance のデプロイと SAS トークンで、使われているタイム ゾーンが異なるため、一致していない可能性があります。 時間枠のトークンの有効期間を現在の日付より前および後に拡張して、SAS トークンを再生成してみてください。
- 同じストレージ コンテナーをターゲットにして複数のログ再生の復元を並列で開始する場合は、復元操作ごとに同じ有効な SAS トークンが提供されていることを確認します。
- データベース名、リソース グループ名、マネージド インスタンス名のスペルは正しいですか?
- LRS をオートコンプリート モードで開始した場合、最後のバックアップ ファイルに有効なファイル名を指定しましたか?
- バックアップ URI パスにキーワード
backupまたはbackupsが含まれていますか?backupまたはbackupsは予約済みキーワードであるため、使用しているコンテナーまたはフォルダーの名前を変更します。
次のステップ
- リンク機能を使用した Azure SQL Managed Instance への移行についての詳細を理解します。
- SQL Server から Azure SQL Managed Instance への移行についての詳細を理解します。
- SQL Server と SQL Managed Instance の違いについての詳細を理解します。
- Azure に移行するワークロードのコストとサイズ設定のベスト プラクティスについて学ぶ。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示