分散可用性グループを使用してセルフマネージド SQL Server から移行する

このガイドでは、Database Migration Service の分散可用性グループ（DAG）を使用して、セルフマネージド SQL Server Enterprise Edition インスタンスから Cloud SQL for SQL Server Enterprise Edition に、プライベート ネットワーク接続経由でデータベースを移行する方法について説明します。

DAG 移行では、Database Migration Service は、最初のフルロード（FULL_DUMP フェーズ）と継続的なトランザクション ログ レプリケーション（変更データ キャプチャ - CDC - フェーズ）の両方を、移行元の可用性グループと移行先の Cloud SQL for SQL Server 可用性グループ間のネットワーク経由で直接ストリーミングします。DAG 移行のアーキテクチャ、前提条件、制限事項の詳細については、分散可用性グループ（DAG）の移行についてをご覧ください。Cloud Storage に保存されているバックアップ ファイルを使用して移行するには、SQL Server データベースを Cloud SQL for SQL Server に移行するをご覧ください。

分散可用性グループの移行を行うには、次の大まかなタスクを完了します。

1. 移行先の Cloud SQL for SQL Server インスタンスを作成して準備します。
2. 移行元の SQL Server インスタンスと可用性グループを準備します。
3. 双方向のプライベート ネットワーク接続を確立し、リンクサーバーを構成します。
4. 接続プロファイルを作成して移行ジョブを実行します。
5. 移行をモニタリングして検証する。
6. 移行をプロモート、フェイルバック、または完了します。

費用

Cloud SQL への同種移行の場合、Database Migration Service は追加料金なしで提供されます。ただし、標準の Cloud SQL とネットワークの料金が適用されます。使用料金を概算するには、料金計算ツールを使用します。

始める前に

1. ソース データベースと宛先データベースが、分散可用性グループの移行に関するすべての前提条件と制限事項を満たしていることを確認します（Enterprise Edition の実行、デフォルトのデータ ディレクトリへのデータファイルの保存、データベース所有者として sa を使用しないなど）。分散可用性グループ（DAG）の移行についてをご覧ください。
2. 移行先の Google Cloud リージョンを選択します。Database Migration Service は完全にリージョンに依存するプロダクトです。移行に関連するすべてのエンティティ（移行元と移行先の接続プロファイル、移行ジョブ、移行先の Cloud SQL for SQL Server インスタンス）は、同じリージョンに存在する必要があります。
3. Google Cloud コンソールのプロジェクト セレクタ ページで、 Google Cloud プロジェクトを選択または作成します。

   プロジェクト セレクタに移動

4. Database Migration Service、Compute Engine、Cloud SQL Admin API を有効にします。

   API を有効にする

必要なロール

Google Cloud プロジェクトで次の IAM ロールが付与されていることを確認します。

• 移行を実行するユーザー アカウント:
  • データベース移行管理者（roles/datamigration.admin）
  • Cloud SQL 編集者（roles/cloudsql.editor）
• Database Migration Service サービス アカウント（service-<var>PROJECT_NUMBER</var>@gcp-sa-datamigration.）:
  • Database Migration Service エージェント（roles/datamigration.serviceAgent）
  • Cloud SQL 編集者（roles/cloudsql.editor）
  • Cloud SQL Studio ユーザー（roles/cloudsql.studioUser）

ロールの付与の詳細については、アクセスの管理をご覧ください。

移行先の Cloud SQL for SQL Server インスタンスを作成して準備する

このステップでは、移行先の Cloud SQL for SQL Server Enterprise エディション インスタンスを作成し、リンクサーバーに必要なデータベース フラグを有効にします。

1. 移行先の Cloud SQL for SQL Server インスタンスを作成します。作成手順の詳細については、Cloud SQL for SQL Server インスタンスを作成するをご覧ください。インスタンスが、分散可用性グループの移行に関する次の要件を満たしていることを確認します。
   • [Enterprise Edition]（バージョン 2017、2019、2022、2025）を選択します。
   • ソース SQL Server インスタンスと移行先 Cloud SQL for SQL Server インスタンスの接続方法に合わせて、プライベート ネットワーキングを構成します。Virtual Private Cloud ピアリングを介してインスタンスを接続する場合は、 プライベート サービス アクセスを有効にします。インバウンド Private Service Connect エンドポイントとアウトバウンド Private Service Connect ネットワーク アタッチメントを使用してインスタンスを接続する場合は、 Private Service Connect を使用します。

     同じ宛先の Cloud SQL for SQL Server インスタンスで、プライベート サービス アクセスと Private Service Connect の両方を有効にしないでください。Cloud SQL for SQL Server は、両方が有効になっている場合、リンクサーバーをサポートしません。ネットワーキングの設定の詳細については、双方向のプライベート ネットワーク接続を確立するをご覧ください。

   • DAG 移行ジョブを完了して削除するまで、ポイントインタイム リカバリ（PITR）を無効にして、リードレプリカを追加しないでください。
   • ソース データベースが Windows Active Directory ログインによって所有されている場合は、移行前にソース データベースの所有者を SQL ログインに変更するか、移行先の Cloud SQL for SQL Server インスタンスを Active Directory に参加させて、移行ジョブの開始時に Database Migration Service が移行先インスタンスに対応する Windows ログインを自動的に作成できるようにします。手順については、Cloud SQL for SQL Server 用に Managed Microsoft AD を構成するをご覧ください。
2. 移行先の Cloud SQL for SQL Server インスタンスで cloudsql enable linked servers データベース フラグを有効にします（on に設定）。フラグの設定手順については、リンクサーバーを管理するとデータベース フラグを構成するをご覧ください。

   このフラグは、このガイドの後半で移行先の Cloud SQL for SQL Server インスタンスでリンクサーバーを作成して検証するときに必要になります。

移行元の SQL Server インスタンスを準備する

このステップでは、移行元の SQL Server インスタンスで Always On 可用性グループを有効にし、データベース ミラーリング エンドポイントと証明書を作成します。また、Database Migration Service 専用の SQL ログインを作成し、移行元の可用性グループを準備します。

Always On 可用性グループを有効にする

ソース SQL Server インスタンスで Always On 可用性グループ機能が有効になっていることを確認します。

• Windows の場合は、Microsoft のドキュメントの Always On 可用性グループを有効または無効にするをご覧ください。
• Linux の場合は、Microsoft のドキュメントで Linux で高可用性を実現するために SQL Server Always On 可用性グループを構成するをご覧ください。

データベース ミラーリング エンドポイントと証明書を作成する

SQL Server では、分散可用性グループが TCP DATABASE_MIRRORING（DBM）エンドポイント（デフォルト ポート 5022）を介してインスタンス間でデータとトランザクション ログをストリーミングします。セルフマネージド SQL Server インスタンスと移行先の Cloud SQL for SQL Server インスタンスはスタンドアロン インスタンスであるため、DBM エンドポイントを介して信頼を確立するには、証明書ベースの相互認証と AES 暗号化が必要です。

証明書を作成し、ソース SQL Server インスタンスの DATABASE_MIRRORING エンドポイントにバインドするだけで済みます。移行先の Cloud SQL for SQL Server インスタンスで証明書ファイルを手動でエクスポートしたり、証明書を作成したりする必要はありません。

• 移行ジョブを開始すると、Database Migration Service は、移行先の Cloud SQL for SQL Server インスタンスに DATABASE_MIRRORING エンドポイントと証明書を自動的に構成し、リンクサーバーを使用して両方のインスタンス間で公開鍵を交換します。
• カットオーバーの完了後に移行ジョブを削除すると、Database Migration Service はインポートされた証明書を両方のインスタンスから自動的に削除します。

ソース SQL Server インスタンスに、証明書で認証された DATABASE_MIRRORING エンドポイントがまだない場合は、作成します。

1. SQL クライアント（sqlcmd ユーティリティなど）を使用してソース インスタンスに接続します。
2. 次の T-SQL コマンドを実行して、データベース マスターキー、証明書、選択した DBM ポート（デフォルトは 5022）をリッスンする DATABASE_MIRRORING エンドポイントを作成します。

   USE [master];
   GO
   
   IF NOT EXISTS (SELECT * FROM sys.symmetric_keys WHERE symmetric_key_id = 101)
   BEGIN
       CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'MASTER_KEY_PASSWORD';
   END
   GO
   
   CREATE CERTIFICATE [SOURCE_CERT_NAME]
       WITH SUBJECT = 'AlwaysOn AG Certificate',
       EXPIRY_DATE = 'CERT_EXPIRY_DATE';
   GO
   
   CREATE ENDPOINT [HADR_ENDPOINT_NAME]
       STATE = STARTED
       AS TCP (LISTENER_PORT = SOURCE_DBM_PORT_NUMBER)
       FOR DATABASE_MIRRORING (
           ROLE = ALL,
           AUTHENTICATION = CERTIFICATE [SOURCE_CERT_NAME],
           ENCRYPTION = REQUIRED ALGORITHM AES
       );
   GO

   次のように置き換えます。

   • MASTER_KEY_PASSWORD は、データベース マスター鍵を暗号化するパスワードに置き換えます。
   • SOURCE_CERT_NAME は、ソースのデータベース ミラーリング証明書の名前（例: dbmCertificate）に置き換えます。
   • CERT_EXPIRY_DATE は、証明書の有効期限（YYYYMMDD 形式）に置き換えます。
   • HADR_ENDPOINT_NAME は、データベース ミラーリング エンドポイントの名前に置き換えます。
   • SOURCE_DBM_PORT_NUMBER は、データベース ミラーリング トラフィックの TCP ポート番号（デフォルトは 5022）に置き換えます。

専用の Database Migration Service のログインと権限を作成する

Database Migration Service は、ソース接続プロファイルで指定した専用の SQL ログインを使用して、リンクサーバー経由でソース SQL Server インスタンスに接続します。このログインを構成するには、sysadmin サーバーロールを付与するか、gcp_dms_db ヘルパー データベースを使用して最小権限を構成します。

sysadmin ロールを付与する

セキュリティ ポリシーで移行ログインに sysadmin サーバーロールを付与できる場合は、次の T-SQL コマンドを実行します。

USE [master];
GO
CREATE LOGIN [SOURCE_USERNAME] WITH PASSWORD = 'SOURCE_PASSWORD';
CREATE USER [SOURCE_USER] FOR LOGIN [SOURCE_USERNAME];
ALTER SERVER ROLE [sysadmin] ADD MEMBER [SOURCE_USERNAME];
GRANT CONNECT ON ENDPOINT::[HADR_ENDPOINT_NAME] TO [SOURCE_USERNAME];
GO

次のように置き換えます。

• SOURCE_USERNAME は、Database Migration Service がソース インスタンスへの接続に使用する SQL ログイン名（cloud_dms_login など）に置き換えます。
• SOURCE_PASSWORD は、SOURCE_USERNAME ログインのパスワードに置き換えます。
• SOURCE_USER は、SOURCE_USERNAME にマッピングされたデータベース ユーザー名（cloud_dms_user など）に置き換えます。
• HADR_ENDPOINT_NAME は、データベース ミラーリング エンドポイントの名前（Hadr_endpoint など）に置き換えます。

最小権限（gcp_dms_db）

セキュリティ ポリシーで移行ログインに sysadmin を付与することが禁止されている場合は、専用の gcp_dms_db ヘルパー データベース（TRUSTWORTHY ON を持つ sa が所有）を作成し、3 つの Database Migration Service ラッパー ストアド プロシージャを作成して、移行ログインにきめ細かい権限を付与します。

USE [master];
GO

CREATE DATABASE [gcp_dms_db];
GO

ALTER AUTHORIZATION ON DATABASE::[gcp_dms_db] TO [sa];
ALTER DATABASE [gcp_dms_db] SET TRUSTWORTHY ON;
GO

USE [gcp_dms_db];
GO

CREATE OR ALTER PROCEDURE dbo.gcp_dms_set_dag_commit_mode
    @dag_name NVARCHAR(128),
    @source_ag NVARCHAR(128),
    @dest_ag NVARCHAR(128),
    @commit_mode NVARCHAR(30)
WITH EXECUTE AS 'dbo'
AS
BEGIN
    SET NOCOUNT ON;
    IF @commit_mode NOT IN ('SYNCHRONOUS_COMMIT', 'ASYNCHRONOUS_COMMIT')
    BEGIN
        RAISERROR('Invalid commit mode. Must be SYNCHRONOUS_COMMIT or ASYNCHRONOUS_COMMIT.', 16, 1);
        RETURN;
    END
    DECLARE @sql NVARCHAR(MAX);
    SET @sql = N'USE master; ALTER AVAILABILITY GROUP ' + QUOTENAME(@dag_name) +
               N' MODIFY AVAILABILITY GROUP ON ' +
               QUOTENAME(@source_ag, '''') + N' WITH (AVAILABILITY_MODE = ' + @commit_mode + N'), ' +
               QUOTENAME(@dest_ag, '''') + N' WITH (AVAILABILITY_MODE = ' + @commit_mode + N');';
    EXECUTE sp_executesql @sql;
END;
GO

CREATE OR ALTER PROCEDURE dbo.gcp_dms_set_dag_secondary
    @dag_name NVARCHAR(128)
WITH EXECUTE AS 'dbo'
AS
BEGIN
    SET NOCOUNT ON;
    DECLARE @sql NVARCHAR(MAX);
    SET @sql = N'USE master; ALTER AVAILABILITY GROUP ' + QUOTENAME(@dag_name) + N' SET (ROLE = SECONDARY);';
    EXECUTE sp_executesql @sql;
END;
GO

CREATE OR ALTER PROCEDURE dbo.gcp_dms_failover_dag
    @dag_name NVARCHAR(128)
WITH EXECUTE AS 'dbo'
AS
BEGIN
    SET NOCOUNT ON;
    DECLARE @sql NVARCHAR(MAX);
    SET @sql = N'USE master; ALTER AVAILABILITY GROUP ' + QUOTENAME(@dag_name) + N' FORCE_FAILOVER_ALLOW_DATA_LOSS;';
    EXECUTE sp_executesql @sql;
END;
GO

USE [master];
GO

CREATE LOGIN [SOURCE_USERNAME] WITH PASSWORD = 'SOURCE_PASSWORD';
CREATE USER [SOURCE_USER] FOR LOGIN [SOURCE_USERNAME];
GRANT VIEW SERVER STATE TO [SOURCE_USERNAME];
-- Note: Run GRANT VIEW SERVER PERFORMANCE STATE on SQL Server 2022 and later:
GRANT VIEW SERVER PERFORMANCE STATE TO [SOURCE_USERNAME];
GRANT VIEW ANY DEFINITION TO [SOURCE_USERNAME];
GRANT ALTER ANY AVAILABILITY GROUP TO [SOURCE_USERNAME];
GRANT CONNECT ON ENDPOINT::[HADR_ENDPOINT_NAME] TO [SOURCE_USERNAME];
GRANT CREATE CERTIFICATE TO [SOURCE_USER];
GO

USE [gcp_dms_db];
GO

CREATE USER [SOURCE_USER] FOR LOGIN [SOURCE_USERNAME];
GRANT EXECUTE ON dbo.gcp_dms_set_dag_commit_mode TO [SOURCE_USER];
GRANT EXECUTE ON dbo.gcp_dms_set_dag_secondary TO [SOURCE_USER];
GRANT EXECUTE ON dbo.gcp_dms_failover_dag TO [SOURCE_USER];
GO

-- Repeat the following block for EACH user database in your source Availability Group:
USE [DATABASE_NAME];
GO

CREATE USER [SOURCE_USER] FOR LOGIN [SOURCE_USERNAME];
ALTER ROLE [db_backupoperator] ADD MEMBER [SOURCE_USER];
GO

次のように置き換えます。

• SOURCE_USERNAME は、Database Migration Service がソース インスタンスへの接続に使用する SQL ログイン名（cloud_dms_login など）に置き換えます。
• SOURCE_PASSWORD は、SOURCE_USERNAME ログインのパスワードに置き換えます。
• SOURCE_USER は、SOURCE_USERNAME にマッピングされたデータベース ユーザー名（cloud_dms_user など）に置き換えます。
• HADR_ENDPOINT_NAME は、データベース ミラーリング エンドポイントの名前（Hadr_endpoint など）に置き換えます。
• DATABASE_NAME は、可用性グループ内の各ソース データベースの名前に置き換えます。移行された各データベースに db_backupoperator を付与することは、Database Migration Service のプリフライト検証で必要です。これにより、プロモーション中に CHECKPOINT を使用してトランザクション ログをフラッシュできます。

ソース データベースと可用性グループを準備する

既存の Always On 可用性グループからデータベースを移行することも、新しいスタンドアロン可用性グループ（CLUSTER_TYPE = NONE）を作成することもできます。続行する前に、次の要件を確認してください。

• 可用性グループ内のすべてのデータベースは、FULL 復旧モデルを使用し、sa が所有せず、データファイル（.mdf と .ndf）をデフォルトのデータ ディレクトリに保存します。
• 既存の可用性グループを再利用する場合は、データベース ミラーリング エンドポイントがポート 5022（または選択した DBM ポート）に構成されていること、レプリカで SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL) が有効になっていること（プロモーションによって DAG ロールが切り替えられた後も、セカンダリ データベースが標準の接続文字列で読み取り可能な状態を維持するため）、移行ログインに CONNECT ON ENDPOINT が設定されていることを確認します。移行元の可用性グループに複数のレプリカがあり、可用性グループ リスナーが構成されている場合は、リンクサーバーと移行元の接続プロファイルを構成するときに、リスナー IP アドレスを <var>SOURCE_HOST_IP_ADDRESS</var> として使用します。これにより、移行元の可用性グループでフェイルオーバーが発生した場合に移行を再開できます。

データベースを準備して新しいスタンドアロン可用性グループ（CLUSTER_TYPE = NONE）を作成するには、次の T-SQL コマンドを実行します。

USE [master];
GO

ALTER DATABASE [DATABASE_NAME] SET RECOVERY FULL;
GO

-- If the database is owned by 'sa', change the owner to another login:
ALTER AUTHORIZATION ON DATABASE::[DATABASE_NAME] TO [DB_OWNER_LOGIN];
GO

-- Initialize the local SQL Server transaction log chain for the Availability Group:
BACKUP DATABASE [DATABASE_NAME] TO DISK = 'NUL';
GO

CREATE AVAILABILITY GROUP [SOURCE_AVAILABILITY_GROUP_NAME] WITH (CLUSTER_TYPE = NONE)
    FOR REPLICA ON N'SOURCE_SERVER_NAME' WITH (
        ENDPOINT_URL = N'TCP://localhost:SOURCE_DBM_PORT_NUMBER',
        FAILOVER_MODE = MANUAL,
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        SEEDING_MODE = MANUAL,
        PRIMARY_ROLE (ALLOW_CONNECTIONS = READ_WRITE),
        SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL)
    );
GO

ALTER AVAILABILITY GROUP [SOURCE_AVAILABILITY_GROUP_NAME] ADD DATABASE [DATABASE_NAME];
GO

次のように置き換えます。

• DATABASE_NAME は、可用性グループに含めるデータベースの名前に置き換えます。
• DB_OWNER_LOGIN は、データベースを所有する sa 以外のログインに置き換えます。
• SOURCE_AVAILABILITY_GROUP_NAME は、ソース可用性グループの名前（source_ag など）に置き換えます。
• SOURCE_SERVER_NAME は、移行元の SQL Server インスタンスのサーバー名（SELECT @@SERVERNAME によって返される値と一致）に置き換えます。
• SOURCE_DBM_PORT_NUMBER は、データベース ミラーリング エンドポイントの TCP ポート番号（デフォルトは 5022）に置き換えます。

注: BACKUP DATABASE ... TO DISK = 'NUL' の実行は、データベースを可用性グループに追加する前に FULL 復旧モデルに切り替えた後、データベースのトランザクション ログチェーンを初期化するためのローカル SQL Server の要件です。このコマンドは、可用性グループのローカル ログチェーンを初期化します。バックアップ ファイルの作成やアップロードは行いません。移行ジョブを開始すると、Database Migration Service は、ネットワーク経由で初期のフルロードを直接ストリーミングするように分散可用性グループを構成します。

双方向のプライベート ネットワーク接続を確立する

DAG 移行の場合、Database Migration Service は内部 Google Cloud API を介して移行先の Cloud SQL for SQL Server インスタンスと通信し、移行先の Cloud SQL for SQL Server インスタンスのリンクサーバーを介して移行元の SQL Server インスタンスでオーケストレーション クエリを実行し、プライベート ネットワークを介して 2 つのインスタンス間でデータを直接ストリーミングします。この移行では、Virtual Private Cloud ネットワークを介して、ソース SQL Server ホストと移行先の Cloud SQL for SQL Server インスタンスの間に双方向のプライベート IP 接続を直接確立する必要があります。移行元インスタンスと移行先インスタンス間のパブリック IP 接続はサポートされていません。

必要なポートと IP アドレス

ネットワーク構成では、次の 2 つの TCP ポートで、移行元の SQL Server インスタンスと移行先の Cloud SQL for SQL Server インスタンス間のトラフィックを許可する必要があります。

ポート	方向	目的
SQL Server データベース ポート（デフォルトは 1433）	移行先の Cloud SQL for SQL Server インスタンスから移行元の SQL Server インスタンス	移行先の Cloud SQL for SQL Server インスタンスのリンクサーバーが、移行元インスタンスで事前検証、証明書交換、DAG オーケストレーション クエリを実行するために使用します。
データベース ミラーリング（DBM）ポート（デフォルトは 5022）	移行元の SQL Server インスタンスと移行先の Cloud SQL for SQL Server インスタンス間の双方向	移行元と移行先の可用性グループが、FULL_DUMP 中の最初の完全読み込み、CDC 中の継続的なデータベース変更、FAILBACK 中のリバース レプリケーションをストリーミングするために使用します。

このガイドの後半でリンクサーバーと接続プロファイルを構成するときに、次の 2 つのプライベート IP アドレスを指定します。

• SOURCE_HOST_IP_ADDRESS（リンクサーバーの @datasrc パラメータとソース接続プロファイルの --host フラグで使用）は、移行先の Cloud SQL for SQL Server インスタンスから到達可能なソース SQL Server ホストのプライベート IP アドレス（または、マルチレプリカ ソース可用性グループ用に構成されている場合は、ソース可用性グループでフェイルオーバーが発生した場合に移行を再開できるように、可用性グループ リスナーの IP アドレスが推奨されます）です。
• DESTINATION_HOST_IP_ADDRESS（宛先接続プロファイルの --host フラグで使用）は、ソース SQL Server ホストから到達可能な宛先 Cloud SQL for SQL Server インスタンス（またはその Private Service Connect エンドポイントの IP アドレス）のプライベート IP アドレスです。

プライベート ネットワーキング方法を構成する

移行先の Cloud SQL for SQL Server インスタンスで有効にしたネットワーキング方法（プライベート サービス アクセスまたは Private Service Connect）のネットワーク ルーティング構成を完了します。

プライベート サービス アクセス

プライベート サービス アクセスは、Virtual Private Cloud ネットワークを、移行先 Cloud SQL for SQL Server インスタンスをホストする Google マネージド サービス プロデューサーの Virtual Private Cloud ネットワークとピアリングします。

1. Virtual Private Cloud ネットワークに、割り当てられた内部 IPv4 アドレス範囲と、宛先の Cloud SQL for SQL Server インスタンスに対して有効になっているプライベート接続（servicenetworking-googleapis-com への Virtual Private Cloud ピアリング）があることを確認します。手順については、Cloud SQL for SQL Server のプライベート IP を構成するをご覧ください。
2. ホストされている場所に基づいて、移行元の SQL Server ホストへのルーティングを構成します。
   • ソース インスタンスが同じ Virtual Private Cloud ネットワーク内の Compute Engine 仮想マシンで実行されている場合、追加のルーティングは必要ありません。仮想マシンと Cloud SQL for SQL Server インスタンスは、Virtual Private Cloud ピアリング接続を介して、互いのプライベート IP アドレスに直接アクセスできます。
   • 移行元インスタンスがオンプレミス、別のクラウド プロバイダ、または別の Virtual Private Cloud ネットワークで実行されている場合は、次の手順を完了して、推移的なピアリング境界を越えてルートが交換されるようにします。
     1. Cloud VPN または Cloud Interconnect を使用して、外部ネットワークを Virtual Private Cloud ネットワークに接続します。手順については、外部ソースから Cloud SQL インスタンスにアクセスするをご覧ください。
     2. Cloud Router で、Cloud SQL for SQL Server に割り振られた IP アドレス範囲をソース ネットワークにアドバタイズします。手順については、カスタム IP 範囲のアドバタイズをご覧ください。
     3. Virtual Private Cloud ネットワークの servicenetworking-googleapis-com ピアリング接続を更新して、カスタムルートのエクスポートを有効にします。これにより、Cloud SQL for SQL Server インスタンスがソース ネットワークへのルートを学習します。手順については、ピアリング接続を更新するをご覧ください。
3. 移行用のプライベート IP アドレスを記録します。
   • ソース SQL Server ホストの内部 IP アドレスを SOURCE_HOST_IP_ADDRESS として使用します。
   • 移行先の Cloud SQL for SQL Server インスタンスに割り当てられたプライベート IP アドレス（インスタンスの [概要] ページに表示）を DESTINATION_HOST_IP_ADDRESS として使用します。

Private Service Connect

プライベート サービス アクセスの代わりに Private Service Connect を使用する場合は、インバウンド Private Service Connect エンドポイント（ソース インスタンスがポート 5022 で Cloud SQL for SQL Server に接続できるようにする）とアウトバウンド Private Service Connect インターフェース（Cloud SQL for SQL Server がポート 1433 と 5022 でソース インスタンスへのリンクサーバーと DAG 接続を開始できるようにする）の両方を構成する必要があります。

1. 移行先の Cloud SQL for SQL Server インスタンスで Private Service Connect が有効になっており（プライベート IP なし）、許可されたコンシューマー プロジェクトが指定されていることを確認します。手順については、Private Service Connect を構成するをご覧ください。
2. ソース SQL Server ホストから移行先の Cloud SQL for SQL Server インスタンスへのインバウンド接続を許可するには、Virtual Private Cloud サブネットに内部 IP アドレスを予約し、Cloud SQL for SQL Server インスタンスのサービス アタッチメントをターゲットとする Private Service Connect エンドポイント（転送ルール）を作成します。手順については、Private Service Connect エンドポイントを作成するをご覧ください。
3. 移行先の Cloud SQL for SQL Server インスタンスから移行元の SQL Server ホストへのアウトバウンド接続を許可するには（リンクサーバーとアウトバウンド DAG 接続に必要）、移行元ホストにルーティングできるサブネットに Virtual Private Cloud ネットワーク アタッチメントを作成し、移行先の Cloud SQL for SQL Server インスタンスで Private Service Connect のアウトバウンド接続を構成します。手順については、ネットワーク アタッチメントを作成して管理すると Private Service Connect のアウトバウンド接続を構成するをご覧ください。
4. 移行用のプライベート IP アドレスを記録します。
   • ソース SQL Server ホストのプライベート IP アドレスを SOURCE_HOST_IP_ADDRESS として使用します。
   • Virtual Private Cloud ネットワーク内の Private Service Connect エンドポイント（転送ルール）の内部 IP アドレスを DESTINATION_HOST_IP_ADDRESS として使用します。

Virtual Private Cloud とソースホストのファイアウォール ルールを構成する

1. Virtual Private Cloud ネットワークで、ソース SQL Server IP アドレス（SOURCE_HOST_IP_ADDRESS）と宛先 Cloud SQL for SQL Server IP 範囲（または Private Service Connect エンドポイントとネットワーク アタッチメント サブネット）の間の TCP トラフィックを、データベース ポート（デフォルトは 1433）とデータベース ミラーリング ポート（デフォルトは 5022）の両方で許可する上り（内向き）と下り（外向き）のファイアウォール ルールを作成します。ファイアウォール ルールの作成の詳細については、ファイアウォール ルールを作成するをご覧ください。
2. 移行元の SQL Server マシンで、次のネットワークとホストのファイアウォール設定を確認します。
   • SQL Server 構成マネージャー（Linux の場合は mssql-conf）で TCP/IP が有効になっており、インスタンスが静的 TCP ポート（デフォルトは 1433）をリッスンしている。
   • オペレーティング システムのファイアウォール（Windows Defender ファイアウォール、Linux iptables、firewalld など）が、データベース ポート（デフォルトは 1433）とデータベース ミラーリング ポート（デフォルトは 5022）の両方でインバウンド TCP 接続を許可し、ポート 5022 で DESTINATION_HOST_IP_ADDRESS へのアウトバウンド TCP 接続を許可している。

Cloud SQL 接続テストでネットワーク到達性を確認する

リンクサーバーを構成する前に、 Google Cloud コンソールの Cloud SQL for SQL Server インスタンスの [接続] > [接続テスト] タブから 3 つの接続テストを実行することをおすすめします。接続テストの実行方法については、接続テストを管理するをご覧ください。

1. ポート 1433 でアウトバウンド リンクサーバー接続をテストするには、[送信元] を [現在の Cloud SQL インスタンス]、[宛先] を SOURCE_HOST_IP_ADDRESS、[宛先ポート] を 1433（またはカスタム データベース ポート）に設定します。
2. ポート 5022 でアウトバウンド データベース ミラーリング接続をテストするには、[送信元] を [現在の Cloud SQL インスタンス]、[宛先] を SOURCE_HOST_IP_ADDRESS、[宛先ポート] を 5022（またはカスタム DBM ポート）に設定します。
3. ポート 5022 でインバウンド データベース ミラーリング接続をテストするには、[送信元] を SOURCE_HOST_IP_ADDRESS、[宛先] を [現在の Cloud SQL インスタンス]（Private Service Connect を使用する場合は DESTINATION_HOST_IP_ADDRESS）、[宛先ポート] を 5022（またはカスタム DBM ポート）に設定します。

移行先の Cloud SQL for SQL Server インスタンスでリンクサーバーを作成して確認する

ネットワーク接続が確立されたら、移行先の Cloud SQL for SQL Server インスタンスに接続し、移行元の SQL Server インスタンスを指すリンクサーバーを作成します。

1. SQL クライアントを使用して Cloud SQL インスタンスに接続します。次の方法を使用できます。
   • sqlcmd クライアント。この方法を使用してインスタンスのプライベート IP に接続できますが、Compute Engine 仮想マシンの作成が必要になる場合があります。
   • gcloud sql connect コマンド。このコマンドは、パブリック IP アドレスが有効になっている Cloud SQL インスタンスでのみ機能します。
2. sqlserver ユーザーとしてログインし、移行先の Cloud SQL for SQL Server バージョンに対して次の T-SQL コマンドを実行して、移行元の SQL Server インスタンスを指すリンクサーバーを作成し、@locallogin = N'sqlserver' を移行元の移行ログインにマッピングし、rpc out を有効にして、OPENQUERY で接続をテストします（Cloud SQL のリンクサーバー オプションの詳細については、リンクサーバーを管理するをご覧ください）。

   Cloud SQL for SQL Server 2017、2019、2022

   USE [master];
   GO
   
   EXEC master.dbo.sp_addlinkedserver
       @server = N'LINKED_SERVER_NAME',
       @srvproduct = N'',
       @provider = N'SQLNCLI',
       @datasrc = N'SOURCE_HOST_IP_ADDRESS,SOURCE_PORT_NUMBER';
   GO
   
   EXEC master.dbo.sp_addlinkedsrvlogin
       @rmtsrvname = N'LINKED_SERVER_NAME',
       @useself = N'False',
       @locallogin = N'sqlserver',
       @rmtuser = N'SOURCE_USERNAME',
       @rmtpassword = N'SOURCE_PASSWORD';
   GO
   
   EXEC master.dbo.sp_serveroption
       @server = N'LINKED_SERVER_NAME',
       @optname = N'rpc out',
       @optvalue = N'TRUE';
   GO
   
   SELECT * FROM OPENQUERY([LINKED_SERVER_NAME], 'SELECT @@VERSION AS SourceServerVersion');
   GO

   Cloud SQL for SQL Server 2025

   USE [master];
   GO
   
   EXEC master.dbo.sp_addlinkedserver
       @server = N'LINKED_SERVER_NAME',
       @srvproduct = N'',
       @provider = N'MSOLEDBSQL19',
       @datasrc = N'SOURCE_HOST_IP_ADDRESS,SOURCE_PORT_NUMBER',
       @provstr = N'Encrypt=Optional;TrustServerCertificate=Yes;Authentication=SqlPassword;UID=Placeholder;';
   GO
   
   EXEC master.dbo.sp_addlinkedsrvlogin
       @rmtsrvname = N'LINKED_SERVER_NAME',
       @useself = N'False',
       @locallogin = N'sqlserver',
       @rmtuser = N'SOURCE_USERNAME',
       @rmtpassword = N'SOURCE_PASSWORD';
   GO
   
   EXEC master.dbo.sp_serveroption
       @server = N'LINKED_SERVER_NAME',
       @optname = N'rpc out',
       @optvalue = N'TRUE';
   GO
   
   SELECT * FROM OPENQUERY([LINKED_SERVER_NAME], 'SELECT @@VERSION AS SourceServerVersion');
   GO

   次のように置き換えます。

   • LINKED_SERVER_NAME は、Cloud SQL for SQL Server のリンクサーバーの名前（source_sql_linked_server など）に置き換えます。
   • SOURCE_HOST_IP_ADDRESS は、ソース SQL Server インスタンスのプライベート IP アドレス（マルチレプリカ ソース可用性グループ用に構成されている場合は、可用性グループ リスナーの IP アドレス）に置き換えます。
   • SOURCE_PORT_NUMBER は、ソース SQL Server データベース エンジンが接続を受け入れるポート番号に置き換えます（デフォルトは 1433）。
   • SOURCE_USERNAME は、専用の Database Migration Service ログインと権限を作成するで移行元インスタンスに作成した専用の SQL ログイン名に置き換えます。
   • SOURCE_PASSWORD は、SOURCE_USERNAME ログインのパスワードに置き換えます。

接続プロファイルを作成して移行ジョブを実行する

Google Cloud CLI を使用して、移行元と移行先の接続プロファイルを作成し、継続的な DAG 移行ジョブを作成して、移行構成を検証し、移行ジョブを開始します。

1. ソース接続プロファイルを作成します。
   gcloud database-migration connection-profiles create sqlserver コマンドを実行します（クリックして展開）。

   gcloud database-migration connection-profiles create sqlserver

   このサンプルでは、オプションの --no-async フラグを使用して、すべてのオペレーションが同期的に実行されるようにしています。そのため、一部のコマンドは完了するまでに時間がかかることがあります。--no-async フラグをスキップして、コマンドを非同期で実行できます。その場合は、 gcloud database-migration operations describe コマンドを使用して、オペレーションが成功したかどうかを確認する必要があります。

   gcloud database-migration connection-profiles create sqlserver SOURCE_CONNECTION_PROFILE_ID \
       --no-async \
       --display-name=SOURCE_CONNECTION_PROFILE_NAME \
       --region=REGION \
       --role=SOURCE \
       --host=SOURCE_HOST_IP_ADDRESS \
       --port=SOURCE_PORT_NUMBER \
       --dbm-port=SOURCE_DBM_PORT_NUMBER \
       --username=SOURCE_USERNAME \
       --password=SOURCE_PASSWORD

   次のように置き換えます。

   • SOURCE_CONNECTION_PROFILE_ID は、移行元接続プロファイルの機械で読み取り可能な ID（sqlserver-dag-source-profile など）に置き換えます。
   • SOURCE_CONNECTION_PROFILE_NAME は、ソース接続プロファイルの人が読める名前に置き換えます。この値は、 Google Cloud コンソールの Database Migration Service に表示されます。
   • REGION は、接続プロファイルを保存するリージョンの ID（us-central1 など）に置き換えます。
   • SOURCE_HOST_IP_ADDRESS は、ソース SQL Server インスタンスのプライベート IP アドレス（マルチレプリカ ソース可用性グループ用に構成されている場合は、可用性グループ リスナーの IP アドレス）に置き換えます。
   • SOURCE_PORT_NUMBER は、ソース SQL Server データベース エンジンが接続を受け入れるポート番号に置き換えます（デフォルトは 1433）。
   • SOURCE_DBM_PORT_NUMBER は、ソース データベース ミラーリング エンドポイントの TCP ポート番号（デフォルトは 5022）に置き換えます。
   • SOURCE_USERNAME は、専用の Database Migration Service ログインと権限を作成するで移行元インスタンスに作成した専用の SQL ログイン名に置き換えます。
   • SOURCE_PASSWORD は、SOURCE_USERNAME ログインのパスワードに置き換えます。

2. 宛先接続プロファイルを作成します。
   gcloud database-migration connection-profiles create sqlserver コマンドを実行します（クリックして展開）。

   gcloud database-migration connection-profiles create sqlserver

   このサンプルでは、オプションの --no-async フラグを使用して、すべてのオペレーションが同期的に実行されるようにしています。そのため、一部のコマンドは完了するまでに時間がかかることがあります。--no-async フラグをスキップして、コマンドを非同期で実行できます。その場合は、 gcloud database-migration operations describe コマンドを使用して、オペレーションが成功したかどうかを確認する必要があります。

   gcloud database-migration connection-profiles create sqlserver DESTINATION_CONNECTION_PROFILE_ID \
       --no-async \
       --display-name=DESTINATION_CONNECTION_PROFILE_NAME \
       --region=REGION \
       --role=DESTINATION \
       --cloudsql-instance=CLOUDSQL_INSTANCE_ID \
       --host=DESTINATION_HOST_IP_ADDRESS \
       --port=DESTINATION_PORT_NUMBER \
       --dbm-port=DESTINATION_DBM_PORT_NUMBER \
       --username=sqlserver \
       --password=CLOUD_SQL_DB_USER_PASSWORD

   次のように置き換えます。

   • DESTINATION_CONNECTION_PROFILE_ID: 宛先接続プロファイルの機械可読識別子（sqlserver-dag-dest-profile など）。
   • DESTINATION_CONNECTION_PROFILE_NAME は、移行先接続プロファイルの人が読める名前に置き換えます。この値は、 Google Cloud コンソールの Database Migration Service に表示されます。
   • REGION は、接続プロファイルを保存するリージョンの識別子に置き換えます。
   • CLOUDSQL_INSTANCE_ID は、移行先の Cloud SQL for SQL Server インスタンスの名前に置き換えます。
   • DESTINATION_HOST_IP_ADDRESS は、移行元の SQL Server インスタンスから到達可能な移行先の Cloud SQL for SQL Server インスタンスのプライベート IP アドレス（または Private Service Connect エンドポイントの IP アドレス）に置き換えます。
   • DESTINATION_PORT_NUMBER は、移行先の Cloud SQL for SQL Server インスタンスのデータベース ポート番号（1433）に置き換えます。
   • DESTINATION_DBM_PORT_NUMBER は、移行先の Cloud SQL for SQL Server インスタンスのデータベース ミラーリング ポート番号（5022）に置き換えます。
   • CLOUD_SQL_DB_USER_PASSWORD は、移行先の Cloud SQL for SQL Server インスタンスの sqlserver ユーザーのパスワードに置き換えます（--username は sqlserver に設定する必要があります）。

3. 継続的な DAG 移行ジョブを作成します。
   gcloud database-migration migration-jobs create コマンドを実行します（クリックして展開）。

   gcloud database-migration migration-jobs create

   このサンプルでは、オプションの --no-async フラグを使用して、すべてのオペレーションが同期的に実行されるようにしています。そのため、一部のコマンドは完了するまでに時間がかかることがあります。--no-async フラグをスキップして、コマンドを非同期で実行できます。その場合は、 gcloud database-migration operations describe コマンドを使用して、オペレーションが成功したかどうかを確認する必要があります。

   gcloud database-migration migration-jobs create MIGRATION_JOB_ID \
       --no-async \
       --display-name=MIGRATION_JOB_NAME \
       --region=REGION \
       --type=CONTINUOUS \
       --source=SOURCE_CONNECTION_PROFILE_ID \
       --destination=DESTINATION_CONNECTION_PROFILE_ID \
       --sqlserver-dag-source-ag=SOURCE_AVAILABILITY_GROUP_NAME \
       --sqlserver-dag-linked-server=LINKED_SERVER_NAME

   次のように置き換えます。

   • MIGRATION_JOB_ID は、移行ジョブの機械で読み取り可能な識別子（例: sqlserver-dag-job）に置き換えます。
   • MIGRATION_JOB_NAME は、移行ジョブの人が読める形式の名前に置き換えます。この値は Google Cloud コンソールに表示されます。
   • REGION は、移行ジョブを作成するリージョンの ID に置き換えます。
   • SOURCE_CONNECTION_PROFILE_ID は、移行元接続プロファイルの ID に置き換えます。
   • DESTINATION_CONNECTION_PROFILE_ID は、宛先接続プロファイルの ID に置き換えます。
   • SOURCE_AVAILABILITY_GROUP_NAME は、移行元の SQL Server インスタンスの可用性グループの名前に置き換えます。
   • LINKED_SERVER_NAME は、移行先の Cloud SQL for SQL Server インスタンスでリンクサーバーを作成して確認するで移行先の Cloud SQL for SQL Server インスタンスに構成したリンクサーバーの名前に置き換えます。

4. 移行ジョブの構成を確認します。
   DAG 移行ジョブを開始する前に、verify を実行して、双方向ネットワーク接続、リンクサーバー RPC アクセス、gcp_dms_db 権限（最小権限を使用している場合）、移行元データベースの所有者（sa が所有するデータベースがないことを確認）、デフォルトのデータファイル パスを検証する必要があります。gcloud database-migration migration-jobs verify コマンドを実行します（クリックして展開）。

   gcloud database-migration migration-jobs verify

   gcloud database-migration migration-jobs verify MIGRATION_JOB_ID \
       --region=REGION

   次のように置き換えます。

   • MIGRATION_JOB_ID は、移行ジョブの ID に置き換えます。
   • REGION は、移行ジョブが保存されているリージョンの ID に置き換えます。

   検証オペレーションのステータスを確認するには、gcloud database-migration operations describe コマンドを実行します。

5. 移行ジョブを開始します。
   検証が成功したら、gcloud database-migration migration-jobs start コマンドを実行します（クリックして展開）。

   gcloud database-migration migration-jobs start

   gcloud database-migration migration-jobs start MIGRATION_JOB_ID \
       --region=REGION

   次のように置き換えます。

   • MIGRATION_JOB_ID は、移行ジョブの ID に置き換えます。
   • REGION は、移行ジョブが保存されているリージョンの ID に置き換えます。
   注意: DAG 移行ジョブを開始すると、Database Migration Service は、移行先の Cloud SQL for SQL Server インスタンスで cloud sql enable dag support フラグを on に自動的に設定します。cloud sql enable dag support フラグを手動で変更または削除しないでください。

移行をモニタリングして検証する

DAG 移行ジョブの実行中に、 Google Cloud コンソールで進行状況をモニタリングし、CDC 中に読み取り専用モードで移行先データベースをクエリして、アクティブなレプリケーションを管理できます。

Google Cloud コンソールで進行状況をモニタリングする

実行中の DAG 移行ジョブは、他の Database Migration Service 移行ジョブと同様に、 Google Cloud コンソールの [移行ジョブの詳細] ページでモニタリングできます。

• 移行ジョブの詳細ページの [データベース] テーブルで、リアルタイム フェーズ（初期フルロード中の Full dump、継続的なレプリケーション中の CDC、データベース レベルのエラー メッセージ）と、可用性グループ内の各データベースの復元ラグを確認します。
• [モニタリング] タブで、[復元ラグ]（datamigration.googleapis.com/migration_job/max_replica_sec_lag。分散可用性グループのレプリケーション ラグをデータベースごとに秒単位で報告します）グラフを表示します。

モニタリング指標とジョブの状態の詳細については、移行ジョブの指標と移行ジョブのステータス コードをご覧ください。

CDC 中に読み取り専用モードで移行されたデータベースを確認する

バックアップ ベースの移行（移行先のデータベースはプロモートされるまで RESTORING 状態のまま）とは異なり、分散型可用性グループの移行では、移行先の Cloud SQL for SQL Server データベースが CDC フェーズに入るとすぐに、読み取り専用モードでクエリを実行できます。

ソース インスタンスの SQL ログインが所有するデータベースごとに、Database Migration Service は、移行先の Cloud SQL for SQL Server インスタンスに、gcp_dms_、6 文字の識別子、ソース所有者名（例: gcp_dms_a1b2c3_myowner）を接頭辞として付加したログインを自動的に作成します。プロモーション前にそのログインでデータベースをクエリするには、移行先の Cloud SQL for SQL Server インスタンスに sqlserver として接続し、sys.server_principals で生成されたログイン名を見つけて、パスワードをリセットします。

SELECT name FROM sys.server_principals WHERE name LIKE 'gcp_dms_%';
GO
ALTER LOGIN [GENERATED_DMS_OWNER_LOGIN] WITH PASSWORD = 'NEW_OWNER_PASSWORD';
GO

次のように置き換えます。

• GENERATED_DMS_OWNER_LOGIN は、クエリによって返された生成されたデータベース オーナーのログイン名に置き換えます。
• NEW_OWNER_PASSWORD は、ログイン用の新しいパスワードに置き換えます。

移行されたオブジェクトとデータの検証の詳細については、移行を検証するをご覧ください。

アクティブな DAG 移行ジョブを管理する（省略可）

移行ジョブが CDC フェーズで実行されている間、次の管理オペレーションを実行できます。

• ALTER AVAILABILITY GROUP ... ADD DATABASE または ALTER AVAILABILITY GROUP ... REMOVE DATABASE を実行して、移行元 SQL Server インスタンスの移行元可用性グループにデータベースを追加または削除します。Database Migration Service は、次のポーリング サイクルで変更を自動的に検出し、移行先の Cloud SQL for SQL Server インスタンスを更新します。
• gcloud database-migration migration-jobs stop を実行して、データ レプリケーションを一時的に停止します。DAG 移行ジョブの停止は、定義された短い期間にのみ使用してください。レプリケーションが停止している間もトランザクション ログに更新が蓄積され、トランザクション ログディスクがいっぱいになる可能性があるためです。停止状態から、gcloud database-migration migration-jobs resume を実行してデータ レプリケーションを再開するか、gcloud database-migration migration-jobs delete を実行して移行を完了し、必要なクリーンアップを実行できます。
• gcloud database-migration migration-jobs restart を実行して、失敗した移行ジョブを再開します。DAG 移行ジョブを再開すると、移行先の Cloud SQL for SQL Server インスタンスで移行されたデータベースが削除され、分散可用性グループが再作成され、ネットワーク経由で最初のフルロードが再実行されます。

移行をプロモート、フェイルバック、または完了する

アプリケーションを Cloud SQL for SQL Server に切り替える準備ができたら、移行ジョブをプロモートします。DAG 移行でジョブをプロモートすると、Cloud SQL for SQL Server が読み取り / 書き込みプライマリに切り替わり、移行ジョブが FAILBACK フェーズ（Google Cloud CLI と API レスポンスでは PHASE_FAILBACK）に移行します。このフェーズでは、ソース SQL Server インスタンスへのリバース レプリケーションがアクティブになります。

1. ソース SQL Server データベースへのアプリケーションの書き込みを停止し、 Google Cloud コンソールの [復元ラグ] 指標をチェックして、レプリケーション ラグがゼロに達したことを確認します。

2. 移行ジョブをプロモートして Cloud SQL にカットオーバーします。
   gcloud database-migration migration-jobs promote コマンドを実行します（クリックして展開）。

   gcloud database-migration migration-jobs promote

   gcloud database-migration migration-jobs promote MIGRATION_JOB_ID \
       --region=REGION

   次のように置き換えます。

   • MIGRATION_JOB_ID は、移行ジョブの ID に置き換えます。
   • REGION は、移行ジョブが保存されているリージョンの ID に置き換えます。

   プロモート中に、Database Migration Service は次のアクションを実行します。

   • 分散可用性グループを同期 commit に設定し、すべてのソース データベースで CHECKPOINT を発行します。すべてのトランザクションがデータ損失なしで同期されるのを待機し、可用性グループのロールを反転して、移行先の Cloud SQL for SQL Server インスタンスが読み取り / 書き込みのプライマリになり、元のソース SQL Server インスタンスがセカンダリになります。
   • 移行ジョブを Running 状態に維持し、サブ状態を FAILBACK フェーズ（Google Cloud CLI と API レスポンスでは PHASE_FAILBACK）に移行します。これにより、移行先の Cloud SQL for SQL Server から移行元の SQL Server インスタンスに新しい書き込みが継続的に複製されます。

   プロモートが完了したら、アプリケーションを新しい Cloud SQL for SQL Server インスタンスに接続します。

3. （省略可）ソース SQL Server インスタンスにフェイルバックする。
   移行ジョブが FAILBACK フェーズにあるときに、アプリケーションを Cloud SQL for SQL Server に切り替えた後に問題が発生した場合は、Cloud SQL for SQL Server でのアプリケーションの書き込みを停止し、--failback フラグを指定して gcloud database-migration migration-jobs promote コマンドを実行することで、データ損失なしでカットオーバーを元に戻すことができます（クリックして展開）。

   gcloud database-migration migration-jobs promote --failback

   gcloud database-migration migration-jobs promote MIGRATION_JOB_ID \
       --region=REGION \
       --failback

   次のように置き換えます。

   • MIGRATION_JOB_ID は、移行ジョブの ID に置き換えます。
   • REGION は、移行ジョブが保存されているリージョンの ID に置き換えます。

   FAILBACK フェーズ中に --failback フラグを指定して promote を実行すると、Cloud SQL for SQL Server に書き込まれたすべての変更が同期され、レプリケーションの方向が再度切り替わります。これにより、元のソース SQL Server 可用性グループが読み取り / 書き込みプライマリになり、Cloud SQL for SQL Server がセカンダリになり、移行ジョブが CDC フェーズに戻ります。--failback は、移行ジョブが FAILBACK フェーズにある場合にのみ有効です。FAILBACK フェーズ中に --failback を指定せずに promote を実行する（または CDC フェーズ中に --failback を渡す）と、検証が FAILED_PRECONDITION エラーで失敗し、移行ジョブは実行されたままになります。

4. （省略可）移行ジョブを削除する前にデータ レプリケーションを停止します。
   移行ジョブを完全に削除する前にデータ レプリケーションを停止する場合は、gcloud database-migration migration-jobs stop コマンドを実行します（クリックして展開）。

   gcloud database-migration migration-jobs stop

   gcloud database-migration migration-jobs stop MIGRATION_JOB_ID \
       --region=REGION

   次のように置き換えます。

   • MIGRATION_JOB_ID は、移行ジョブの ID に置き換えます。
   • REGION は、移行ジョブが保存されているリージョンの ID に置き換えます。
   注意: 移行ジョブを停止すると、データ レプリケーションが停止しますが、レプリケーションが停止している間もトランザクション ログに更新が蓄積されるため、定義された短い期間にのみ使用する必要があります。Stopped 状態から、gcloud database-migration migration-jobs resume を実行してデータ レプリケーションを再開するか、次のステップで gcloud database-migration migration-jobs delete を実行して移行を完了し、必要なクリーンアップを実行します。

5. 移行を完了して移行ジョブを削除します。
   アプリケーションが新しい Cloud SQL for SQL Server 移行先インスタンスで完全に動作していることを確認し、移行元 SQL Server インスタンスへのリバース レプリケーションが不要になったら、移行ジョブを（Running 状態または Stopped 状態から）削除して移行を完了し、必要なクリーンアップを実行します。 gcloud database-migration migration-jobs delete コマンドを実行します（クリックして展開）。

   gcloud database-migration migration-jobs delete

   このコマンドは、完了するために入力が必要なインタラクティブな確認プロンプトを返します。 オプションの --quiet フラグを使用すると、確認プロンプトをスキップできます。

   gcloud database-migration migration-jobs delete MIGRATION_JOB_ID \
       --region=REGION

   次のように置き換えます。

   • MIGRATION_JOB_ID は、移行ジョブの ID に置き換えます。
   • REGION は、移行ジョブが保存されているリージョンの ID に置き換えます。

   移行ジョブを削除すると、移行が完了し、アクティブなリバース レプリケーションが停止します。また、両方のインスタンスで分散可用性グループとデータベース ミラーリングの証明書が削除され、DAG レプリケーション中に制限されている Cloud SQL for SQL Server の機能（ポイントインタイム リカバリ（PITR）やリードレプリカなど）を有効にできます。

   移行ジョブを削除した後、必要に応じて、移行先の Cloud SQL for SQL Server インスタンスで cloud sql enable dag support データベース フラグを無効にするか削除し、Cloud SQL for SQL Server インスタンス（EXEC master.dbo.sp_dropserver @server = N'LINKED_SERVER_NAME', @droplogins = 'droplogins';）でリンクサーバーを削除し、移行元の SQL Server インスタンスで gcp_dms_db ヘルパー データベースと移行ログインを削除します。