Azure SQL Managed Instance での Log Replay Service の概要
適用対象: 
Azure SQL Managed Instance
この記事では、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 からデータベースを移行する」を参照してください。
重要
データベースを 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/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 でオンラインにされたデータベースの復元プロセスは再開できなくなります。 たとえば、移行が完了すると、オンライン データベースの追加の差分バックアップを復元できなくなります。 移行の完了後、さらにバックアップ ファイルを復元するには、マネージド インスタンスからデータベースを削除し、移行を最初からやり直す必要があります。
移行のワークフロー
一般的な移行ワークフローを次の図に示し、大まかなステップを表に示します。
オートコンプリート モードは、すべてのバックアップ チェーン ファイルが事前に使用できる場合にのみ使用する必要があります。 データのキャッチアップが必要ないパッシブ ワークロードの場合は、このモードをお勧めします。
バックアップ チェーン全体が事前に存在しない場合や、移行の進行中に新しいバックアップ ファイルを追加する予定がある場合は、連続モードの移行を使用してください。 データのキャッチアップが必要なアクティブ ワークロードの場合は、このモードをお勧めします。
| 操作 | 詳細 |
|---|---|
| 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
複数のデータベースを移行する場合は、各データベースが独自のフォルダーに存在する必要があります。 LRS は、Azure Blob Storage コンテナーと個々のデータベース フォルダーの完全な URI パスを指すように、データベースごとに個別に開始する必要があります。 データベース フォルダー内の入れ子になったフォルダーはサポートされていません。
LRS の制限事項
詳細については、LRS を使用する場合の制限事項を確認してください。
次のステップ
詳細については、「Log Replay Service を使用した SQL Server から SQL Managed Instance へのデータベースの移行」を参照してください。
リンク機能を使用した SQL Managed Instance へのデータベースの移行についての詳細を確認してください。
SQL Server から SQL Managed Instance へのデータベースの移行についての詳細を確認してください。
SQL Server と SQL Managed Instance の違いについての詳細を理解します。
Azure に移行するワークロードのコストとサイズ設定のベスト プラクティスについて詳しく学習します。