Cómo migrar PostgreSQL local a Azure – Parte2
Bienvenidos/as a un nuevo post en el blog de Aleson ITC. En la primera parte de esta serie de blogs, vimos como crear nuestro servicio de Azure Database for PostgreSQL flexible server.
En este blog, vamos a ver los requisitos previos y configuraciones a aplicar antes de poder realizar la migración.
Tipos de migración
Offline migration
En este tipo de migración se detienen todas las aplicaciones que se conectan a la instancia de origen y las bases de datos se copias a un servidor flexible.
Online migration
En este tipo de migración, las aplicaciones no se detienen mientras las BBDD se copia a un servidor flexible, la copia inicial va seguida de una replicación para mantener el servidor flexible sincronizado con la instancia de origen.
A continuación, dejo una tabla de pros y contras de la migración online y offline:
Primero vamos a empezar con la migración online, repasamos los pasos a revisar.
Verificar la versión de PostgreSQL origen
La versión del servidor de PostgreSQL de origen tiene que ser 9.5 o superior, en caso de tener una versión inferior, primero migrar a 9.5 o superior en local antes de iniciar la migración.
Instalar test_decoding (Servidor Origen)
Test_decoding, es un plugin que guarda los cambios que se han hecho en la BBDD y los transforma en un formato especifico/legible. Este plugin esta pensado principalmente para capturar y examinar los cambios que la BBDD.
Configurar servidor de Azure destino
Tener creada nuestro servicio de Azure Database for PostgreSQL flexible server.
La SKU (Stock Keeping Unit) para el servicio debe coincidir con la que tenemos en local, esto es básicamente el tipo de servidor en cuanto hardware. Azure proporciona tres niveles de precios:
- Burstable: Cargas de trabajo que no necesitan toda la CPU de forma continua para funcionar.
- General Purpose: Cargas de trabajo que requieren de un tamaño de memoria equilibrada con un rendimiento de I/O escalable, ejemplo, servidores aplicaciones web y app móvil.
- Memory Optimized: Cargas de trabajo de BBDD de alto rendimiento que requieren rendimiento en memoria para poder procesar transacciones de una manera mas rápida. Ejemplo, servidores de procesamiento de datos en tiempo real y analítica de datos.
https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-compute
A continuación dejo una tabla de los diferentes SKU disponibles:
Habilitar CDC
Instalar la extensión test_decoding.
En el servidor de postgres origen, establecer los siguientes parámetros en el archivo postgresql.conf
wal_level = logical
Este valor nos permite utilizar funciones de replicación lógica, como la decodificación lógica, que permite replicar cambios a nivel de fila.
Solo como información, wal_level también tiene más valores.
minimal: Graba la cantidad mínima de información necesaria para la recuperación ante fallos. Este nivel no es adecuado para la replicación.
replica: Graba la información suficiente para soportar la replicación física y la recuperación ante fallos. Este es el valor predeterminado.
max_replication_slots, establecer un valor mayor que 1, el valor debe ser mayor que el numero de BBDD seleccionadas para la migración.
max_wal_senders, establecer un valor mayor que 1, debe establecerse al menos al mismo valor que max_replication_slots, mas el numero de remitentes ya utilizados.
Garantiza que haya suficientes procesos disponibles para transmitir los datos WAL a todas las réplicas configuradas.
wal_sender_timeout, este parámetro finaliza las conexiones de replicación que están inactivas durante más tiempo que el número de milisegundos establecidos. El valor por defecto es, 60000 milisegundos (60 segundos), nosotros podemos establecer como mejor nos convenga.
Estos parámetros, hay que ponerlos al final del archivo postgresql.conf, justo debajo de CUSTOMIZED OPTIONS.
Esto es un ejemplo de configuración, los valores los tenemos que ajustar según el escenario en el que estamos.
Configuración de red entre PostgreSQL y Azure Database for PostgreSQL.
Tenemos que asegurarnos que el servicio de migración funcione correctamente y también asegurarnos de que el servidor de PostgreSQL de origen puede comunicarse con el servidor de Azure Database for PostgreSQL de destino.
A continuación, dejo enlace con la configuración que tenemos que revisar dependiendo del escenario en que estamos.
Consideraciones adicionales:
Configuración de pg_hba.conf, para facilitar la conectividad entre las instancias de PostgreSQL de origen y destino. Este archivo incluye la autenticación del cliente y debe ser configurado para permitir que el PostgreSQL de destino se conecte a la fuente.
Este archivo se encuentra en el directorio de datos de la instalación de PostgreSQL.
Habilitar extensiones
En esta parte, tenemos que asegurar de que si tenemos alguna extensión instalada en nuestro servidor de PostgreSQL origen también están disponibles y las podemos instalar en nuestro servidor flexible Azure database for PostgreSQL.
Para más información sobre las extensiones de PostgreSQL, dejamos el siguiente enlace:
Revisar parámetros de configuración personalizados.
Si en los archivos de configuración de PostgreSQL, tenemos parámetros personalizados, tenemos que revisar y replicarlos en Azure.
Con todas estas configuraciones estaremos listos para realizar nuestra migración Online.
Migración Offline
Con la migración offline, los pasos a seguir son los mismos a excepción de que no tenemos que habilitar el CDC.
Por otro lado, en Azure Database for PostgreSQL flexible server es importante desactivar la alta disponibilidad y las replicas de lectura en el entorno de destino. Estas funciones solo deben activarse una vez finalizada la migración, en ambos casos.
Por último, quedaría crear el proyecto de migración, pero este paso lo veremos en la tercera parte del blog. Espero que os haya servido este post, ¡y os espero en el siguiente!
¿Necesitas una migración rápida y sin pausar tu negocio? ¡Contáctanos!
Data Analyst Associate.
