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 のログ配布テクノロジに基づいています。

開始するには、Log Replay Service を使って SQL Server から Azure SQL Managed Instance にデータベースを移行する方法に関する記事を参照してください。

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 アカウントに直接保存されている。
  • 差分バックアップを使用する必要がある。

次のソースがサポートされています。

  • 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)

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) を使います。
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 へと再設定します。 このステップは、アプリケーションの接続文字列を手動で変更するか、自動的に変更する (たとえば、アプリケーションでプロパティやデータベースの接続文字列を読み取ることができる場合など) というように、自分で調整する必要があります。

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

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

  • 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 リンク機能の使用を検討してください。

次の手順