Claves para planificar el paso de SQL Server 2017 a 2022 con Distributed Availability Groups
Cuando una empresa necesita trasladar sus bases de datos a otra región de Microsoft Azure y, al mismo tiempo, actualizar SQL Server, la migración debe abordar dos retos: mantener los datos actualizados durante el traslado y controlar la interrupción del servicio en el momento del cambio.
Para entornos que utilizan SQL Server en máquinas virtuales de Azure con Always On Availability Groups, los Distributed Availability Groups (DAG) permiten conectar grupos de disponibilidad independientes, incluso cuando sus servidores están en regiones diferentes.
A continuación, explicamos el proceso mediante un escenario que evoluciona de SQL Server 2017 Enterprise a SQL Server 2022 Enterprise.
¿Qué es un Distributed Availability Group?
Un grupo de disponibilidad distribuido conecta dos grupos Always On tradicionales. Cada uno tiene sus propias réplicas, su propio clúster de Windows Server (WSFC) y su propio listener.
El DAG enlaza ambos grupos para transmitir los cambios de las bases de datos entre ellos.
Durante la preparación, el grupo de origen conserva la capacidad de lectura y escritura. El servidor principal del grupo de destino actúa como forwarder: recibe los registros de transacciones y los distribuye a sus réplicas locales.
El DAG no crea un listener adicional; las aplicaciones utilizan el listener del grupo que esté prestando servicio.
Escenario de West Europe a France Central
Imaginemos una empresa de comercio electrónico, denominada Comercio Demo, que quiere renovar su plataforma y trasladar la base de datos ficticia PedidosDemo a otra región de Azure.
| Componente | Origen | Destino |
| Región | West Europe | France Central |
| Motor | SQL Server 2017 Enterprise | SQL Server 2022 Enterprise |
| Servidores | WE-SQL17-01 y WE-SQL17-02 | FC-SQL22-01 y FC-SQL22-02 |
| Clúster | WSFC_WE | WSFC_FC |
| Availability Group | AG_WE_2017 | AG_FC_2022 |
Ambos grupos se vinculan mediante DAG_WE_FC. El entorno de destino se construye de forma independiente para que puedan realizarse pruebas y comprobaciones antes de cualquier cambio en las conexiones de producción.
Preparación del entorno de destino
Antes de iniciar la sincronización, se despliega la nueva infraestructura en France Central y se comprueba que puede funcionar con autonomía.
Entre las tareas principales se incluyen:
- Infraestructura y alta disponibilidad: crear las máquinas virtuales, preparar almacenamiento y redes, configurar el WSFC, el quórum y el grupo Always On de SQL Server 2022.
- Conectividad: validar la comunicación privada entre las regiones, la resolución DNS, los listeners, los endpoints HADR y las reglas de seguridad necesarias. En Azure VM también debe revisarse el tipo de listener, ya que un DAG no admite un grupo subyacente con listener basado en DNN.
- Seguridad y configuración: revisar cuentas de servicio, permisos, certificados y claves. Si se utiliza TDE, preparar correctamente el material criptográfico requerido antes de restaurar.
- Objetos de instancia: planificar la migración de inicios de sesión y SID, trabajos de SQL Server Agent, linked servers, credenciales, Database Mail y otras dependencias que no se trasladan con el DAG.
- Compatibilidad: verificar que la aplicación y las consultas funcionan sobre SQL Server 2022 y revisar expresamente el nivel de compatibilidad de las bases de datos.
De SQL Server 2017 a 2022: la inicialización debe ser manual
Este es uno de los puntos más importantes del procedimiento.
Cuando el grupo de destino utiliza una versión principal de SQL Server superior a la del origen, Microsoft no admite la inicialización automática (AUTOMATIC) entre ambos grupos del DAG.
En este caso se debe configurar:
SEEDING_MODE = MANUALLa secuencia consiste en realizar una copia de seguridad completa y copias del log de transacciones en el origen, restaurarlas en el destino utilizando WITH NORECOVERY, y unir las bases de datos al grupo distribuido y a las réplicas del grupo local siguiendo la secuencia documentada.
Una vez establecido el DAG, los cambios posteriores siguen llegando de forma continua mediante el transporte de registros, sin necesidad de repetir todas las copias de seguridad.
También existe una limitación temporal relevante: mientras el origen siga en SQL Server 2017, las bases de datos del grupo de destino SQL Server 2022 no estarán disponibles para consultas de lectura.
Durante esta etapa pueden aparecer estados como Partially Healthy o Synchronizing/In Recovery por la diferencia de versiones. Es necesario interpretar esos estados junto con los indicadores de avance y sincronización, sin confundirlos automáticamente con una avería.
Cómo preparar y ejecutar el corte de servicio
El objetivo no es prometer una migración sin interrupciones, sino reducir la ventana de parada y controlar el riesgo de pérdida de datos.
Para ello se planifica un ensayo previo, se vigila el retraso de replicación y se define una decisión de continuar o cancelar (go/no-go).
Durante la ventana de cambio, las acciones principales son detener o controlar las escrituras de la aplicación, ajustar la sincronización entre grupos según el procedimiento de Microsoft, verificar que el origen y el forwarder han confirmado el mismo last_hardened_lsn para cada base de datos y, finalmente, ejecutar el failover manual del DAG y redirigir las aplicaciones al listener de France Central.
En un DAG, el cambio de grupo se realiza con un comando de failover forzado. Aunque su nombre incluya ALLOW_DATA_LOSS, la finalidad de las comprobaciones previas es evitar la pérdida de transacciones.
No debe ejecutarse como un failover automático ni sin comprobar la sincronización. El procedimiento exacto debe ajustarse a la combinación de versiones y validarse en un ensayo.
La limitación más importante: el retorno de SQL Server 2022 a 2017
Al realizar el corte, las bases de datos pasan a ejecutarse en SQL Server 2022 y se actualizan internamente a la nueva versión.
Desde ese momento no es posible volver directamente al grupo de SQL Server 2017 mediante el DAG.
Los cambios realizados en SQL Server 2022 tampoco se replican hacia el grupo antiguo.
Por tanto, el plan de contingencia debe distinguir entre cancelar la operación antes del corte, cuando el origen aún presta servicio, y recuperarse de un problema después del corte, cuando la aplicación ya ha comenzado a escribir en SQL Server 2022.
Son escenarios distintos y requieren procedimientos distintos. Si se desea conservar un DAG operativo con posibilidad de retorno posterior, el entorno anterior también tendría que actualizarse a una versión compatible.
Validaciones después de la migración
Una vez realizado el cambio, la revisión debe ir más allá de comprobar que las bases de datos están en línea:
- Validar conexiones de las aplicaciones al listener del nuevo Availability Group y realizar operaciones funcionales de lectura y escritura.
- Comprobar el estado de las réplicas locales, el listener y el failover dentro del WSFC de destino.
- Revisar trabajos, backups, monitorización, rendimiento, permisos y dependencias externas.
- Confirmar el comportamiento de las consultas en SQL Server 2022 antes de modificar el nivel de compatibilidad de la base de datos.
- Documentar el resultado del corte, los puntos de control y la estrategia de desmantelamiento del entorno antiguo.
Conclusión: migrar con continuidad y un corte controlado
Los Distributed Availability Groups constituyen una alternativa especialmente interesante cuando es necesario migrar un entorno SQL Server Always On entre regiones de Azure y aprovechar el movimiento para actualizar la versión del motor.
Permiten construir el nuevo clúster en paralelo, transferir cambios durante la preparación y realizar un cambio de servicio planificado.
La clave está en conocer las diferencias entre versiones: inicialización manual de SQL Server 2017 a 2022, comprobaciones rigurosas antes del failover y un plan de contingencia que tenga en cuenta que no existe un retorno directo a SQL Server 2017 después de empezar a trabajar en 2022.
En GPSOS ayudamos a diseñar, migrar y mantener sus plataformas SQL Server de alta disponibilidad, tanto en infraestructuras tradicionales como en entornos cloud. Consulta nuestros servicios de Consultoría SQL Server.
Contacta con GPSOS si estás planificando una renovación de arquitectura Always On.
Referencias técnicas
- Microsoft Learn: Distributed Availability Groups
- Microsoft Learn: Configuración de un DAG
- Microsoft Learn: Completar una migración mediante DAG
¿Aún no conoces Query Performance? Descubre cómo puede ayudarte en tu entorno Oracle y/o SQL Server. Más información en su página de LinkedIn.
Sígue a GPS en LinkedIn