Estos días han sido de esos en los que tocaba tarea de migración y, bueno, que mejor forma de hacerla que tener seguro el proceso (previa POC) y, además, compartirlo. En este post quiero comentar los pasos que he seguido para la migración. En concreto, se trata de migrar de «Azure Database for PostgreSQL Single Server» a «Azure Database for PostgreSQL Flexible Server», teniendo en cuenta algunas premisas iniciales o requisitos.
Antes de comenzar comento algunos puntos que considero importantes, como resumen de lo que será la migración:
✅ Migrar de PostgreSQL v10 a v14.
✅ Crear el nuevo servidor de destino (Flexible Server).
✅ El nuevo servidor destino tendrá un nuevo nombre, diferente a actual.
✅ Son necesarias configuraciones en ambos servidores e incluso algunos permisos al Resource Group.
✅ En la nueva cadena de conexión el «User Id» deja de necesitar el dominio (sufijo @myserver).
✅ Durante el proceso de migración tenemos que crear «tareas migración», cada una de ellas con un máximo de 8 bases de datos a migrar a la vez.
Servidor Origen (Single Server)
- Version: 10
- General Purpose, 4 vCore(s), 100 GB
Servidor Destino (Flexible Server)
Como no tenemos aun un Flexible Server, lo creamos teniendo en cuenta estos datos y pasos:
- Version 14
- Burstable, B1ms, 1 vCores, 2 GiB RAM, 32 GiB storage
- Nuevo servidor Flexible Server:
Donde:
- Se inicia el proceso de creación del nuevo Servidor Flexible
- Seleccionar el tamaño de la instancia.
- Introducir el nuevo nombre y crear las credenciales de acceso. Es importante que el nombre del usuario no coincida con niguno de los habituales (sa, admin, etc.). De ser así recibiremos un mensaje de error como el siguiente: Admin login name cannot be’ azure_superuser’, ‘azuresu’, ‘azure_pg_admin’, ‘sa’, ‘admin’, ‘administrator’, ‘root’, ‘guest’, ‘dbmanager’, ‘loginmanager’, ‘dbo’, ‘information_schema’, ‘sys’, ‘db_accessadmin’, ‘db_backupoperator’, ‘db_datareader’, ‘db_datawriter’, ‘db_ddladmin’, ‘db_denydatareader’, ‘db_denydatawriter’, ‘db_owner’, ‘db_securityadmin’, ‘public’.
- Establecer el método de conexión Publico o Privado. Para el ejemplo he elegido «public», pero, ¡ya sabemos que no es lo recomendado para entornos productivos!
- Finalmente pulsar «Create» y esperar la creación
Configuración
Antes de continuar con el proceso de migración es necesario realizar algunas configuraciones previas:
1. Registrar el proveedor de recursos (o Resource Provider) «Microsoft.DataMigration».
2. Establecer como «LOGICAL» el modo de replicación en el servidor origen (Single Server).
Nota: En este momento tras guardar los cambios el servidor, es necesario un reinicio.
3. Crear un nuevo AppRegistration en AAD con el nombre, por ejemplo: «PostgreSQLMigration»
Nota: Guarda este nuevo secret. Vas a necesitarlo más adelante y, posiblemente más de una vez.
4. Asignar permisos de Contributor al Servidor Postres de origen (Single Server) para el AppRegistration creado en el paso anterior.
5. Repetir el paso anterior para el Servidor de destino (Flexible server) y para el grupo de recursos (o Resource Group). «POCs» para este caso en particular. Como ambos servidores están en el mismo grupo de recursos, asignando los permisos a dicho grupo de recursos, sería suficiente.
6. En el servidor destino, selecconar todas las extensiones necesarias. Ej.: «CITEXT» (Case Insensitive text).
Proceso de Migración
En este punto ya estamos en disposición de comenzar con el proceso de migración. Existe varios mecanismos de migración, si bien, para este caso he optado por la opción de migración (aun en Preview), que nos ofrece el Portal:
1. Acceder al servicio Flexible Server y seleccionar «Migration (preview)».
2. Crear una nueva tarea de migración («Migrate from Single Server»)
Pestaña Setup:
3. Indicar un «Migration Name» que te permita referirte a la tarea en cuestión, puesto que en caso de error tendrás que crear una nueva migración y tendrás que dar un nuevo nombre.
4. Seleccionar el Resource Group.
5. Seleccionar el App-Registration creado previamente y marcar el check: «Yes, this app is registered as a contributor with source, target, and the migration resource group.«
6. Introducir el secret del App-Registration ¡Que hemos guardado en el momento de su creación!
Pestañas Source y Target:
1. Seleccionar el servidor origen
2. Introducir las credenciales para el servidor origen.
3. Seleccionar las bases de datos a migrar.
4. Seleccionar el modo de migración: Online / Offline.
5. Seleccionar el servidor destino .
6. Introducir las credenciales para el servidor destino.
7. Seleccionar NO «Authorize DB overwrite» lo que implica que tras la migración se requiere confirmación del usuario. En caso de seleccionar SI, la base de datos en el servidor destino se sobre-escribirá sin previa confirmación.
8. Finalmente pulsar «Review & Create» para iniciar así, el proceso de migración.
Una vez que termine el proceso, vemos un estado «WaitingForUserAction» y un sub-estado: «WaitingForCutOver, lo que indica que se requiere confirmación para finalizar el proceso.
Adicionalmente, podemos encontrarnos con un sub-estado: «WaitingForTargetDBOverwriteConfirmation«, el cual requiere confirmación para sobre-escribir los cambios en el destino. Esto ocurrirá si hemos tenido que repetir por algún motivo un proceso de migración.
Llegado este punto, podemos concluir diciendo que los datos han sido migrados con éxito.
Durante el proceso de migración hemos tenido que crear un nuevo servidor destino, por lo que nos veremos obligados a cambiar todas las cadenas de conexión de nuestros servicios/aplicaciones.
Es importante conocer también algunas limitaciones del proceso de migración. Por ejemplo, el número máximo de bases de datos por cada tarea de migración es de 8.
Y hasta aquí el ejemplo/PoC. Espero que sea de utilidad.
Un saludo y Feliz Navidad !
Juanlu, ElGuerre 