El fin de soporte de SQL Server 2019 está a la vuelta de la esquina, eso ya lo sabemos. También hemos hablado en esta casa de cómo planificar una migración y, cuando lo hicimos, comentamos la posibilidad de valorar métodos para una migración Online, sin tiempo de inactividad o con el mínimo posible. Y, eso es justo de lo que os quiero contar hoy, esos métodos de migración casi transparentes para el usuario por su nula o baja inactividad.
Preparar una migración
Antes de entrar en las opciones de migración online, es fundamental preparar adecuadamente el entorno. La planificación es clave. Sin entrar mucho en detalle, que ya le dedicamos un artículo entero a este tema, debemos asegurarnos de que todas las aplicaciones que interactúan con la base de datos sean compatibles con SQL Server 2022. Una buena práctica es clonar el entorno de producción en un entorno de pruebas donde podamos simular la migración. Este paso extra nos permitirá identificar posibles inconvenientes y corregirlos antes de afectar el entorno productivo.
También es crucial realizar una evaluación de los requisitos de hardware y software, ya que SQL Server 2022 puede requerir actualizaciones en los sistemas operativos o en el hardware para aprovechar todas sus nuevas características. Una vez que hemos cubierto estos aspectos, estamos listos para explorar las opciones de migración online que nos ayudarán a reducir el tiempo de inactividad.
Migraciones Online (sin inactividad)
Una migración en caliente, también conocida como migración online, es el proceso en el que la base de datos se migra a un nuevo servidor o versión sin interrumpir el servicio o con una interrupción mínima. En lugar de detener las operaciones para realizar la migración, la base de datos permanece activa, y los usuarios pueden seguir accediendo a los datos mientras se lleva a cabo el proceso. Esto es especialmente crítico en entornos donde la disponibilidad continua es esencial, como en sistemas de comercio electrónico, fábricas que no pueden parar la producción o cualquier otro sistema que opere en tiempo real.
Un concepto clave asociado a las migraciones en caliente es el RTO, o «Recovery Time Objective» (Objetivo de Tiempo de Recuperación). El RTO se refiere al tiempo máximo tolerable durante el cual un sistema, aplicación o proceso puede estar inactivo antes de que se produzca un impacto significativo en la organización. En el contexto de una migración, el RTO define cuánto tiempo podemos permitir que la base de datos esté inaccesible durante el cambio, y es un factor crucial para determinar la estrategia de migración.
Cuando hablamos de minimizar el tiempo de inactividad, estamos trabajando directamente para cumplir con el RTO definido. Un RTO corto, como por ejemplo de unos pocos minutos, implica que necesitamos utilizar métodos avanzados de migración en caliente, como Always On, Database Mirroring o Log Shipping, que permiten que el tiempo de transición sea prácticamente imperceptible para los usuarios. De esta manera, podemos asegurar que la migración no solo sea efectiva, sino que también cumpla con las expectativas y requisitos de disponibilidad de la organización.
Migración con Always On: Alto coste, cero inactividad
Always On Availability Groups es, sin duda, una de las tecnologías más potentes y flexibles para lograr una migración con tiempo de inactividad cero o cercano a cero. La idea detrás de Always On es crear un grupo de disponibilidad que replique las bases de datos seleccionadas en uno o más nodos secundarios. Esto no solo ofrece alta disponibilidad y recuperación ante desastres, sino que también facilita las migraciones.
Always On existente
En el mejor de los casos, ya dispondremos de un Always On con dos o más servidores SQL Server 2019. En este caso, para aprovechar Always On en la migración a SQL Server 2022, lo primero que haremos será agregar un nuevo nodo (o varios) con SQL Server 2022 a nuestro grupo de disponibilidad actual. Es importante que el nodo con SQL Server 2022 tenga configurada una replicación síncrona para garantizar que no tendremos pérdida de datos.
Una vez que el nodo 2022 esté sincronizado y funcionando correctamente, podemos proceder a realizar un failover manual al nuevo nodo. Durante este proceso, la mayoría de las conexiones se mantendrán activas y la interrupción será mínima (de pocos milisegundos).
Con el servicio balanceado al nodo SQL Server 2022, los nodos con SQL Server 2019 perderán la conexión, ya que no podrán alojar bases de datos de un servidor con una versión superior, por lo que tendremos que sacarlos del grupo de disponibilidad y actualizarlos a SQL 2022 o desmontarlos. En este punto, es el momento de añadir el resto de nodos con SQL Server 2022, si aún no lo habíamos hecho, para mantener la alta disponibilidad.
Si nuestro anterior Always On disponía de uno o varios Listener no tendremos que hacer nada más y no habrá ninguna pérdida de servicio. En caso contrario, las aplicaciones y usuarios deberán apuntar al nuevo servidor, con el tiempo de inactividad que conlleve el cambio por su lado.
Sin Always On anteriores
Si no disponemos de un grupo de alta disponibilidad Always On anterior la cosa se complica. Primero tenemos que asegurarnos de cumplir los requisitos para montar el Always On como disponer de una licencia SQL Server Enterprise o una sola base de datos (es la limitación de los Always On básicos con licencia estándar). Si cumplimos con estos requisitos, estamos listos para el siguiente paso, la configuración del Always On. Es importante destacar que este paso necesita de la instalación y configuración del servicio de clúster de Windows (WSFC) lo que nos puede requerir de uno o varios reinicios, con las consecuentes pérdidas de inactividad del servicio de base de datos.
Con el Always On ya configurado los pasos son los descritos en el apartado anterior: asegurarnos de que la replicación es correcta, balancear el servicio, modificar las conexiones de las aplicaciones para que apunten al nuevo servidor y desmontar el AG y apagar el servidor SQL Server 2019.
Migración con DB Mirroring: menor coste, baja inactividad
Database Mirroring es una antigua solución de alta disponibilidad anterior a la implementación de Always On pero que, hasta el día de hoy, se mantiene por compatibilidad. Además, no requiere de WSFC ni de licencia enterprise para funcionar lo que lo hace una solución ideal para nuestra migración con baja inactividad.
Estos son los pasos a seguir para una migración de baja inactividad con DB Mirroring:
En el servidor SQL Server 2019:
- Hacer una copia completa de la base de datos.
- Hacer una copia de log de la base de datos.
En el servidor SQL Server 2022:
- Restaurar con No Recovery la copia completa de la base de datos
- Restaurar con No Recovery la copia de log de la base de datos.
Configurar el DB Mirroring:
- En el SQL Server 2019:
ALTER DATABASE TuBaseDeDatos SET PARTNER = 'TCP://SQL2022ServerName:5022';- En el SQL Server 2012:
ALTER DATABASE TuBaseDeDatos SET PARTNER = 'TCP://SQL2019ServerName:5022';- Verifica que la configuración es correcta y que se está replicando en tiempo real. Puedes usar este script:
SELECT
db_name(database_id) AS DatabaseName,
mirroring_state_desc,
mirroring_role_desc,
mirroring_partner_name,
mirroring_partner_instance
FROM
sys.database_mirroring; Migración:
- Detén las conexiones de los usuarios y balancea el DB Mirroring para convertir el servidor SQL Server 2022 en principal. Ejecuta este comando en el SQL Server 2022:
ALTER DATABASE TuBaseDeDatos SET PARTNER FAILOVER;- Modifica las conexiones de tus aplicaciones y usuarios para que apunten al servidor SQL Server 2022 y restablece la conexión
- Elimina el DB Mirroring
-- En el Principal (ahora SQL Server 2022)
ALTER DATABASE TuBaseDeDatos SET PARTNER OFF;
-- En el secundario (SQL Server 2019)
ALTER DATABASE TuBaseDeDatos SET PARTNER OFF;
Como puedes ver, gracias a este método de migración la pérdida de servicio ha sido mínima, sin embargo, sí que llega a existir. Además cuantas más bases de datos tengas más se va a alargar el proceso que se tiene que repetir manualmente por cada una de ellas.
Migración con Log Shipping: bajo coste, inactividad moderada
El Log Shipping es otra alternativa para realizar la migración de SQL Server 2019 a 2022, especialmente en entornos donde el presupuesto es limitado o donde necesitemos una solución más sencilla. Aunque el Log Shipping no nos ofrezca las mismas ventajas que Always On o Database Mirroring en términos de disponibilidad continua, sigue siendo una herramienta efectiva para minimizar el tiempo de inactividad.
Para el proceso de migración con Log Shipping, configuraremos la copia y restauración periódica de los archivos de registro de transacciones desde el servidor principal con SQL Server 2019 a un servidor secundario con SQL Server 2022. A diferencia de los otros métodos, el Log Shipping requiere un breve tiempo de inactividad al momento de realizar el balanceo final al nuevo servidor.
Para llevar a cabo este balanceo, debemos asegurarnos de que todos los logs pendientes se hayan restaurado en el servidor con SQL Server 2022. Una vez hecho esto, deshabilitaremos el servidor principal y configuraremos el nuevo servidor como el principal. Aunque este método requiere un breve tiempo de inactividad, sigue siendo una opción viable para entornos donde la alta disponibilidad no es crítica o donde la simplicidad y el bajo coste son prioritarios.
Conclusión
Migrar de SQL Server 2019 a 2022 sin inactividad es un proceso que puede parecer difícil, pero con las herramientas y estrategias adecuadas, podemos minimizar significativamente el tiempo de inactividad necesario. Always On, Database Mirroring y Log Shipping ofrecen soluciones adaptadas a diferentes necesidades y presupuestos. Always On es la opción más completa para entornos que no pueden permitirse ningún tipo de interrupción. Database Mirroring ofrece una buena combinación de seguridad y simplicidad, mientras que Log Shipping es ideal para aquellos que buscáis una solución económica y efectiva.
Cada uno de estos métodos tiene sus particularidades y ventajas, y la elección entre ellos dependerá de las características y requisitos específicos de nuestro entorno. Lo que es innegable es que, con la planificación adecuada y el uso de estas tecnologías, podemos llevar a cabo una migración exitosa a SQL Server 2022, garantizando así la continuidad de nuestras operaciones y aprovechando las ventajas de la nueva versión con el mínimo impacto en nuestros usuarios.
Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!
