Acerca de las migraciones de grupos de disponibilidad distribuidos (DAG)

Además del flujo de migración estándar de copia de seguridad y restablecimiento de Cloud Storage, Database Migration Service admite la migración de bases de datos de SQL Server autoadministradas a Cloud SQL para SQL Server con grupos de disponibilidad distribuida (DAG) de SQL Server.

En lugar de exportar y subir archivos de copia de seguridad y de registro de transacciones a un bucket de Cloud Storage, Database Migration Service configura un grupo de disponibilidad distribuido entre tu grupo de disponibilidad de origen y un grupo de disponibilidad secundario administrado en tu instancia de destino de Cloud SQL para SQL Server. Esta configuración transmite la carga completa inicial y los cambios continuos de la base de datos directamente a través de una conexión de red privada.

En esta página, se abordan los siguientes temas:

Cuándo usar las migraciones de DAG

En la siguiente tabla, se comparan las migraciones de copia de seguridad y restablecimiento estándar con las migraciones de grupos de disponibilidad distribuida (DAG) para ayudarte a elegir el mejor enfoque para tu carga de trabajo:

Atributo o requisito Migraciones de copia de seguridad y restablecimiento estándar (guía de migración estándar) Migraciones de grupos de disponibilidad distribuidos (DAG) (guía de migración de DAG)
Fuentes compatibles SQL Server autoadministrado, Amazon RDS y Cloud SQL para SQL Server. SQL Server autoadministrado (Enterprise Edition) con grupos de disponibilidad Always On
Mecanismo de transferencia de datos Archivos de copia de seguridad completa (.bak), copia de seguridad diferencial opcional (.diff) y registro de transacciones (.trn) almacenados en etapa de pruebas en Cloud Storage. Transmisión directa de red a través de un extremo de duplicación de base de datos de SQL Server (DBM) (no se requieren archivos de copia de seguridad ni buckets de Cloud Storage).
Conectividad de red No se requiere conectividad entre el origen y el destino. Se requiere conectividad de IP privada bidireccional en el puerto de la base de datos de SQL Server (1433 predeterminado) y el puerto de duplicación de la base de datos (5022 predeterminado).
Acceso a la base de datos de destino durante la migración Las bases de datos permanecen en modo RESTORING (inaccesibles para las consultas) hasta que se ascienden. Se puede acceder a las bases de datos en modo de solo lectura durante la fase de replicación continua (CDC).
Regreso a la instancia principal después de la promoción No se admite (promoción unidireccional). Replicación inversa integrada (fase FAILBACK) de Cloud SQL para SQL Server a la instancia de SQL Server de origen después de la promoción, con compatibilidad para el cambio de conmutación por recuperación sin pérdida de datos.

Cómo funcionan las migraciones de DAG

Durante una migración de DAG, Database Migration Service organiza la replicación de datos entre tu grupo de disponibilidad de origen y un grupo de disponibilidad secundario administrado en tu instancia de Cloud SQL para SQL Server de destino.

Canales de comunicación de red

Database Migration Service usa dos canales de comunicación de red privada entre tu instancia de SQL Server de origen y la instancia de Cloud SQL para SQL Server de destino:

  1. Servidor vinculado de SQL Server (puerto de la base de datos, predeterminado 1433): Database Migration Service usa un servidor vinculado configurado en la instancia de destino de Cloud SQL para SQL Server para ejecutar consultas administrativas y de organización en la instancia de SQL Server de origen.
  2. Extremo de duplicación de bases de datos (DBM) (predeterminado 5022): El grupo de disponibilidad de origen y el grupo de disponibilidad de Cloud SQL para SQL Server de destino intercambian datos de carga completa iniciales autenticados con certificados y cambios continuos en la base de datos directamente a través del puerto DBM.

Fases del ciclo de vida de la migración

Un trabajo de migración de DAG avanza por cuatro fases del ciclo de vida:

  1. Carga completa inicial (FULL_DUMP): Cuando inicias el trabajo de migración, Database Migration Service configura el grupo de disponibilidad distribuido para transmitir la copia completa inicial de todas las bases de datos del grupo de disponibilidad de origen a través de la red a la instancia de destino de Cloud SQL para SQL Server.
  2. Replicación continua (CDC): A medida que cada base de datos finaliza su carga completa inicial, pasa a la fase CDC. Los cambios en curso que se realizan en las bases de datos de origen se replican de forma continua en el extremo de DBM, y puedes conectarte a la instancia de destino de Cloud SQL para SQL Server para ejecutar consultas de verificación de solo lectura en las bases de datos que se replican.
  3. Ascenso y replicación inversa (FAILBACK): Cuando asciendes el trabajo de migración (promote sin la marca --failback), Database Migration Service sincroniza ambos grupos de disponibilidad, cambia sus roles para que la instancia de Cloud SQL para SQL Server de destino se convierta en la principal de lectura y escritura, y tu instancia de SQL Server de origen original se convierta en la secundaria, y cambia la fase del trabajo de migración a FAILBACK (PHASE_FAILBACK en las respuestas de la API de Google Cloud CLI y la API). Mientras se encuentra en la fase FAILBACK, el trabajo de migración permanece en el estado Running y replica las escrituras nuevas de Cloud SQL para SQL Server en tu instancia de SQL Server de origen.
  4. Cambio, detención o finalización de la conmutación por recuperación (Stop y Delete):
    • Si necesitas revertir la migración de sistemas durante la fase FAILBACK, puedes ejecutar el comando promote con la marca --failback (failback = true en la API) para realizar un cambio de conmutación por error sin pérdida de datos que restablezca tu instancia de SQL Server de origen original como la principal, descender de nivel Cloud SQL para SQL Server a la secundaria y devolver el trabajo de migración a la fase CDC.
    • Puedes ejecutar stop para detener la replicación de datos durante un período breve definido (las actualizaciones se siguen acumulando en los registros de transacciones mientras se detiene la replicación). Desde un estado Stopped, puedes ejecutar resume para reanudar la replicación de datos o ejecutar delete para completar la migración y realizar la limpieza necesaria.
    • Una vez que confirmes que la migración de sistemas a Cloud SQL para SQL Server es permanente, borra (delete) el trabajo de migración (ya sea directamente o desde el estado Stopped). Cuando borras el trabajo de migración, se completa la migración, se borran el grupo de disponibilidad distribuido y los certificados en ambas instancias, y se te permite habilitar las funciones de Cloud SQL para SQL Server que están bloqueadas durante la migración, como la recuperación de un momento determinado (PITR) y las réplicas de lectura.

Bases de datos de origen y destino compatibles

Las migraciones de DAG admiten las siguientes ediciones y versiones de bases de datos de origen y destino:

  • Bases de datos de origen: SQL Server Enterprise Edition autoadministrado (versiones 2017, 2019, 2022 y 2025) con la función Grupos de disponibilidad Always On habilitada (en Windows o Linux).
  • Bases de datos de destino: Cloud SQL para SQL Server Enterprise Edition (versiones 2017, 2019, 2022 y 2025).

Limitaciones conocidas para las migraciones de DAG

Ten en cuenta las siguientes limitaciones antes de configurar una migración de DAG:

  • La creación de perfiles de conexión de DAG y la creación, verificación, inicio, ascenso o eliminación de trabajos de migración de DAG solo se admiten a través de Google Cloud CLI o la API de Database Migration Service. Puedes supervisar el progreso del trabajo de migración de DAG, el estado por base de datos y las métricas en la consola de Google Cloud .
  • Tanto la instancia de SQL Server de origen como la instancia de Cloud SQL para SQL Server de destino deben ejecutar la edición Enterprise. Las fuentes de Amazon RDS y Cloud SQL para SQL Server no son compatibles con las migraciones de DAG.
  • Cada trabajo de migración de DAG migra todas las bases de datos contenidas en un solo grupo de disponibilidad de origen (hasta el límite de 100 bases de datos por grupo de disponibilidad distribuido). Las bases de datos del sistema (master, model, msdb, tempdb) y la base de datos auxiliar de Database Migration Service (gcp_dms_db) no se migran.
  • Todas las bases de datos del grupo de disponibilidad de origen deben almacenar sus archivos de datos (.mdf y .ndf) en el directorio de datos predeterminado de SQL Server.
  • Requisitos de propiedad de la base de datos:
    • El acceso sa no puede ser propietario de las bases de datos de origen. Antes de iniciar el trabajo de migración, cambia el propietario de la base de datos de sa a otro acceso de SQL o usuario de Windows.
    • Si una base de datos de origen es propiedad de un usuario de Active Directory de Windows, debes cambiar el propietario de la base de datos de origen a un acceso de SQL antes de migrar o integrar tu instancia de Cloud SQL para SQL Server de destino con Active Directory para que Database Migration Service pueda crear automáticamente el acceso de Windows correspondiente en la instancia de destino cuando se inicie el trabajo de migración.
    • Para los propietarios de bases de datos autenticadas con SQL, Database Migration Service crea automáticamente un acceso correspondiente en la instancia de destino de Cloud SQL para SQL Server con el prefijo gcp_dms_, un identificador de 6 caracteres y el nombre del propietario de origen (por ejemplo, gcp_dms_a1b2c3_myowner) para que sea el propietario de la base de datos migrada.
  • No se admite la conectividad de IP pública. Debes configurar la conectividad de IP privada entre la instancia de SQL Server de origen y la instancia de destino de Cloud SQL para SQL Server con el acceso privado a servicios o Private Service Connect.
  • Restricciones de Cloud SQL para SQL Server de destino mientras existe el trabajo de migración de DAG: Desde el momento en que inicias un trabajo de migración de DAG hasta que lo borras (incluso mientras el trabajo está en la fase FAILBACK posterior a la promoción):
    • La recuperación de un momento determinado (PITR) debe estar inhabilitada en la instancia de destino de Cloud SQL para SQL Server.
    • Las réplicas de lectura y los grupos de lectura no son compatibles con la instancia de destino de Cloud SQL para SQL Server.
    • El mantenimiento planificado con tiempo de inactividad cercano a cero no es compatible con la instancia de destino de Cloud SQL para SQL Server.
    • No modifiques de forma manual la marca de base de datos cloud sql enable dag support en la instancia de Cloud SQL para SQL Server de destino. Database Migration Service habilita esta marca automáticamente cuando se inicia el trabajo de migración, y puedes quitarla después de borrar el trabajo de migración.
  • Agrega o quita bases de datos durante la migración:
    • Puedes agregar o quitar bases de datos de forma dinámica en tu grupo de disponibilidad de origen mientras el trabajo de migración se encuentra en la fase CDC. Database Migration Service detecta automáticamente las bases de datos recién agregadas, las valida y realiza su carga completa inicial en la instancia de destino de Cloud SQL para SQL Server.
    • Si quitas una base de datos del grupo de disponibilidad de origen, se detiene la replicación de esa base de datos, se quita de los objetos con seguimiento del trabajo de migración y se deja la base de datos en estado RESTORING en la instancia de destino de Cloud SQL para SQL Server (no se recupera cuando se promociona el trabajo).
    • No se admite agregar bases de datos nuevas directamente en la instancia de destino de Cloud SQL para SQL Server durante la fase de FAILBACK posterior a la promoción (el grupo de disponibilidad de destino no se actualiza con las bases de datos nuevas creadas en Cloud SQL).
  • Advertencias para detener, reanudar y reiniciar trabajos de migración de DAG:
    • Detener (stop) un trabajo de migración de DAG detiene la replicación de datos, lo que hace que las actualizaciones se acumulen en los registros de transacciones mientras se detiene la replicación. Solo detén un trabajo de migración de DAG durante un período breve y definido para que los discos de registro de transacciones no se llenen. Desde el estado Stopped, puedes ejecutar resume para reanudar la replicación de datos o ejecutar delete para completar la migración y realizar la limpieza necesaria.
    • Si reinicias (restart) un trabajo de migración de DAG con errores o detenido, se borrarán las bases de datos migradas en la instancia de destino de Cloud SQL para SQL Server y se volverá a ejecutar la carga completa inicial (FULL_DUMP) en la red.

¿Qué sigue?