適用対象:
Azure SQL Managed Instance
この記事では、SQL Server から Azure SQL Managed Instance へのデータベースの移行に使用できる、Log Replay Service (LRS) の概要について説明します。 LRS は、Azure SQL Managed Instance で利用できる無料のクラウド サービスであり、SQL Server ログ配布テクノロジに基づいています。
注
Azure Arc によって有効になっている SQL Server インスタンスを、Azure portal から直接 Azure SQL Managed Instance に移行できるようになりました。 詳細については、「 Azure SQL Managed Instance への移行」を参照してください。
LRS は標準の SQL Server バックアップ ファイルを復元するため、それを使用して、任意の場所 (オンプレミスまたは任意のクラウド) で ホストされている SQL Server から Azure SQL Managed Instance に移行できます。
LRS を使用して移行を開始するには、 ログ再生サービスを使用して SQL Server からのデータベースの移行を確認します。
重要
データベースを Business Critical サービス レベルに移行する前に、General Purpose サービス レベルには適用されないこれらの制限事項を検討してください。
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/ボックス
- 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)
- アリババクラウドRDS for SQL Server
リストにないソースからの移行で予期しない問題が発生した場合は、サポート チケットを開いてサポートを受けてください。
注
- LRS は、SQL マネージド インスタンスで差分バックアップを復元する唯一の方法です。 マネージド インスタンスで差分バックアップを手動で復元したり、T-SQL を使用して
NORECOVERYモードを手動で設定したりすることはできません。
LRS のしくみ
LRS を使用してクラウドにデータベースを移行するカスタム ソリューションを構築するには、このセクションで後述する図と表に示されているオーケストレーション手順を実行する必要があります。
移行は、SQL Server でのデータベース バックアップの作成と、Azure Blob Storage アカウントへのバックアップ ファイルのコピーで構成されます。 LRS では、完全バックアップ、ログ バックアップ、差分バックアップがサポートされます。 その後、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 アカウントに配置されるすべてのファイルがスキャンされ、ファイル ヘッダーのみを読み取ってバックアップ チェーンが構築されます。 データベースは、移行プロセス中は復元中状態になります。 LRS は NORECOVERY モードでデータベースを復元するため、移行プロセスが完了するまで読み取りまたは書き込みのワークロードには使用できません。
複数のデータベースを移行する場合は、次のことを行う必要があります。
- 各データベースのバックアップ ファイルを、フラットファイル構造の Blob Storage アカウント上の個別のフォルダーに配置します。 たとえば、blobcontainer/database1/files、blobcontainer/database2/files などの個別のデータベース フォルダーを使用します。
- 入れ子になったフォルダー構造はサポートされていないため、データベース フォルダー内の入れ子になったフォルダーは使用しないでください。 たとえば、blobcontainer/database1/subfolder/files などのサブフォルダーは使用しないでください。
- データベースごとに LRS を個別に開始します。
- 異なる URI パスを指定して、Blob Storage アカウント上のデータベース フォルダーを分離します。
バックアップに対して CHECKSUM を有効にする必要はありませんが、強くお勧めします。
CHECKSUM なしでのデータベースの復元には時間がかかります。SQL Managed Instance では、CHECKSUM を有効にしないで復元されるバックアップに対して整合性チェックが実行されるためです。
詳細については、「 ログ再生サービスを使用して SQL Server からデータベースを移行する」を参照してください。
注意事項
CHECKSUMが有効になっている SQL Server でバックアップを作成することを強くお勧めします。このバックアップを使用しないと、破損したデータベースが Azure に復元されるリスクがあるためです。
オートコンプリートと連続モードの移行
LRS は "オートコンプリート" または "連続" モードで開始できます。
事前にバックアップ チェーン全体を生成し、移行の開始後にファイルを追加する予定がない場合は、 オートコンプリート モードを使用します。 この移行モードは、データのキャッチアップを必要としないパッシブ ワークロードに推奨されます。 すべてのバックアップ ファイルを Blob Storage アカウントにアップロードし、オートコンプリート モードの移行を開始します。 最後に指定したバックアップ ファイルが復元されると、移行は自動的に完了します。 移行されたデータベースは、SQL Managed Instance の読み取り/書き込みアクセスに使用できるようになります。
移行の進行中に新しいバックアップ ファイルを追加し続ける予定がある場合は、"連続" モードを使用します。 データのキャッチアップが必要なアクティブ ワークロードの場合は、このモードをお勧めします。 現在使用可能なバックアップ チェーンを Blob Storage アカウントにバックアップし、連続モードで移行を開始し、必要に応じてワークロードから新しいバックアップ ファイルの追加を続けます。 システムは、Azure Blob Storage フォルダーを定期的にスキャンし、検出された新しいログまたは差分バックアップ ファイルを復元します。
一括移行の準備ができたら、SQL Server インスタンスでワークロードを停止し、最後のバックアップ ファイルを生成した後、アップロードします。 最後のログ末尾バックアップが SQL Managed Instance で復元済みとして表示されることを確認して、最後のバックアップ ファイルが復元されていることを確認します。 次に、手動切り替えを開始します。 最後の一括移行ステップによって、データベースがオンラインになり、SQL Managed Instance 上での読み取りと書き込みアクセスができるようになります。
LRS がオートコンプリートによって自動的に終了するか、カットオーバーによって手動で停止された後、SQL Managed Instance 上でオンライン化されたデータベースの復元プロセスを再開することはできません。 たとえば、移行が完了すると、オンライン データベースの追加の差分バックアップを復元できなくなります。 移行の完了後、さらにバックアップ ファイルを復元するには、マネージド インスタンスからデータベースを削除し、移行を最初からやり直す必要があります。
移行のワークフロー
このセクションの画像は、一般的な移行ワークフローを示していますが、この表では手順の概要を示します。
すべてのバックアップ チェーン ファイルが事前に使用可能な場合にのみ、オートコンプリート モードを使用します。 データのキャッチアップを必要としないパッシブ ワークロードには、このモードをお勧めします。
バックアップ チェーン全体が事前に存在しない場合や、移行の進行中に新しいバックアップ ファイルを追加する予定がある場合は、連続モードの移行を使用してください。 データのキャッチアップが必要なアクティブ ワークロードの場合は、このモードをお勧めします。
| 操作 | 詳細 |
|---|---|
| 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 コマンドレット) を使用してサービスを開始します。 オートコンプリートと連続のどちらかの移行モードを選択します。 Blob Storage アカウント上のバックアップ フォルダーを指す各データベースで、LRS を個別に開始します。 サービスが開始すると、Blob Storage コンテナーからバックアップを取得し、それらの SQL Managed Instance への復元を開始します。 LRS をオートコンプリート モードで起動すると、指定した最後のバックアップ ファイルを介してすべてのバックアップが復元されます。 すべてのバックアップ ファイルを事前にアップロードする必要があり、移行の進行中に新しいバックアップ ファイルを追加することはできません。 このモードは、データのキャッチアップを必要としないパッシブ ワークロードに推奨されます。 LRS を連続モードで起動すると、最初にアップロードしたすべてのバックアップが復元され、フォルダーにアップロードした新しいファイルが監視されます。 サービスを手動で停止するまで、ログ シーケンス番号 (LSN) チェーンに基づいてログが連続して適用されます。 データのキャッチアップが必要なアクティブ ワークロードの場合は、このモードをお勧めします。 |
| 2.1. 操作の進行状況を監視する. | PowerShell (get-azsqlinstancedatabaselogreplay) または Azure CLI (az_sql_midb_log_replay_show コマンドレット) を使用して、進行中の復元操作の進行状況を監視します。 失敗した要求に関する追加の詳細を追跡するには、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 デプロイにアップロードします。 SQL マネージド インスタンスで最後のログ末尾バックアップが復元されていることを確認します。 カットオーバーを完了するには、PowerShell ( complete) または Azure CLI (az_sql_midb_log_replay_complete) を使って LRS 操作を開始します。 この操作によって LRS が停止し、データベースがオンラインになり、SQL Managed Instance 上でのワークロードの読み取りと書き込みが可能になります。アプリケーションの接続文字列を SQL Server インスタンスから SQL Managed Instance へと再設定します。 このステップは、アプリケーションの接続文字列を手動で変更するか、自動的に変更する (たとえば、アプリケーションでプロパティやデータベースの接続文字列を読み取ることができる場合など) というように、自分で調整する必要があります。 |
重要
カットオーバーの後、Business Critical サービス レベルの SQL Managed Instance は、高可用性グループに対して 3 つのセカンダリ レプリカをシードする必要があるため、使用可能になるまで General Purpose よりかなり長くかかることがあります。 操作時間は、データのサイズによって異なります。 詳細については、管理操作の所要時間に関するセクションを参照してください。
大規模なデータベースを移行する
数テラバイトの大きなデータベースを移行する場合は、次の点を考慮してください。
- 1 つの LRS ジョブは、最大 30 日間実行できます。 この期間が経過すると、ジョブは自動的に取り消されます。
- 実行時間の長いジョブの場合、システムの更新によって移行ジョブが中断され、延長される可能性があります。 メンテナンス期間を使用して、計画されたシステム更新をスケジュールすることを強くお勧めします。 スケジュールされたメンテナンス期間を中心に移行を計画します。
- システムの更新によって中断された移行ジョブは、 General Purpose SQL マネージド インスタンスで自動的に中断および再開され、 Business Critical SQL マネージド インスタンスでは再開されます。 これらの更新プログラムは、移行の期間に影響します。
- Blob Storage アカウントへの SQL Server バックアップ ファイルのアップロード速度を上げるには、インフラストラクチャに十分なネットワーク帯域幅がある場合は、複数のスレッドによる並列化を使用することを検討してください。
移行を開始する
移行を開始するには、LRS を開始します。 サービスはオートコンプリートまたは連続モードで開始できます。 具体的な詳細については、 ログ再生サービスを使用した SQL Server からのデータベースの移行に関するページを参照してください。
オートコンプリート モード。 オートコンプリート モードを使用すると、指定したバックアップ ファイルの最後が復元されると、移行が自動的に完了します。 このオプション:
- バックアップ チェーン全体が事前に使用でき、Azure Blob Storage アカウントにアップロードできる必要があります。
- 移行の進行中に新しいバックアップ ファイルを追加することはできません。
- start コマンドに最後のバックアップ ファイルのファイル名を指定する必要があります。
データのキャッチアップが必要ないパッシブ ワークロードの場合は、オートコンプリート モードの使用をお勧めします。
連続モード。 連続モードを使うと、サービスは Azure Blob Storage フォルダーを継続的にスキャンし、移行の進行中に追加される新しいバックアップ ファイルを復元します。
移行は、手動カットオーバーを要求した後にのみ完了します。
バックアップ チェーン全体が事前に存在しない場合や、移行の進行中に新しいバックアップ ファイルを追加する予定がある場合は、連続モードの移行を使用してください。
データのキャッチアップが必要なアクティブ ワークロードの場合は、連続モードの使用をお勧めします。
最大 30 日以内に 1 つの LRS 移行ジョブを完了するように計画します。 この期間が経過すると、LRS ジョブは自動的に取り消されます。
注
複数のデータベースを移行する場合は、各データベースを独自のフォルダー内に配置する必要があります。 Azure Blob Storage コンテナーの完全な URI パスと個々のデータベース フォルダーをポイントして、データベースごとに個別に LRS を開始します。 データベース フォルダー内の入れ子になったフォルダーはサポートされていません。
LRS の制限事項
詳細については、LRS を使用する場合の制限事項を確認してください。