適用対象:Azure SQL データベース
この記事では、データベースまたはエラスティック プールを新しいリージョンに移動する方法に関する一般的なワークフローについて説明します。
Note
- データベースとエラスティック プールを別の Azure リージョンに移動するには、Azure Resource Mover を使用することもできます。これは推奨される方法です。
- この記事は、Azure パブリック クラウド内または同じソブリン クラウド内での移行に適用されます。
概要
既存のデータベースまたはプールをリージョン間で移動することが必要になるさまざまなシナリオがあります。 たとえば、ビジネスを新しいリージョンに拡張しており、新しい顧客ベース用にそれを最適化したい場合があります。 コンプライアンス上の理由により、操作を別のリージョンに移動する必要がある場合や、 Azure が、近接性を向上させ、カスタマー エクスペリエンスを向上させる、新しいリージョンをリリースした場合もあります。
リソースを別のリージョンに移動する一般的なワークフローは、次の手順で構成されます。
- 移動の前提条件を確認します。
- スコープ内のリソースの移動を準備します。
- 準備プロセスを監視します。
- 移動プロセスをテストします。
- 実際の移動を開始します。
データベースを移動するための前提条件を検証する
- 各ソース サーバーにターゲット サーバーを作成します。
- PowerShell を使用して、適切な例外でファイアウォールを構成します。
- 正しいログインを使用して両方のサーバーを構成します。 サブスクリプション管理者または SQL サーバー管理者でない場合は、管理者に協力を求め、必要なアクセス許可を割り当てます。 詳細については、ディザスター リカバリーの後に Azure SQL Database セキュリティを管理する方法に関する記事を参照してください。
- データベースが透過的なデータ暗号化 (TDE) で暗号化されていて、Azure Key Vault で独自の暗号化キー (BYOK またはカスタマー マネージド キー) を使用している場合は、ターゲット リージョンで適切な暗号化マテリアルがプロビジョニングされていることを確認してください。
- これを行う最も簡単な方法は、(ソース サーバーで TDE プロテクターとして使用されている) 既存のキー コンテナーからターゲット サーバーに暗号化キーを追加し、そのキーをターゲット サーバーの TDE プロテクターとして設定することです。これは、リージョン内のサーバーが、他の任意のリージョンのキー コンテナーに接続できるようになっているためです。
- ターゲット サーバーが古い暗号化キー (データベースのバックアップの復元に必要) にアクセスできるようにするためのベスト プラクティスとして、ソース サーバーで Get-AzSqlServerKeyVaultKey コマンドレットを実行し、使用可能なキーのリストを返し、それらのキーをターゲット サーバーに追加します。
- ターゲット サーバーで顧客が管理する TDE を構成する方法の詳細とベスト プラクティスについては、Azure Key Vault でのカスタマー マネージド キーを使用した Azure SQL Transparent Data Encryptionに関する記事を参照してください。
- キー コンテナーを新しいリージョンに移動するには、「リージョン間で Azure キー コンテナーを移動する」を参照してください。
 
- データベース レベルの監査が有効になっている場合は、無効にし、代わりにサーバー レベルの監査を有効にします。 フェールオーバー後、データベース レベルの監査では、移動後には不要となり、不可能となるリージョン間のトラフィックが必要になります。
- サーバー レベルの監査では、次のことを確認します。- 既存の監査ログを含むストレージ コンテナー、Log Analytics、またはイベント ハブが、ターゲット リージョンに移動されていること。
- ターゲット サーバーで監査が構成されていること。 詳細については、「SQL Database 監査の使用」を参照してください。
 
- サーバーに長期リテンション ポリシー (LTR) がある場合、既存の LTR バックアップは現在のサーバーに関連付けられたままになります。 ターゲット サーバーが異なるため、たとえサーバーが削除されても、ソース サーバーを使用してソース リージョンのそれ以前の LTR バックアップにアクセスできるようになります。
Note
ソブリン リージョンとパブリック リージョン間で既存の LTR バックアップがあるデータベースを移行することはサポートされていません。これを行うには、LTR バックアップをターゲット サーバーに移動する必要がありますが、これは現在不可能なためです。
リソースを準備する
- ソースのサーバーとターゲットのサーバーとの間でフェールオーバー グループを作成します。
- 移動したいデータベースをフェールオーバー グループに追加します。 追加されたすべてのデータベースのレプリケーションが自動的に開始されます。 詳細については、SQL Database でフェイルオーバー グループを使用する を参照してください。
準備プロセスを監視する
Get-AzSqlDatabaseFailoverGroup を定期的に呼び出して、ソースからターゲット サーバーへのデータベースのレプリケーションを監視することができます。 Get-AzSqlDatabaseFailoverGroup の出力オブジェクトには、Get-AzSqlDatabaseFailoverGroup のプロパティが含まれます。
- ReplicationState = 2 (CATCH_UP) は、データベースが同期されており、安全にフェールオーバーできることを示します。
- ReplicationState = 0 (SEEDING) は、データベースがまだシード処理されておらず、フェールオーバーの試行が失敗することを示します。
同期をテストする
ReplicationState が 2 になったら、セカンダリ エンドポイント <fog-name>.secondary.database.windows.net を使用して各データベースまたはデータベースのサブセットに接続し、データベースに対して任意のクエリを実行して、接続性、適切なセキュリティ構成、データ レプリケーションを保証します。
移動を開始する
- セカンダリ エンドポイント <fog-name>.secondary.database.windows.netを使用してターゲット サーバーに接続します。
- Switch-AzSqlDatabaseFailoverGroup を使用して、セカンダリ サーバーを完全に同期したプライマリに切り替えます。 この操作は成功するか、そうでなければロールバックします。
- nslookup <fog-name>.secondary.database.windows.netを使用してコマンドが正常に完了したことを検証して、DNS CNAME エントリがターゲット リージョンの IP アドレスを指していることを確認します。 switch コマンドが失敗した場合、CNAME は更新されません。
ソース データベースを削除する
移動が完了したら、不要な料金が発生しないように、ソース リージョンのリソースを削除します。
- Remove-AzSqlDatabaseFailoverGroup を使用して、フェールオーバー グループを削除します。
- ソース サーバー上の各データベースに対して、Remove-AzSqlDatabase を使用して各ソース データベースを削除します。 これにより、geo レプリケーション リンクが自動的に終了します。
- Remove-AzSqlServer 使用してソース サーバーを削除します。
- キー コンテナー、監査ストレージ コンテナー、イベント ハブ、Microsoft Entra テナント、その他の依存リソースを削除して、課金されないようにします。
プールを移動するための前提条件を確認する
- 各ソース サーバーにターゲット サーバーを作成します。
- PowerShell を使用して、適切な例外でファイアウォールを構成します。
- 正しいログインを使用してサーバーを構成します。 サブスクリプション管理者またはサーバー管理者でない場合は、管理者に協力を求め、必要なアクセス許可を割り当てます。 詳細については、ディザスター リカバリーの後に Azure SQL Database セキュリティを管理する方法に関する記事を参照してください。
- データベースが透過的なデータ暗号化で暗号化されていて、Azure Key Vault で独自の暗号化キーを使用している場合は、ターゲット リージョンで適切な暗号化マテリアルがプロビジョニングされていることを確認してください。
- ソース エラスティック プールごとにターゲット エラスティック プールを作成して、同じ名前と同じサイズのプールが同じサービス レベルで作成されるようにします。
- データベース レベルの監査が有効になっている場合は、無効にし、代わりにサーバー レベルの監査を有効にします。 フェールオーバー後、データベース レベルの監査では、移動後には不要となり、不可能となるリージョン間のトラフィックが必要になります。
- サーバー レベルの監査では、次のことを確認します。- 既存の監査ログを含むストレージ コンテナー、Log Analytics、またはイベント ハブが、ターゲット リージョンに移動されていること。
- 監査構成は、ターゲット サーバーで構成されます。 詳細については、SQL Database の監査に関する記事を参照してください。
 
- サーバーに長期リテンション ポリシー (LTR) がある場合、既存の LTR バックアップは現在のサーバーに関連付けられたままになります。 ターゲット サーバーが異なるため、たとえサーバーが削除されても、ソース サーバーを使用してソース リージョンのそれ以前の LTR バックアップにアクセスできるようになります。
Note
ソブリン リージョンとパブリック リージョン間で既存の LTR バックアップがあるデータベースを移行することはサポートされていません。これを行うには、LTR バックアップをターゲット サーバーに移動する必要がありますが、これは現在不可能なためです。
移動の準備をする
- ソース サーバー上の各エラスティック プールとターゲット サーバー上の対応するエラスティック プールとの間に、個別のフェールオーバー グループを作成します。 
- プール内のすべてのデータベースをフェールオーバー グループに追加します。 追加されたデータベースのレプリケーションが自動的に開始されます。 詳細については、SQL Database でフェイルオーバー グループを使用する を参照してください。 - Note - 複数のエラスティック プールを含むフェールオーバー グループを作成することはできますが、プールごとに個別のフェールオーバー グループを作成することを強くお勧めします。 移動する必要のある複数のエラスティック プールにわたって多数のデータベースがある場合は、準備手順を並行して実行してから、移動手順を並行して開始することができます。 このプロセスは、同じフェールオーバー グループ内に複数のエラスティック プールがある場合と比べて、拡張性が高く、所要時間は短くなります。 
準備プロセスを監視する
Get-AzSqlDatabaseFailoverGroup を定期的に呼び出して、ソースからターゲットへのデータベースのレプリケーションを監視することができます。 Get-AzSqlDatabaseFailoverGroup の出力オブジェクトには、Get-AzSqlDatabaseFailoverGroup のプロパティが含まれます。
- ReplicationState = 2 (CATCH_UP) は、データベースが同期されており、安全にフェールオーバーできることを示します。
- ReplicationState = 0 (SEEDING) は、データベースがまだシード処理されておらず、フェールオーバーの試行が失敗することを示します。
同期をテストする
ReplicationState が 2 になったら、セカンダリ エンドポイント <fog-name>.secondary.database.windows.net を使用して各データベースまたはデータベースのサブセットに接続し、データベースに対して任意のクエリを実行して、接続性、適切なセキュリティ構成、データ レプリケーションを保証します。
移動を開始する
- セカンダリ エンドポイント <fog-name>.secondary.database.windows.netを使用してターゲット サーバーに接続します。
- Switch-AzSqlDatabaseFailoverGroup を使用して、セカンダリ サーバーを完全に同期したプライマリに切り替えます。 この操作は成功するか、そうでなければロールバックします。
- nslookup <fog-name>.secondary.database.windows.netを使用してコマンドが正常に完了したことを検証して、DNS CNAME エントリがターゲット リージョンの IP アドレスを指していることを確認します。 switch コマンドが失敗した場合、CNAME は更新されません。
ソース エラスティック プールを削除する
移動が完了したら、不要な料金が発生しないように、ソース リージョンのリソースを削除します。
- Remove-AzSqlDatabaseFailoverGroup を使用して、フェールオーバー グループを削除します。
- Remove-AzSqlElasticPool を使用して、ソース サーバー上の各ソース エラスティック プールを削除します。
- Remove-AzSqlServer 使用してソース サーバーを削除します。
- キー コンテナー、監査ストレージ コンテナー、イベント ハブ、Microsoft Entra テナント、その他の依存リソースを削除して、課金されないようにします。
次のステップ
移行後のデータベースを管理します。