Migración de base de datos sin tiempo de inactividad

Una migración de base de datos sin tiempo de inactividad mueve PostgreSQL, MySQL u Oracle mientras la aplicación sigue atendiendo. Es uno de los mayores desafíos para un equipo de infraestructura. Retirar el sistema de servicio durante horas para realizar copias de seguridad y restauración genera pérdidas de facturación en e-commerces y fricciones en operaciones 24/7.

A continuación, presentamos los principales enfoques técnicos para realizar migraciones de datos complejas con cero tiempo de inactividad (Zero Downtime).

1. Replicación Lógica (Logical Replication)

A diferencia de la replicación física (que crea una copia bit a bit idéntica del disco del servidor), la replicación lógica permite transmitir flujos de modificaciones de tablas específicas y concretas entre diferentes versiones y servidores.

El Flujo:

1. Monte el nuevo servidor de base de datos vacío.
2. Inicie un canal de replicación lógica desde el servidor de origen hacia el nuevo destino.
3. La nueva base de datos se sincronizará continuamente mientras las transacciones activas se siguen guardando en la antigua.
4. Cuando ambas estén emparejadas (retraso cercano a cero), cambie las credenciales de conexión de la aplicación para apuntar a la nueva base de datos.

2. Enfoque de Escritura Doble (Double Write)

En caso de que el nuevo servidor utilice un sistema o estructura de datos incompatible con la replicación lógica nativa, se utiliza la técnica de doble escritura a nivel de aplicación.

Las Fases:

• Fase 1: Actualice la aplicación para leer datos de la base de datos antigua, pero registrar inserciones y actualizaciones en ambas bases de datos (antigua y nueva).
• Fase 2: Ejecute un script en segundo plano para migrar los datos heredados creados antes de la Fase 1, omitiendo los registros que la aplicación ya ha actualizado de forma doble.
• Fase 3: Una vez validada la consistencia de los datos, cambie las lecturas de la aplicación a la nueva base de datos.
• Fase 4: Elimine el código de doble escritura y apague la base de datos antigua de forma segura.

3. Replicación lógica en PostgreSQL

Las tablas replicadas necesitan clave primaria. En el servidor de origen, wal_level pasa a logical y PostgreSQL reinicia:

sudo -u postgres psql -c "ALTER SYSTEM SET wal_level = 'logical';"
sudo systemctl restart postgresql

Usuario solo de replicación, publicación de las tablas y, en el destino, la suscripción. Cambie la IP y la clave:

CREATE ROLE replicador WITH REPLICATION LOGIN PASSWORD 'cambie-esta-clave';
GRANT SELECT ON clientes, pedidos TO replicador;
CREATE PUBLICATION pub_app FOR TABLE clientes, pedidos;

CREATE SUBSCRIPTION sub_app
  CONNECTION 'host=10.0.0.10 port=5432 dbname=app user=replicador password=cambie-esta-clave'
  PUBLICATION pub_app;

La publicación corre en el origen. La suscripción corre en la base nueva, que tiene que alcanzar el origen en el puerto 5432. El retraso se ve en esta consulta, en el origen:

SELECT slot_name, confirmed_flush_lsn, pg_current_wal_lsn()
FROM pg_replication_slots;

Cuando confirmed_flush_lsn acompaña a pg_current_wal_lsn, el corte es cambiar la connection string de la aplicación. La consulta lenta y el índice después del corte están en consultas lentas en PostgreSQL.

Conclusión

Realizar migraciones con cero downtime exige una planificación arquitectónica detallada y fases de validación de consistencia. Al implementar replicación lógica o flujos estructurados de doble escritura, la operación de la empresa continúa generando ingresos normalmente durante las actualizaciones tecnológicas de la infraestructura de datos.