Una de las cosas que realizamos en STR con mucha frecuencia es la migración de sistemas, ya sea entre distintos proveedores o dentro de un mismo proveedor por cambio de versión, servicio o cualquier otra razón.

Recientemente se nos ha presentado un reto con el siguiente contexto:

1. Arquitectura en AWS en la que tenemos que migrar un SQL Server 2008 Standard Edition que se encuentra en una instancia EC2 y no tenemos alta disponibilidad.
2. Necesidad de migrar a RDS con SQL Server 2019.
3. La ocupación de los datos es de unos 400GB en total.
4. Ventana de trabajo total de 6 horas como máximo y minimizando la parada de servicio todo lo posible.

Con este escenario pensamos en hacer uso del servicio de DMS (Data Migration Service de AWS). Tiempo atrás (2 o 3 años) ya lo habíamos usado, o mejor dicho, intentado, porque no salió demasiado bien.

La idea, por tanto, es montar una replicación con DMS entre la instancia SQL Server 2008 Standard Edition y el RDS SQL Server 2019 haciendo así que el tiempo de parada sea cuestión de minutos, ya que los datos están replicados en tiempo real.

Primer contratiempo, SQL Server 2008 Standard Edition no es compatible con Ongoing replication (CDC):

Está opción queda descartada, ya que para nuestro caso concreto no es posible por las versiones con las que contamos en origen.

Dado que el plan A ya no es posible y tenemos que realizar una parada larga pero ajustada al límite de 6 horas, seguimos con el plan de hacer uso del DMS, pero ahora con un Full Load en vez de replicación.

1. DMS Ongoing replication (CDC) 
2. DMS Full Load

Empezamos con el plan B, algo desconfiados, pero aún así comenzamos con las pruebas.

Después de realizar las cargas de prueba se detecta que el comportamiento no está siendo el esperado y la estructura de los datos no es igual en el origen que en destino, algo que ya sabíamos pero que pensamos no iba a ser un problema.

Paramos y empezamos a leer detenidamente cada una de la lista de limitaciones. Vemos que la limitación que nos afecta de manera considerable es que las propiedades Identity no se migran.

Dado que es necesario y crítico, detenemos las pruebas y pensamos en opciones.

Después de varias pruebas teniendo en cuenta las limitaciones de DMS con la opción de Full Load en SQL Server y tras solventar muchas limitaciones, tenemos que descartar ésta finalmente, ya que el tiempo que tenemos que invertir tanto nosotros como el cliente, no es viable.

Por tanto descartados el plan A y el plan B.

Tenemos que buscar nuevas opciones para conseguir el objetivo y optamos por la que quizás era más evidente y de primeras descartamos, hacer uso de los backup nativos de SQL Server.

1. DMS Ongoing replication (CDC)
2. DMS Full Load
3. Carga de backup nativos de SQL Server (ficheros .bak)

Comenzamos con el plan C.

Lo primero que hacemos es revisar detenidamente todas las limitaciones y recomendaciones que nos podemos encontrar y así evitamos sorpresas.

Después de revisarlo vemos que en nuestro caso es viable y lo que tenemos que tener en cuenta es:

• Los .bak tienen que estar en S3 y no pueden superar 1TB cada .bak
• Nuestro RDS tiene que tener unas configuraciones específicas para activar la creación y recuperación de backups nativos
• Para realizar la carga de los .bak no tiene que existir la base de datos en la instancia RDS
• Los .bak almacenados en S3 pueden tener cifrado de tipo cliente o estar sin cifrar para poder hacer la carga

Como ya disponemos del RDS lo primero que hacemos es crear el option group y el role que nos va a permitir acceder al procedimiento almacenado de backup and restore. Tenemos información oficial para los parámetros a tener en cuenta en la documentación de AWS.

Teniendo esto listo, sólo nos falta hacer la llamada al proceso almacenado que AWS nos facilita para realizar la carga de las bases de datos desde ficheros de backup: sdb.dbo.rds_restore_database.

Este proceso almacenado podemos llamarlo tantas veces como necesitemos teniendo en cuenta que sólo se puede tener un proceso de backup/restore por base de datos. Da igual que esté en ejecución como en espera.

Además, podemos ver el estado de los restores con otro procedimiento almacenado facilitado por AWS: msdb.dbo.rds_task_status.

Una vez finalizadas las pruebas y realizadas las comprobaciones vemos viable esta opción para plantear una migración segura y dentro de los requisitos y plazos acordados.

Como parte del aprendizaje que hemos sacado en este proceso destacamos:

• A veces la opción más sencilla y común puede ser la mejor por muy buena que parezca la opción más innovadora y “chula”.
• Cuando las cosas se complican y se retuercen demasiado suele no ser el camino correcto, es tiempo de parar y pensar en otras alternativas.
• Es muy importante leer la documentación y ver las limitaciones de las herramientas o servicios que vamos a utilizar con detalle (todos nos hemos saltado esta regla no escrita alguna vez xD)