Esegui la migrazione da SQL Server autogestito utilizzando i gruppi di disponibilità distribuiti

Questa guida mostra come eseguire la migrazione dei database da un'istanza SQL Server Enterprise Edition autogestita a Cloud SQL per SQL Server Enterprise Edition tramite una connessione di rete privata utilizzando un gruppo di disponibilità distribuito (DAG) in Database Migration Service.

Con una migrazione DAG, Database Migration Service trasmette in streaming sia il caricamento completo iniziale (noto come fase FULL_DUMP) sia la replica continua del log delle transazioni (nota come fase Change Data Capture - CDC) direttamente sulla rete tra il gruppo di disponibilità di origine e il gruppo di disponibilità Cloud SQL per SQL Server di destinazione. Per ulteriori informazioni su architettura, prerequisiti e limitazioni delle migrazioni DAG, consulta Informazioni sulle migrazioni dei gruppi di disponibilità distribuiti (DAG). Per eseguire la migrazione utilizzando i file di backup archiviati in Cloud Storage, consulta Esegui la migrazione dei database SQL Server in Cloud SQL per SQL Server.

Per eseguire una migrazione di un gruppo di disponibilità distribuito, completa le seguenti attività di alto livello:

1. Crea e prepara l'istanza Cloud SQL per SQL Server di destinazione.
2. Prepara l'istanza SQL Server di origine e il gruppo di disponibilità.
3. Stabilisci una connessione di rete privata bidirezionale e configura un server collegato.
4. Crea i profili di connessione ed esegui il job di migrazione.
5. Monitora e verifica la migrazione.
6. Promuovi, esegui il failback o completa la migrazione.

Costi

Per le migrazioni omogenee a Cloud SQL, Database Migration Service viene offerto senza costi aggiuntivi. Tuttavia, si applicano i prezzi standard di Cloud SQL e della rete. Per stimare i costi di utilizzo, utilizza il Calcolatore prezzi.

Prima di iniziare

1. Verifica che i database di origine e di destinazione soddisfino tutti i prerequisiti e le limitazioni per le migrazioni dei gruppi di disponibilità distribuiti (tra cui l'esecuzione di Enterprise Edition, l'archiviazione dei file di dati nella directory di dati predefinita e il mancato utilizzo di sa come proprietario del database). Consulta Informazioni sulle migrazioni dei gruppi di disponibilità distribuiti (DAG).
2. Scegli la regione Google Cloud per la migrazione. Database Migration Service è un prodotto completamente regionale; tutte le entità correlate alla migrazione (profili di connessione di origine e di destinazione, job di migrazione e istanza Cloud SQL per SQL Server di destinazione) devono risiedere nella stessa regione.
3. Nella console Google Cloud , nella pagina di selezione del progetto, seleziona o crea un progetto Google Cloud .

   Vai al selettore di progetti

4. Abilita le API Database Migration Service, Compute Engine e Cloud SQL Admin.

   Abilita le API

Ruoli obbligatori

Assicurati che nel tuo progettoGoogle Cloud siano concessi i seguenti ruoli IAM:

• Account utente che esegue la migrazione:
  • Database Migration Admin (roles/datamigration.admin)
  • Cloud SQL Editor (roles/cloudsql.editor)
• Account di servizio Database Migration Service (service-<var>PROJECT_NUMBER</var>@gcp-sa-datamigration.iam.gserviceaccount.com):
  • Database Migration Service Agent (roles/datamigration.serviceAgent)
  • Cloud SQL Editor (roles/cloudsql.editor)
  • Cloud SQL Studio User (roles/cloudsql.studioUser)

Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso.

Crea e prepara l'istanza Cloud SQL per SQL Server di destinazione

In questo passaggio, crei l'istanza Cloud SQL per SQL Server Enterprise Edition di destinazione e attivi il flag di database richiesto per i server collegati.

1. Crea l'istanza Cloud SQL per SQL Server di destinazione. Per istruzioni dettagliate sulla creazione, consulta Crea un'istanza Cloud SQL per SQL Server. Assicurati che l'istanza soddisfi i seguenti requisiti per le migrazioni dei gruppi di disponibilità distribuiti:
   • Seleziona Enterprise Edition (versione 2017, 2019, 2022 o 2025).
   • Configura il networking privato in modo che sia in linea con il modo in cui prevedi di connettere l'istanza SQL Server di origine e l'istanza Cloud SQL per SQL Server di destinazione. Abilita l' accesso privato ai servizi se prevedi di connettere le tue istanze tramite il peering Virtual Private Cloud o utilizza Private Service Connect se prevedi di connettere le tue istanze utilizzando un endpoint Private Service Connect in entrata e un collegamento di rete Private Service Connect in uscita.

     Non attivare sia l'accesso privato ai servizi sia Private Service Connect sulla stessa istanza Cloud SQL per SQL Server di destinazione. Cloud SQL per SQL Server non supporta i server collegati quando entrambi sono abilitati. Per i dettagli completi sulla configurazione del networking, consulta Stabilisci la connettività di rete privata bidirezionale.

   • Mantieni disabilitato il recupero point-in-time (PITR) e non aggiungere repliche di lettura fino a quando non avrai completato ed eliminato il job di migrazione del DAG.
   • Se un database di origine è di proprietà di un accesso Windows Active Directory, cambia il proprietario del database di origine in un accesso SQL prima della migrazione oppure unisci l'istanza Cloud SQL per SQL Server di destinazione ad Active Directory in modo che Database Migration Service possa creare automaticamente l'accesso Windows corrispondente nell'istanza di destinazione all'avvio del job di migrazione. Per istruzioni, consulta Configura Managed Microsoft AD per Cloud SQL per SQL Server.
2. Attiva il flag di database cloudsql enable linked servers (impostato su on) nell'istanza Cloud SQL per SQL Server di destinazione. Per istruzioni sull'impostazione dei flag, consulta Gestisci i server collegati e Configura i flag di database.

   Questo flag è necessario in un secondo momento in questa guida, quando crei e verifichi il server collegato nell'istanza Cloud SQL per SQL Server di destinazione.

Prepara l'istanza SQL Server di origine

In questo passaggio, attivi i gruppi di disponibilità Always On nell'istanza SQL Server di origine, crei un endpoint e un certificato di mirroring del database, crei un accesso SQL dedicato per Database Migration Service e prepari il gruppo di disponibilità di origine.

Abilita i gruppi di disponibilità Always On

Assicurati che la funzionalità Gruppi di disponibilità Always On sia abilitata nell'istanza SQL Server di origine:

• Per Windows, consulta Abilita e disabilita i gruppi di disponibilità Always On nella documentazione di Microsoft.
• Per Linux, consulta Configura il gruppo di disponibilità Always On di SQL Server per l'alta affidabilità su Linux nella documentazione di Microsoft.

Crea l'endpoint e il certificato di mirroring del database

In SQL Server, i gruppi di disponibilità distribuiti trasmettono dati e log delle transazioni tra le istanze tramite endpoint TCP DATABASE_MIRRORING (DBM) (porta predefinita 5022). Poiché l'istanza SQL Server autogestita e l'istanza Cloud SQL per SQL Server di destinazione sono istanze autonome, richiedono l'autenticazione reciproca basata su certificato e la crittografia AES per stabilire l'attendibilità sull'endpoint DBM.

Devi solo creare un certificato e associarlo all'endpoint DATABASE_MIRRORING nell'istanza SQL Server di origine. Non è necessario esportare manualmente i file dei certificati o creare certificati nell'istanza Cloud SQL per SQL Server di destinazione:

• Quando avvii il job di migrazione, Database Migration Service configura automaticamente l'endpoint e il certificato DATABASE_MIRRORING nell'istanza Cloud SQL per SQL Server di destinazione e utilizza il server collegato per scambiare le chiavi pubbliche tra le due istanze.
• Quando elimini il job di migrazione dopo aver completato il cutover, Database Migration Service rimuove automaticamente i certificati importati da entrambe le istanze.

Se l'istanza SQL Server di origine non ha già un endpoint DATABASE_MIRRORING autenticato con un certificato, creane uno:

1. Connettiti all'istanza di origine con un client SQL, ad esempio l'utilità sqlcmd.
2. Esegui i seguenti comandi T-SQL per creare una chiave master del database, un certificato e un endpoint DATABASE_MIRRORING in ascolto sulla porta DBM scelta (predefinita 5022):

   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

   Sostituisci quanto segue:

   • MASTER_KEY_PASSWORD con una password per criptare la chiave master del database.
   • SOURCE_CERT_NAME con un nome per il certificato di mirroring del database di origine (ad esempio dbmCertificate).
   • CERT_EXPIRY_DATE con la data di scadenza del certificato nel formato YYYYMMDD.
   • HADR_ENDPOINT_NAME con il nome dell'endpoint di mirroring del database.
   • SOURCE_DBM_PORT_NUMBER con il numero di porta TCP per il traffico di mirroring del database (valore predefinito 5022).

Crea l'accesso e le autorizzazioni dedicati di Database Migration Service

Database Migration Service si connette all'istanza SQL Server di origine tramite il server collegato utilizzando un accesso SQL dedicato che fornisci nel profilo di connessione di origine. Puoi configurare questo accesso concedendo il ruolo server sysadmin o configurando le autorizzazioni con privilegio minimo con il database helper gcp_dms_db:

Concedi il ruolo sysadmin

Se la tua policy di sicurezza consente di concedere il ruolo server sysadmin all'accesso per la migrazione, esegui i seguenti comandi 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

Sostituisci quanto segue:

• SOURCE_USERNAME con il nome di accesso SQL utilizzato da Database Migration Service per connettersi all'istanza di origine (ad esempio, cloud_dms_login).
• SOURCE_PASSWORD con la password per l'accesso a SOURCE_USERNAME.
• SOURCE_USER con il nome utente del database mappato a SOURCE_USERNAME (ad esempio cloud_dms_user).
• HADR_ENDPOINT_NAME con il nome dell'endpoint di mirroring del database (ad esempio, Hadr_endpoint).

Privilegio minimo (gcp_dms_db)

Se la tua policy di sicurezza vieta la concessione di sysadmin all'accesso per la migrazione, crea il database helper gcp_dms_db dedicato (di proprietà di sa con TRUSTWORTHY ON), crea le tre stored procedure wrapper di Database Migration Service e concedi autorizzazioni granulari all'accesso per la migrazione:

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

Sostituisci quanto segue:

• SOURCE_USERNAME con il nome di accesso SQL utilizzato da Database Migration Service per connettersi all'istanza di origine (ad esempio, cloud_dms_login).
• SOURCE_PASSWORD con la password per l'accesso a SOURCE_USERNAME.
• SOURCE_USER con il nome utente del database mappato a SOURCE_USERNAME (ad esempio cloud_dms_user).
• HADR_ENDPOINT_NAME con il nome dell'endpoint di mirroring del database (ad esempio, Hadr_endpoint).
• DATABASE_NAME con il nome di ogni database di origine nel tuo gruppo di disponibilità. La concessione di db_backupoperator su ogni database migrato è richiesta dalla verifica preflight di Database Migration Service e consente di eseguire il flush dei log delle transazioni con CHECKPOINT durante la promozione.

Prepara i database di origine e il gruppo di disponibilità

Puoi eseguire la migrazione dei database da un gruppo di disponibilità Always On esistente o creare un nuovo gruppo di disponibilità autonomo (CLUSTER_TYPE = NONE). Prima di continuare, verifica i seguenti requisiti:

• Ogni database nel gruppo di disponibilità utilizza il modello di recupero FULL, non è di proprietà di sa e archivia i propri file di dati (.mdf e .ndf) nella directory di dati predefinita.
• Se riutilizzi un gruppo di disponibilità esistente, verifica che l'endpoint di mirroring del database sia configurato sulla porta 5022 (o sulla porta DBM scelta), che SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL) sia abilitato sulla replica in modo che i database secondari rimangano leggibili con stringhe di connessione standard dopo che la promozione ha invertito i ruoli DAG e che i dati di accesso per la migrazione abbiano CONNECT ON ENDPOINT. Se il gruppo di disponibilità di origine ha più repliche e un listener del gruppo di disponibilità configurato, utilizza l'indirizzo IP del listener come <var>SOURCE_HOST_IP_ADDRESS</var> durante la configurazione del server collegato e del profilo di connessione di origine, in modo che la migrazione possa riprendere se si verifica un failover nel gruppo di disponibilità di origine.

Per preparare un database e creare un nuovo gruppo di disponibilità autonomo (CLUSTER_TYPE = NONE), esegui i seguenti comandi 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

Sostituisci quanto segue:

• DATABASE_NAME con il nome del database da includere nel gruppo di disponibilità.
• DB_OWNER_LOGIN con un accesso non sa per possedere il database.
• SOURCE_AVAILABILITY_GROUP_NAME con il nome del tuo gruppo di disponibilità di origine (ad esempio, source_ag).
• SOURCE_SERVER_NAME con il nome del server dell'istanza SQL Server di origine (corrispondente al valore restituito da SELECT @@SERVERNAME).
• SOURCE_DBM_PORT_NUMBER con il numero di porta TCP dell'endpoint di mirroring del database (valore predefinito 5022).

Nota: l'esecuzione di BACKUP DATABASE ... TO DISK = 'NUL' è un requisito locale di SQL Server per inizializzare la catena di log delle transazioni del database dopo il passaggio al modello di recupero FULL prima di aggiungerlo a un gruppo di disponibilità. Questo comando inizializza la catena di log locale per il gruppo di disponibilità e non crea né carica file di backup. Quando avvii il job di migrazione, Database Migration Service configura il gruppo di disponibilità distribuito per eseguire lo streaming del caricamento completo iniziale direttamente sulla rete.

Stabilisci una connettività di rete privata bidirezionale

Per le migrazioni DAG, Database Migration Service comunica con l'istanza Cloud SQL per SQL Server di destinazione tramite API Google Cloud interne, esegue query di orchestrazione sull'istanza SQL Server di origine tramite un server collegato nell'istanza Cloud SQL per SQL Server di destinazione e trasmette i dati direttamente tra le due istanze su una rete privata. Questa migrazione richiede di stabilire una connessione IP privata bidirezionale direttamente tra l'host SQL Server di origine e l'istanza Cloud SQL per SQL Server di destinazione tramite la rete Virtual Private Cloud. La connettività IP pubblico tra le istanze di origine e di destinazione non è supportata.

Porte e indirizzi IP richiesti

La configurazione di rete deve consentire il traffico tra l'istanza SQL Server di origine e l'istanza Cloud SQL per SQL Server di destinazione sulle seguenti due porte TCP:

Porta	Direzione	Finalità
Porta del database SQL Server (valore predefinito 1433)	Dall'istanza Cloud SQL per SQL Server di destinazione all'istanza SQL Server di origine	Utilizzato dal server collegato nell'istanza Cloud SQL per SQL Server di destinazione per eseguire query di convalida preflight, scambio di certificati e orchestrazione DAG nell'istanza di origine.
Porta di mirroring del database (DBM) (valore predefinito 5022)	Bidirezionale tra l'istanza SQL Server di origine e l'istanza Cloud SQL per SQL Server di destinazione	Utilizzato dai gruppi di disponibilità di origine e di destinazione per trasmettere in streaming il carico completo iniziale durante FULL_DUMP, le modifiche in corso al database durante CDC e la replica inversa durante FAILBACK.

Quando configuri il server collegato e i profili di connessione più avanti in questa guida, fornisci due indirizzi IP privati:

• SOURCE_HOST_IP_ADDRESS (utilizzato nel parametro Linked Server @datasrc e nel flag del profilo di connessione di origine --host) è l'indirizzo IP privato dell'host SQL Server di origine (o l'indirizzo IP del listener del gruppo di disponibilità, che è preferibile se configurato per un gruppo di disponibilità di origine con più repliche, in modo che la migrazione possa riprendere se si verifica un failover nel gruppo di disponibilità di origine) raggiungibile dall'istanza Cloud SQL per SQL Server di destinazione.
• DESTINATION_HOST_IP_ADDRESS (utilizzato nel flag del profilo di connessione di destinazione --host) è l'indirizzo IP privato dell'istanza Cloud SQL per SQL Server di destinazione (o l'indirizzo IP dell'endpoint Private Service Connect) raggiungibile dall'host SQL Server di origine.

Configura il metodo di networking privato

Completa la configurazione del routing di rete per il metodo di networking (accesso privato ai servizi o Private Service Connect) che hai abilitato nell'istanza Cloud SQL per SQL Server di destinazione:

Accesso privato ai servizi

L'accesso privato ai servizi esegue il peering della tua rete Virtual Private Cloud con la rete Virtual Private Cloud del producer di servizi gestiti da Google che ospita l'istanza Cloud SQL per SQL Server di destinazione:

1. Verifica che la tua rete Virtual Private Cloud abbia un intervallo di indirizzi IPv4 interni allocato e una connessione privata (peering Virtual Private Cloud con servicenetworking-googleapis-com) abilitata per l'istanza Cloud SQL per SQL Server di destinazione. Per istruzioni, consulta Configura l'IP privato per Cloud SQL per SQL Server.
2. Configura il routing all'host SQL Server di origine in base a dove è ospitato:
   • Se l'istanza di origine viene eseguita su una macchina virtuale Compute Engine nella stessa rete Virtual Private Cloud, non è necessario alcun routing aggiuntivo. La macchina virtuale e l'istanza Cloud SQL per SQL Server possono raggiungere direttamente i rispettivi indirizzi IP privati tramite la connessione di peering Virtual Private Cloud.
   • Se l'istanza di origine viene eseguita on-premise, in un altro cloud provider o in un'altra rete Virtual Private Cloud, completa i seguenti passaggi in modo che le route vengano scambiate attraverso il confine del peering transitivo:
     1. Connetti la tua rete esterna alla rete Virtual Private Cloud utilizzando Cloud VPN o Cloud Interconnect. Per istruzioni, consulta Accedi a un'istanza Cloud SQL da un'origine esterna.
     2. In router Cloud, annuncia l'intervallo di indirizzi IP allocato di Cloud SQL per SQL Server alla tua rete di origine. Per le istruzioni, consulta Pubblicizza intervalli IP personalizzati.
     3. Aggiorna la connessione di peering servicenetworking-googleapis-com nella tua rete Virtual Private Cloud per abilitare Esporta route personalizzate in modo che l'istanza Cloud SQL per SQL Server apprenda le route alla tua rete di origine. Per le istruzioni, consulta Aggiorna una connessione di peering.
3. Registra gli indirizzi IP privati per la migrazione:
   • Utilizza l'indirizzo IP interno dell'host SQL Server di origine come SOURCE_HOST_IP_ADDRESS.
   • Utilizza l'indirizzo IP privato assegnato all'istanza Cloud SQL per SQL Server di destinazione (mostrato nella pagina Panoramica dell'istanza) come DESTINATION_HOST_IP_ADDRESS.

Private Service Connect

Se utilizzi Private Service Connect anziché l'accesso privato ai servizi, devi configurare sia un endpoint Private Service Connect in entrata (in modo che l'istanza di origine possa connettersi a Cloud SQL per SQL Server sulla porta 5022) sia un'interfaccia Private Service Connect in uscita (in modo che Cloud SQL per SQL Server possa avviare connessioni di server collegati e DAG all'istanza di origine sulle porte 1433 e 5022):

1. Verifica che l'istanza Cloud SQL per SQL Server di destinazione abbia Private Service Connect abilitato (senza IP privato) e specifichi i progetti consumer consentiti. Per istruzioni, consulta Configura Private Service Connect.
2. Per consentire le connessioni in entrata dall'host SQL Server di origine all'istanza Cloud SQL per SQL Server di destinazione, prenota un indirizzo IP interno nella subnet del tuo Virtual Private Cloud e crea un endpoint Private Service Connect (regola di forwarding) che ha come target il collegamento al servizio dell'istanza Cloud SQL per SQL Server. Per le istruzioni, consulta Crea un endpoint Private Service Connect.
3. Per consentire le connessioni in uscita dall'istanza Cloud SQL per SQL Server di destinazione all'host SQL Server di origine (necessario per i server collegati e le connessioni DAG in uscita), crea un collegamento di rete Virtual Private Cloud nella subnet che può instradare al tuo host di origine e configura la connettività in uscita di Private Service Connect nell'istanza Cloud SQL per SQL Server di destinazione. Per istruzioni, consulta Crea e gestisci i collegamenti di rete e Configura la connettività in uscita di Private Service Connect.
4. Registra gli indirizzi IP privati per la migrazione:
   • Utilizza l'indirizzo IP privato dell'host SQL Server di origine come SOURCE_HOST_IP_ADDRESS.
   • Utilizza l'indirizzo IP interno dell'endpoint di Private Service Connect (regola di forwarding) nella tua rete Virtual Private Cloud come DESTINATION_HOST_IP_ADDRESS.

Configura le regole firewall del Virtual Private Cloud e dell'host di origine

1. Nella tua rete Virtual Private Cloud, crea regole firewall in entrata e in uscita che consentano il traffico TCP tra l'indirizzo IP SQL Server di origine (SOURCE_HOST_IP_ADDRESS) e l'intervallo IP Cloud SQL per SQL Server di destinazione (o l'endpoint Private Service Connect e la subnet del collegamento di rete) sia sulla porta del database (predefinita 1433) sia sulla porta di mirroring del database (predefinita 5022). Per ulteriori informazioni sulla creazione di regole firewall, consulta Crea regole firewall.
2. Sulla macchina SQL Server di origine, verifica le seguenti impostazioni del firewall di rete e host:
   • TCP/IP è abilitato in Gestione configurazione SQL Server (o mssql-conf su Linux) e l'istanza è in ascolto su una porta TCP statica (1433 per impostazione predefinita).
   • Il firewall del sistema operativo (ad esempio Windows Defender Firewall o Linux iptables o firewalld) consente le connessioni TCP in entrata sia sulla porta del database (predefinita 1433) sia sulla porta di mirroring del database (predefinita 5022) e le connessioni TCP in uscita verso DESTINATION_HOST_IP_ADDRESS sulla porta 5022.

Verifica la raggiungibilità con i test di connettività di Cloud SQL

Prima di configurare il server collegato, ti consigliamo di eseguire tre Connectivity Tests dalla scheda Connessioni > Connectivity Tests della tua istanza Cloud SQL per SQL Server nella console Google Cloud . Per istruzioni su come eseguire un test di connettività, consulta Gestisci i test di connettività:

1. Per testare la connettività del server collegato in uscita sulla porta 1433, imposta Origine su Istanza Cloud SQL corrente, Destinazione su SOURCE_HOST_IP_ADDRESS e Porta di destinazione su 1433 (o sulla porta del database personalizzata).
2. Per testare la connettività di mirroring del database in uscita sulla porta 5022, imposta Origine su Istanza Cloud SQL corrente, Destinazione su SOURCE_HOST_IP_ADDRESS e Porta di destinazione su 5022 (o sulla porta DBM personalizzata).
3. Per testare la connettività di mirroring del database in entrata sulla porta 5022, imposta Origine su SOURCE_HOST_IP_ADDRESS, Destinazione su Istanza Cloud SQL attuale (o DESTINATION_HOST_IP_ADDRESS se utilizzi Private Service Connect) e Porta di destinazione su 5022 (o sulla porta DBM personalizzata).

Crea e verifica il server collegato nell'istanza Cloud SQL per SQL Server di destinazione

Una volta stabilita la connessione di rete, connettiti all'istanza Cloud SQL per SQL Server di destinazione e crea il server collegato che punta all'istanza SQL Server di origine:

1. Connettiti all'istanza Cloud SQL con un client SQL. Puoi utilizzare i seguenti metodi:
   • Client sqlcmd. Puoi utilizzare questo metodo per connetterti all'IP privato dell'istanza, ma potrebbe essere necessario creare una macchina virtuale Compute Engine.
   • Comando gcloud sql connect. Questo comando funziona solo per le istanze Cloud SQL con un indirizzo IP pubblico abilitato.
2. Accedi come utente sqlserver ed esegui i seguenti comandi T-SQL per la versione di Cloud SQL per SQL Server di destinazione per creare un server collegato che punta all'istanza SQL Server di origine, mappa @locallogin = N'sqlserver' al login di migrazione di origine, abilita rpc out e testa la connessione con OPENQUERY (per ulteriori informazioni sulle opzioni del server collegato su Cloud SQL, consulta Gestisci i server collegati):

   Cloud SQL per SQL Server 2017, 2019 e 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 per 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

   Sostituisci quanto segue:

   • LINKED_SERVER_NAME con il nome del tuo server collegato su Cloud SQL per SQL Server (ad esempio, source_sql_linked_server).
   • SOURCE_HOST_IP_ADDRESS con l'indirizzo IP privato dell'istanza SQL Server di origine (o l'indirizzo IP del listener del gruppo di disponibilità se configurato per un gruppo di disponibilità di origine con più repliche).
   • SOURCE_PORT_NUMBER con il numero di porta in cui il motore del database SQL Server di origine accetta le connessioni (valore predefinito 1433).
   • SOURCE_USERNAME con il nome di accesso SQL dedicato che hai creato nell'istanza di origine in Crea l'accesso e le autorizzazioni dedicati di Database Migration Service.
   • SOURCE_PASSWORD con la password per l'accesso a SOURCE_USERNAME.

Crea profili di connessione ed esegui il job di migrazione

Utilizza Google Cloud CLI per creare i profili di connessione di origine e di destinazione, creare il job di migrazione continua del DAG, verificare la configurazione della migrazione e avviare il job di migrazione:

1. Crea il profilo di connessione di origine.
   Esegui il comando gcloud database-migration connection-profiles create sqlserver (fai clic per espandere):

   gcloud database-migration connection-profiles create sqlserver

   Questo esempio utilizza il flag facoltativo --no-async in modo che tutte le operazioni vengano eseguite in modo sincrono. Ciò significa che il completamento di alcuni comandi potrebbe richiedere un po' di tempo. Puoi saltare il flag --no-async per eseguire i comandi in modo asincrono. In questo caso, devi utilizzare il comando gcloud database-migration operations describe per verificare se l'operazione è andata a buon fine.

   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

   Sostituisci quanto segue:

   • SOURCE_CONNECTION_PROFILE_ID con un identificatore leggibile da macchina per il profilo di connessione di origine (ad esempio, sqlserver-dag-source-profile).
   • SOURCE_CONNECTION_PROFILE_NAME con un nome leggibile per il profilo di connessione di origine. Questo valore viene visualizzato in Database Migration Service nella console Google Cloud .
   • REGION con l'identificatore della regione in cui vuoi salvare il profilo di connessione (ad esempio us-central1).
   • SOURCE_HOST_IP_ADDRESS con l'indirizzo IP privato dell'istanza SQL Server di origine (o l'indirizzo IP del listener del gruppo di disponibilità se configurato per un gruppo di disponibilità di origine con più repliche).
   • SOURCE_PORT_NUMBER con il numero di porta in cui il motore del database SQL Server di origine accetta le connessioni (valore predefinito 1433).
   • SOURCE_DBM_PORT_NUMBER con il numero di porta TCP dell'endpoint di mirroring del database di origine (valore predefinito 5022).
   • SOURCE_USERNAME con il nome di accesso SQL dedicato che hai creato nell'istanza di origine in Crea l'accesso e le autorizzazioni dedicati di Database Migration Service.
   • SOURCE_PASSWORD con la password per l'accesso a SOURCE_USERNAME.

2. Crea il profilo di connessione di destinazione.
   Esegui il comando gcloud database-migration connection-profiles create sqlserver (fai clic per espandere):

   gcloud database-migration connection-profiles create sqlserver

   Questo esempio utilizza il flag facoltativo --no-async in modo che tutte le operazioni vengano eseguite in modo sincrono. Ciò significa che il completamento di alcuni comandi potrebbe richiedere un po' di tempo. Puoi saltare il flag --no-async per eseguire i comandi in modo asincrono. In questo caso, devi utilizzare il comando gcloud database-migration operations describe per verificare se l'operazione è andata a buon fine.

   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

   Sostituisci quanto segue:

   • DESTINATION_CONNECTION_PROFILE_ID con un identificatore leggibile da macchina per il profilo di connessione di destinazione (ad esempio, sqlserver-dag-dest-profile).
   • DESTINATION_CONNECTION_PROFILE_NAME con un nome leggibile per il profilo di connessione di destinazione. Questo valore viene visualizzato in Database Migration Service nella console Google Cloud .
   • REGION con l'identificatore della regione in cui vuoi salvare il profilo di connessione.
   • CLOUDSQL_INSTANCE_ID con il nome dell'istanza Cloud SQL per SQL Server di destinazione.
   • DESTINATION_HOST_IP_ADDRESS con l'indirizzo IP privato dell'istanza Cloud SQL per SQL Server di destinazione (o l'indirizzo IP dell'endpoint Private Service Connect) raggiungibile dall'istanza SQL Server di origine.
   • DESTINATION_PORT_NUMBER con il numero di porta del database dell'istanza Cloud SQL per SQL Server di destinazione (1433).
   • DESTINATION_DBM_PORT_NUMBER con il numero di porta del mirroring del database dell'istanza Cloud SQL per SQL Server di destinazione (5022).
   • CLOUD_SQL_DB_USER_PASSWORD con la password dell'utente sqlserver nell'istanza Cloud SQL per SQL Server di destinazione (--username deve essere impostato su sqlserver).

3. Crea il job di migrazione DAG continuo.
   Esegui il comando gcloud database-migration migration-jobs create (fai clic per espandere):

   gcloud database-migration migration-jobs create

   Questo esempio utilizza il flag facoltativo --no-async in modo che tutte le operazioni vengano eseguite in modo sincrono. Ciò significa che il completamento di alcuni comandi potrebbe richiedere un po' di tempo. Puoi saltare il flag --no-async per eseguire i comandi in modo asincrono. In questo caso, devi utilizzare il comando gcloud database-migration operations describe per verificare se l'operazione è andata a buon fine.

   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

   Sostituisci quanto segue:

   • MIGRATION_JOB_ID con un identificatore leggibile da macchina per il job di migrazione (ad esempio, sqlserver-dag-job).
   • MIGRATION_JOB_NAME con un nome leggibile per il job di migrazione. Questo valore viene visualizzato nella console Google Cloud .
   • REGION con l'identificatore della regione in cui vuoi creare il job di migrazione.
   • SOURCE_CONNECTION_PROFILE_ID con l'identificatore del tuo profilo di connessione di origine.
   • DESTINATION_CONNECTION_PROFILE_ID con l'identificatore del profilo di connessione di destinazione.
   • SOURCE_AVAILABILITY_GROUP_NAME con il nome del gruppo di disponibilità nell'istanza SQL Server di origine.
   • LINKED_SERVER_NAME con il nome del server collegato che hai configurato nell'istanza Cloud SQL per SQL Server di destinazione in Crea e verifica il server collegato nell'istanza Cloud SQL per SQL Server di destinazione.

4. Verifica la configurazione del job di migrazione.
   Prima di avviare un job di migrazione DAG, devi eseguire verify per convalidare la connettività di rete bidirezionale, l'accesso RPC al server collegato, le autorizzazioni gcp_dms_db (se utilizzi il privilegio minimo), i proprietari del database di origine (verificando che nessun database sia di proprietà di sa) e i percorsi dei file di dati predefiniti. Esegui il comando gcloud database-migration migration-jobs verify (fai clic per espandere):

   gcloud database-migration migration-jobs verify

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

   Sostituisci quanto segue:

   • MIGRATION_JOB_ID con l'identificatore del tuo job di migrazione.
   • REGION con l'identificatore della regione in cui è salvato il job di migrazione.

   Puoi controllare lo stato dell'operazione di verifica eseguendo il comando gcloud database-migration operations describe.

5. Avvia il job di migrazione.
   Al termine della verifica, esegui il comando gcloud database-migration migration-jobs start (fai clic per espandere):

   gcloud database-migration migration-jobs start

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

   Sostituisci quanto segue:

   • MIGRATION_JOB_ID con l'identificatore del tuo job di migrazione.
   • REGION con l'identificatore della regione in cui è salvato il job di migrazione.
   Attenzione: quando avvii il job di migrazione DAG, Database Migration Service imposta automaticamente il flag cloud sql enable dag support su on nell'istanza Cloud SQL per SQL Server di destinazione. Non modificare o rimuovere manualmente il flag cloud sql enable dag support.

Monitora e verifica la migrazione

Mentre il job di migrazione DAG è in esecuzione, puoi monitorarne l'avanzamento nella console Google Cloud , eseguire query sui database di destinazione in modalità di sola lettura durante CDC e gestire la replica attiva.

Monitora l'avanzamento nella console Google Cloud

Puoi monitorare un job di migrazione DAG in esecuzione nella console Google Cloud nella pagina Dettagli del job di migrazione, proprio come gli altri job di migrazione di Database Migration Service:

• Nella tabella Database della pagina dei dettagli del job di migrazione, visualizza la fase in tempo reale (Full dump durante il caricamento completo iniziale, CDC durante la replica continua ed eventuali messaggi di errore a livello di database) e il ritardo di ripristino per ogni database nel gruppo di disponibilità.
• Nella scheda Monitoraggio, visualizza il grafico Ritardo di ripristino (datamigration.googleapis.com/migration_job/max_replica_sec_lag, che segnala il ritardo di replica del gruppo di disponibilità distribuito in secondi per database).

Per ulteriori informazioni sulle metriche di monitoraggio e sugli stati dei job, consulta Metriche dei job di migrazione e Codici di stato dei job di migrazione.

Verifica i database di cui è stata eseguita la migrazione in modalità di sola lettura durante il CDC

A differenza delle migrazioni basate su backup (in cui i database di destinazione rimangono nello stato RESTORING fino alla promozione), le migrazioni dei gruppi di disponibilità distribuiti consentono di eseguire query sui database Cloud SQL per SQL Server di destinazione in modalità di sola lettura non appena entrano nella fase CDC.

Per ogni database di proprietà di un accesso SQL nell'istanza di origine, Database Migration Service crea automaticamente un accesso nell'istanza Cloud SQL per SQL Server di destinazione con il prefisso gcp_dms_, un identificatore di 6 caratteri e il nome del proprietario di origine (ad esempio gcp_dms_a1b2c3_myowner). Per eseguire query sul database con questo accesso prima della promozione, connettiti all'istanza Cloud SQL per SQL Server di destinazione come sqlserver, trova il nome di accesso generato in sys.server_principals e reimposta la password:

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

Sostituisci quanto segue:

• GENERATED_DMS_OWNER_LOGIN con il nome di accesso del proprietario del database generato restituito dalla query.
• NEW_OWNER_PASSWORD con una nuova password per l'accesso.

Per ulteriori informazioni sulla verifica degli oggetti e dei dati migrati, consulta Verifica una migrazione.

(Facoltativo) Gestisci un job di migrazione DAG attivo

Mentre il job di migrazione è in esecuzione nella fase CDC, puoi eseguire le seguenti operazioni di gestione:

• Aggiungi o rimuovi i database nel gruppo di disponibilità di origine nell'istanza SQL Server di origine eseguendo ALTER AVAILABILITY GROUP ... ADD DATABASE o ALTER AVAILABILITY GROUP ... REMOVE DATABASE. Database Migration Service rileva automaticamente la modifica nel ciclo di polling successivo e aggiorna l'istanza Cloud SQL per SQL Server di destinazione.
• Interrompi temporaneamente la replica dei dati eseguendo gcloud database-migration migration-jobs stop. L'interruzione di un job di migrazione DAG deve essere utilizzata solo per un periodo di tempo definito e breve, perché gli aggiornamenti continuano ad accumularsi nei log delle transazioni mentre la replica è interrotta e possono causare il riempimento dei dischi dei log delle transazioni. Dallo stato interrotto, puoi eseguire gcloud database-migration migration-jobs resume per riprendere la replica dei dati o eseguire gcloud database-migration migration-jobs delete per completare la migrazione ed eseguire la pulizia necessaria.
• Riavvia un job di migrazione non riuscito eseguendo gcloud database-migration migration-jobs restart. Il riavvio di un job di migrazione DAG elimina i database di cui è stata eseguita la migrazione nell'istanza Cloud SQL per SQL Server di destinazione, ricrea il gruppo di disponibilità distribuito ed esegue nuovamente il caricamento completo iniziale sulla rete.

Promuovi, esegui il failback o completa la migrazione

Quando è tutto pronto per passare le tue applicazioni a Cloud SQL per SQL Server, promuovi il job di migrazione. In una migrazione DAG, la promozione del job imposta Cloud SQL per SQL Server come istanza principale di lettura/scrittura e fa passare il job di migrazione alla fase FAILBACK (PHASE_FAILBACK in Google Cloud CLI e nelle risposte dell'API) con replica inversa attiva nell'istanza SQL Server di origine:

1. Interrompi le scritture dell'applicazione nei database SQL Server di origine e controlla la metrica Ritardo di ripristino nella console Google Cloud per verificare che il ritardo di replica abbia raggiunto lo zero.

2. Promuovi il job di migrazione per eseguire il cutover su Cloud SQL.
   Esegui il comando gcloud database-migration migration-jobs promote (fai clic per espandere):

   gcloud database-migration migration-jobs promote

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

   Sostituisci quanto segue:

   • MIGRATION_JOB_ID con l'identificatore del tuo job di migrazione.
   • REGION con l'identificatore della regione in cui è salvato il job di migrazione.

   Durante la promozione, Database Migration Service esegue le seguenti azioni:

   • Imposta il gruppo di disponibilità distribuito sul commit sincrono, esegue un CHECKPOINT su tutti i database di origine, attende la sincronizzazione di tutte le transazioni senza perdita di dati e inverte i ruoli del gruppo di disponibilità in modo che l'istanza Cloud SQL per SQL Server di destinazione diventi l'istanza principale di lettura/scrittura e l'istanza SQL Server di origine originale diventi l'istanza secondaria.
   • Mantiene il job di migrazione nello stato Running e passa il sottostato alla fase FAILBACK (PHASE_FAILBACK in Google Cloud CLI e nelle risposte dell'API), replicando continuamente le nuove scritture da Cloud SQL per SQL Server di destinazione all'istanza SQL Server di origine.

   Una volta completata la promozione, connetti le tue applicazioni alla nuova istanza Cloud SQL per SQL Server.

3. (Facoltativo) Esegui il failback all'istanza SQL Server di origine.
   Se riscontri un problema dopo aver trasferito le tue applicazioni a Cloud SQL per SQL Server mentre il job di migrazione è in fase di FAILBACK, puoi annullare il cutover senza perdita di dati interrompendo le scritture delle applicazioni su Cloud SQL per SQL Server ed eseguendo il comando gcloud database-migration migration-jobs promote con il flag --failback (fai clic per espandere):

   gcloud database-migration migration-jobs promote --failback

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

   Sostituisci quanto segue:

   • MIGRATION_JOB_ID con l'identificatore del tuo job di migrazione.
   • REGION con l'identificatore della regione in cui è salvato il job di migrazione.

   L'esecuzione di promote con il flag --failback durante la fase FAILBACK sincronizza tutte le modifiche scritte in Cloud SQL per SQL Server, cambia nuovamente la direzione della replica in modo che il gruppo di disponibilità SQL Server di origine originale diventi il Primary di lettura/scrittura e Cloud SQL per SQL Server diventi il Secondary e riporta il job di migrazione alla fase CDC. Tieni presente che --failback è valido solo quando il job di migrazione è in fase FAILBACK; l'esecuzione di promote senza --failback durante la fase FAILBACK (o il passaggio di --failback durante la fase CDC) non supera la convalida con un errore FAILED_PRECONDITION e lascia il job di migrazione in esecuzione.

4. (Facoltativo) Interrompi la replica dei dati prima di eliminare il job di migrazione.
   Se vuoi interrompere la replica dei dati prima di eliminare definitivamente il job di migrazione, esegui il comando gcloud database-migration migration-jobs stop (fai clic per espandere):

   gcloud database-migration migration-jobs stop

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

   Sostituisci quanto segue:

   • MIGRATION_JOB_ID con l'identificatore del tuo job di migrazione.
   • REGION con l'identificatore della regione in cui è salvato il job di migrazione.
   Attenzione: l'arresto di un job di migrazione interrompe la replica dei dati, ma deve essere utilizzato solo per un periodo di tempo definito e breve, perché gli aggiornamenti continuano ad accumularsi nei log delle transazioni mentre la replica è interrotta. Da uno stato Stopped, puoi eseguire gcloud database-migration migration-jobs resume per riprendere la replica dei dati o eseguire gcloud database-migration migration-jobs delete nel passaggio successivo per completare la migrazione ed eseguire la pulizia necessaria.

5. Completa la migrazione ed elimina il job di migrazione.
   Dopo aver verificato che le tue applicazioni sono completamente operative con la nuova istanza di destinazione Cloud SQL per SQL Server e che non hai più bisogno della replica inversa nell'istanza SQL Server di origine, elimina il job di migrazione (dallo stato Running o Stopped) per completare la migrazione ed eseguire la pulizia necessaria. Esegui il comando gcloud database-migration migration-jobs delete (fai clic per espandere):

   gcloud database-migration migration-jobs delete

   Questo comando restituisce un prompt di conferma interattivo che richiede il tuo input per essere completato. Puoi saltare la richiesta di conferma utilizzando il flag facoltativo --quiet.

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

   Sostituisci quanto segue:

   • MIGRATION_JOB_ID con l'identificatore del tuo job di migrazione.
   • REGION con l'identificatore della regione in cui è salvato il job di migrazione.

   L'eliminazione del job di migrazione completa la migrazione, interrompe qualsiasi replica inversa attiva, elimina i certificati del gruppo di disponibilità distribuito e del mirroring del database su entrambe le istanze e consente di abilitare le funzionalità di Cloud SQL per SQL Server limitate durante la replica DAG (ad esempio Recupero point-in-time (PITR) o repliche di lettura).

   Dopo aver eliminato il job di migrazione, puoi facoltativamente disabilitare o rimuovere il flag di database cloud sql enable dag support nell'istanza Cloud SQL per SQL Server di destinazione, eliminare il server collegato nell'istanza Cloud SQL per SQL Server (EXEC master.dbo.sp_dropserver @server = N'LINKED_SERVER_NAME', @droplogins = 'droplogins';) e rimuovere il database helper gcp_dms_db e l'accesso per la migrazione nell'istanza SQL Server di origine.