Informazioni sulle migrazioni dei gruppi di disponibilità distribuiti (DAG)

Oltre al flusso di migrazione di backup e ripristino standard di Cloud Storage, Database Migration Service supporta la migrazione di database SQL Server autogestiti a Cloud SQL per SQL Server utilizzando i gruppi di disponibilità distribuiti (DAG) di SQL Server.

Anziché esportare e caricare i file di backup e di log delle transazioni in un bucket Cloud Storage, Database Migration Service configura un gruppo di disponibilità distribuito tra il gruppo di disponibilità di origine e un gruppo di disponibilità secondario gestito nell'istanza Cloud SQL per SQL Server di destinazione. Questa configurazione trasmette in streaming sia il carico completo iniziale sia le modifiche in corso al database direttamente tramite una connessione di rete privata.

Questa pagina tratta i seguenti argomenti:

Quando utilizzare le migrazioni dei DAG

La tabella seguente mette a confronto le migrazioni di backup e ripristino standard con le migrazioni dei gruppi di disponibilità distribuiti (DAG) per aiutarti a scegliere l'approccio migliore per il tuo workload:

Funzionalità o requisito Migrazioni di backup e ripristino standard (guida alla migrazione standard) Migrazioni di gruppi di disponibilità distribuiti (DAG) (guida alla migrazione dei DAG)
Origini supportate SQL Server autogestito, Amazon RDS e Cloud SQL per SQL Server. SQL Server autogestito (Enterprise Edition) con gruppi di disponibilità Always On.
Meccanismo di spostamento dei dati File di backup completo (.bak), backup differenziale facoltativo (.diff) e log delle transazioni (.trn) gestiti temporaneamente in Cloud Storage. Streaming di rete diretto su un endpoint di mirroring del database SQL Server (DBM) (non sono necessari file di backup o bucket Cloud Storage).
Connettività di rete Non è richiesta alcuna connettività tra origine e destinazione. È richiesta la connettività con IP privato bidirezionale sulla porta del database SQL Server (predefinita 1433) e sulla porta di mirroring del database (predefinita 5022).
Accesso al database di destinazione durante la migrazione I database rimangono in modalità RESTORING (non accessibili alle query) fino alla promozione. I database sono accessibili in modalità di sola lettura durante la fase di replica continua (CDC).
Failback post-promozione Non supportata (promozione unidirezionale). Replica inversa integrata (fase FAILBACK) da Cloud SQL per SQL Server all'istanza SQL Server di origine dopo la promozione, con supporto per il failback senza perdita di dati.

Come funzionano le migrazioni dei DAG

Durante una migrazione DAG, Database Migration Service orchestra la replica dei dati tra il gruppo di disponibilità di origine e un gruppo di disponibilità secondario gestito nell'istanza Cloud SQL per SQL Server di destinazione.

Canali di comunicazione di rete

Database Migration Service utilizza due canali di comunicazione di rete privata tra l'istanza SQL Server di origine e l'istanza Cloud SQL per SQL Server di destinazione:

  1. Server collegato SQL Server (porta del database, predefinita 1433): Database Migration Service utilizza un server collegato configurato nell'istanza Cloud SQL per SQL Server di destinazione per eseguire query di amministrazione e orchestrazione nell'istanza SQL Server di origine.
  2. Endpoint di mirroring del database (DBM) (predefinito 5022): il gruppo di disponibilità di origine e il gruppo di disponibilità Cloud SQL per SQL Server di destinazione scambiano i dati di caricamento completi iniziali autenticati con certificato e le modifiche al database in corso direttamente sulla porta DBM.

Fasi del ciclo di vita della migrazione

Un job di migrazione dei DAG passa attraverso quattro fasi del ciclo di vita:

  1. Caricamento completo iniziale (FULL_DUMP): quando avvii il job di migrazione, Database Migration Service configura il gruppo di disponibilità distribuito per trasmettere in streaming la copia completa iniziale di tutti i database nel gruppo di disponibilità di origine sulla rete all'istanza Cloud SQL per SQL Server di destinazione.
  2. Replica continua (CDC): quando ogni database termina il caricamento completo iniziale, passa alla fase CDC. Le modifiche in corso apportate ai database di origine vengono replicate continuamente sull'endpoint DBM e puoi connetterti all'istanza Cloud SQL per SQL Server di destinazione per eseguire query di verifica di sola lettura sui database in fase di replica.
  3. Promozione e replica inversa (FAILBACK): quando promuovi il job di migrazione (promote senza il flag --failback), Database Migration Service sincronizza entrambi i gruppi di disponibilità, ne inverte i ruoli 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, quindi passa alla fase del job di migrazione FAILBACK (PHASE_FAILBACK nelle risposte di Google Cloud CLI e dell'API). Durante la fase FAILBACK, il job di migrazione rimane nello stato Running e replica le nuove scritture da Cloud SQL per SQL Server nell'istanza SQL Server di origine.
  4. Switchover, arresto o completamento del failback (Stop e Delete):
    • Se devi annullare il cutover durante la fase FAILBACK, puoi eseguire il comando promote con il flag --failback (failback = true nell'API) per eseguire un failback senza perdita di dati che ripristina l'istanza SQL Server di origine originale come principale, retrocede Cloud SQL per SQL Server a secondaria e riporta il job di migrazione alla fase CDC.
    • Puoi eseguire stop per interrompere la replica dei dati per un periodo di tempo definito e breve (gli aggiornamenti continuano ad accumularsi nei log delle transazioni mentre la replica è interrotta). Da uno stato Stopped, puoi eseguire resume per riprendere la replica dei dati o eseguire delete per completare la migrazione ed eseguire la pulizia necessaria.
    • Una volta confermato che il cutover a Cloud SQL per SQL Server è definitivo, elimina (delete) il job di migrazione (direttamente o dallo stato Stopped). L'eliminazione del job di migrazione completa la migrazione, elimina il gruppo di disponibilità distribuito e i certificati su entrambe le istanze e consente di abilitare le funzionalità di Cloud SQL per SQL Server bloccate durante la migrazione, come il recupero point-in-time (PITR) e le repliche di lettura.

Database di origine e destinazione supportati

Le migrazioni DAG supportano le seguenti versioni ed edizioni dei database di origine e di destinazione:

  • Database di origine: SQL Server Enterprise Edition con gestione indipendente (versioni 2017, 2019, 2022 e 2025) con la funzionalità Gruppi di disponibilità Always On abilitata (su Windows o Linux).
  • Database di destinazione: Cloud SQL per SQL Server Enterprise Edition (versioni 2017, 2019, 2022 e 2025).

Limitazioni note per le migrazioni dei DAG

Prima di configurare una migrazione del DAG, tieni presente le seguenti limitazioni:

  • La creazione di profili di connessione DAG e la creazione, la verifica, l'avvio, la promozione o l'eliminazione di job di migrazione DAG sono supportati solo tramite Google Cloud CLI o l'API Database Migration Service. Puoi monitorare l'avanzamento del job di migrazione del DAG, lo stato per database e le metriche nella console Google Cloud .
  • Sia l'istanza SQL Server di origine sia l'istanza Cloud SQL per SQL Server di destinazione devono eseguire Enterprise Edition. Le origini Amazon RDS e Cloud SQL per SQL Server non sono supportate per le migrazioni DAG.
  • Ogni job di migrazione DAG esegue la migrazione di tutti i database contenuti in un singolo gruppo di disponibilità di origine (fino al limite di 100 database per gruppo di disponibilità distribuito). I database di sistema (master, model, msdb, tempdb) e il database helper di Database Migration Service (gcp_dms_db) non vengono migrati.
  • Tutti i database nel gruppo di disponibilità di origine devono archiviare i propri file di dati (.mdf e .ndf) nella directory dei dati predefinita di SQL Server.
  • Requisiti di proprietà del database:
    • I database di origine non possono essere di proprietà dell'accesso sa. Prima di avviare il job di migrazione, cambia il proprietario del database da sa a un altro utente di accesso SQL o Windows.
    • Se un database di origine è di proprietà di un utente Windows Active Directory, devi cambiare il proprietario del database di origine in un accesso SQL prima della migrazione o integrare l'istanza Cloud SQL per SQL Server di destinazione con 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 i proprietari di database autenticati tramite SQL, Database Migration Service crea automaticamente un accesso corrispondente nell'istanza Cloud SQL per SQL Server di destinazione con prefisso gcp_dms_, un identificatore di 6 caratteri e il nome del proprietario di origine (ad esempio gcp_dms_a1b2c3_myowner) per diventare proprietario del database di cui è stata eseguita la migrazione.
  • La connettività IP pubblico non è supportata. Devi configurare la connettività con IP privato tra l'istanza SQL Server di origine e l'istanza Cloud SQL per SQL Server di destinazione utilizzando l'accesso privato ai servizi o Private Service Connect.
  • Limitazioni di Cloud SQL per SQL Server di destinazione durante l'esistenza del job di migrazione DAG: dal momento in cui avvii un job di migrazione DAG fino a quando elimini il job di migrazione (anche quando il job è nella fase FAILBACK post-promozione):
    • Il recupero point-in-time (PITR) deve essere disabilitato nell'istanza Cloud SQL per SQL Server di destinazione.
    • Le repliche di lettura e i pool di lettura non sono supportati nell'istanza Cloud SQL per SQL Server di destinazione.
    • La manutenzione pianificata con tempi di inattività prossimi allo zero non è supportata nell'istanza Cloud SQL per SQL Server di destinazione.
    • Non modificare manualmente il flag di database cloud sql enable dag support nell'istanza Cloud SQL per SQL Server di destinazione. Database Migration Service attiva questo flag automaticamente all'avvio del job di migrazione e puoi rimuoverlo dopo aver eliminato il job di migrazione.
  • Aggiunta o rimozione di database durante la migrazione:
    • Puoi aggiungere o rimuovere dinamicamente i database nel gruppo di disponibilità di origine mentre il job di migrazione è in fase CDC. Database Migration Service rileva automaticamente i database appena aggiunti, li convalida ed esegue il caricamento completo iniziale nell'istanza Cloud SQL per SQL Server di destinazione.
    • La rimozione di un database dal gruppo di disponibilità di origine interrompe la replica per quel database, lo rimuove dagli oggetti monitorati del job di migrazione e lo lascia nello stato RESTORING nell'istanza Cloud SQL per SQL Server di destinazione (non viene recuperato quando il job viene promosso).
    • L'aggiunta di nuovi database direttamente nell'istanza Cloud SQL per SQL Server di destinazione durante la fase post-promozione FAILBACK non è supportata (il gruppo di disponibilità di destinazione non viene aggiornato con i nuovi database creati su Cloud SQL).
  • Avvertenze per l'arresto, la ripresa e il riavvio dei job di migrazione dei DAG:
    • L'arresto (stop) di un job di migrazione DAG interrompe la replica dei dati, causando l'accumulo di aggiornamenti nei log delle transazioni mentre la replica è interrotta. Interrompi un job di migrazione DAG solo per un periodo di tempo definito e breve, in modo che i dischi dei log delle transazioni non si riempiano. Dallo stato Stopped, puoi eseguire resume per riprendere la replica dei dati o eseguire delete per completare la migrazione ed eseguire la pulizia necessaria.
    • Il riavvio (restart) di un job di migrazione DAG non riuscito o interrotto elimina i database di cui è stata eseguita la migrazione nell'istanza Cloud SQL per SQL Server di destinazione ed esegue nuovamente il caricamento completo iniziale (FULL_DUMP) sulla rete.

Passaggi successivi