Actualización de PostgreSQL sin tiempo de inactividad: Blue/Green, replicación y plan de reversión para bases de datos ERP en producción

Un upgrade de PostgreSQL sin tiempo de inactividad suena a primera vista como una promesa del mundo cloud. En la realidad de una base de datos ERP productiva es más bien una disciplina: debe coordinarse la consistencia de los datos, el comportamiento de las interfaces, las ejecuciones por lotes, el reporting, los permisos y los procesos operativos de modo que el cambio de versión sea solo un momento de conmutación controlado. En este contexto «sin tiempo de inactividad» rara vez debe entenderse de forma absoluta. En la práctica significa: ninguna interrupción perceptible para los usuarios, sin rollbacks no planificados, sin bloqueos de horas —y sobre todo, una vía de reversión que realmente funcione.

Esta entrada sitúa las rutas típicas de actualización para PostgreSQL en entornos ERP —con Blue/Green, replicación (física y lógica) y un plan de reversión que no exista solo sobre el papel. El enfoque se centra deliberadamente en la operación y en las preguntas de decisión: ¿Qué arquitectura es necesaria? ¿Dónde están los riesgos? ¿Qué trabajos preparatorios consumen tiempo? ¿Y cómo evitar que una actualización fracase por temas secundarios como controladores, cadenas de jobs o una soberanía de datos poco clara?

Por qué las bases de datos ERP son especialmente críticas durante las actualizaciones

Los sistemas ERP son OLTP-heavy (Online Transaction Processing), es decir, están optimizados para muchas transacciones cortas: registrar documentos, contabilizar movimientos de almacén, calcular precios, contabilizar pagos. Estas transacciones se sostienen en expectativas claras: la latencia debe ser estable, los bloqueos (locks) no deben escalar y el sistema debe comportarse de forma predecible en picos de carga.

Una actualización de PostgreSQL incide precisamente en esa estabilidad —incluso si la aplicación permanece sin cambios. Entre las causas están, por ejemplo:

• Cambios en el optimizador de consultas (planificador): las consultas pueden optar de repente por planes de ejecución distintos. Eso no es „incorrecto“, pero bajo carga puede generar nuevos puntos calientes.
• Cambios en parámetros y valores por defecto: valores de configuración o su comportamiento por defecto cambian entre versiones mayores. Afecta, por ejemplo, a Autovacuum, WAL (Write-Ahead Log, el registro de transacciones) o a parámetros de memoria como work_mem.
• Problemas con controladores y protocolos: versiones de ODBC/JDBC/Npgsql, parámetros SSL/TLS, autenticación (p. ej. SCRAM vs. MD5) y cadenas de certificados suelen ser bloqueadores ocultos.
• Ecosistema de interfaces: ERP rara vez significa «solo una aplicación». Reporting, EDI, webservices, ETL/BI, gestión documental e integraciones por lotes acceden a la base de datos —directa o indirectamente.

La consecuencia: una actualización no es solo un cambio de base de datos. Es un release coordinado entre aplicación, operaciones y sistemas adyacentes. Precisamente por eso Blue/Green y la replicación son tan valiosos: desacoplan la modificación técnica del riesgo de una ventana de mantenimiento prolongada.

Definir objetivos con claridad: «sin tiempo de inactividad» no significa «sin conmutación»

Antes de elegir una arquitectura, conviene una definición clara de objetivos alineada con métricas operativas:

• RTO (Recovery Time Objective): ¿Con qué rapidez debe la base de datos ERP volver a estar accesible de forma estable tras una falla?
• RPO (Recovery Point Objective): ¿Cuánto dato (periodo de tiempo) puede perderse en el peor caso? En migraciones verdaderamente sin tiempo de inactividad el objetivo suele ser RPO≈0.
• Ventana de mantenimiento: ¿Existe una ventana «pequeña» (p. ej. unos minutos) para un cutover, o ninguna? En ERP la conmutación suele ser posible si es planificable (evitar cambios de turno, cierres de mes).

Estos objetivos determinan si puede trabajar con replicación más Cutover o si necesita además mecanismos de desacoplamiento de escritura (p. ej., encolamiento en las interfaces). Quien aquí sea impreciso pagará más tarde en forma de improvisación durante el Go-live.

Blue/Green para PostgreSQL: principio, utilidad y obstáculos típicos

Blue/Green significa: existen en paralelo dos entornos completos. «Blue» es producción, «Green» es la nueva versión. La ventaja decisiva no es solo la posibilidad de conmutar, sino la capacidad de probar bajo condiciones realistas: Green puede ser verificado con datos cercanos a producción, interfaces reales y monitorización real antes de que los usuarios hagan el cambio.

Para PostgreSQL en el contexto ERP, Blue/Green suele incluir:

• un clúster PostgreSQL separado (Green) en hosts/VMs nuevos o en instancias separadas
• parámetros de red y seguridad idénticos (Firewall, TLS, resolución DNS, cuentas de servicio)
• una transferencia de datos definida (copia inicial + delta)
• un mecanismo de Cutover (conmutación DNS/VIP, cambio de cadena de conexión, proxy)

Lo que Blue/Green le aporta operativamente de verdad

En la práctica son tres puntos los que marcan la diferencia:

• La reversión es rápida: Usted conmuta de vuelta en caso de error, en lugar de reparar un upgrade „hacia atrás“.
• Reducción del riesgo mediante validación previa: Green puede recibir comprobaciones de rendimiento y funcionales, incluyendo la carga típica de ERP (procesos por lotes, impresión, picos de contabilizaciones).
• Separación clara del riesgo de base de datos y de la aplicación: Cuando Green está en ejecución, muchas incógnitas ya están resueltas (controladores, autenticación, extensiones, parámetros).

Los fallos más comunes en Blue/Green

Blue/Green rara vez fracasa por la idea en sí, sino por los detalles:

• Dependencias incompletas: Herramientas de reporting o integraciones acceden „de forma rígida“ al host antiguo (IP, alias, certificate pinning). En el Cutover se quedan bloqueadas.
• Propiedad poco clara de las interfaces: Nadie se siente responsable de que todos los consumidores conmutan o al menos sean probados.
• Falta de validación de datos: „Los datos están replicados“ no significa que todo sea correcto desde el punto de vista funcional (p. ej., secuencias/identidades, marcas temporales, lógica de libros auxiliares).

Replicación como herramienta de actualización: física vs. lógica

Para una actualización de PostgreSQL sin tiempo de inactividad, la replicación suele ser el mecanismo central para mantener los datos en paralelo. PostgreSQL ofrece varios enfoques con distintos compromisos. Importante: «replicación» no es automáticamente «alta disponibilidad». Para las actualizaciones utilice la replicación como puente de migración.

Replicación física (Streaming Replication): rápida, próxima a la máquina

La replicación física opera a nivel de WAL: el standby recibe el registro de transacciones y lo aplica. Es eficiente y estable, pero con una limitación central para actualizaciones mayores: normalmente el Primary y el Standby deben corresponder a la misma versión principal. Por eso, para un salto de versión, p. ej. de PostgreSQL 13 a 16, la replicación física sirve más dentro de una versión (HA, mantenimiento) que como ruta directa para un Major-Upgrade.

No obstante, la replicación física puede ser útil en el proyecto de actualización si la utiliza como red de seguridad en el sistema Blue: antes del Cutover puede asegurarse de que la producción existente es redundante mientras construye en paralelo el sistema Green.

Replicación lógica: transferencia de cambios mediante publicaciones/suscripciones

La replicación lógica transmite cambios a nivel de tabla (INSERT/UPDATE/DELETE) y por ello es adecuada para Major-Upgrades, porque publisher y subscriber pueden tener diferentes versiones principales (atendiendo la compatibilidad correspondiente). Para bases de datos ERP suele ser la vía más práctica para lograr una ventana de conmutación mínima.

Características típicas que debe planificar:

• Instantánea inicial + cambios en curso: Se copia inicialmente el conjunto de datos y a continuación se aplican los cambios.
• DDL no se replica automáticamente: Los cambios de esquema (DDL, es decir, tablas/columnas/índices) no se replican como cambios de datos. Para las actualizaciones esto suele estar bien, porque el esquema suele mantenerse igual; sin embargo, las extensiones, los roles y los permisos deben migrarse de forma consciente.
• Temas de secuencias/identity: Las secuencias (p. ej. para números de documento) son críticas en ERP. Dependiendo de la configuración deberá asegurarse de que los estados de las secuencias se transfieren de forma consistente y que, tras el Cutover, se continúan correctamente.
• Evitar conflictos: Durante la fase de replicación solo debe realizarse escritura en un lado. De lo contrario surgirán conflictos que en el funcionamiento ERP son difíciles de resolver.

La ruta de actualización en la práctica: un modelo de procedimiento sólido

Independientemente de la herramienta exacta, una actualización con tiempo de inactividad minimizado en entornos ERP suele desarrollarse en etapas claras. Una estructura práctica es:

1) Análisis previo: ¿Qué debe trasladarse realmente?

Aquí no se trata de «Instalar PostgreSQL X», sino de dependencias:

• Extensiones (p. ej. para texto completo, tareas programadas, tipos de datos especiales): ¿cuáles están activas en producción y cuáles existen por razones históricas?
• Auth und Rollen: roles locales, integración LDAP/AD, SCRAM, autenticación por certificado. La exportación de roles y permisos es un paso de trabajo independiente.
• Jobs und Batchläufe: ¿se ejecuta el scheduling fuera (p. ej. a través de un jobserver) o en la base de datos (p. ej. mediante extensiones)? ¿Qué jobs son cutover-críticos (procesos nocturnos, facturación, MRP)?
• Consumer-Landschaft: ¿quién lee/escribe? ERP-Backend, portales web, servicios de integración, BI/ETL, conexiones con socios, DMS, monitoring.

Un artefacto sencillo pero eficaz es una Application-Map: la base de datos en el centro, flechas a todos los sistemas incluyendo owner y método de conmutación (DNS, configuración, Secret, proxy). Eso evita que el Cutover falle por lectores „olvidados“ que de repente agotan el tiempo de espera.

2) Green aufbauen: nicht nur Datenbank, sondern Betriebsfähigkeit

Green solo tiene sentido cuando es „operativamente real“. Esto incluye:

• Monitoring (métricas, logs, alarmas): la misma visibilidad que en Blue; de lo contrario el go-live quedará a ciegas.
• Backup/RESTore: las copias en Green deben funcionar, incluyendo pruebas de RESTore (al menos por muestreo). Solo así queda claro que, en caso de fallo, no perderá doblemente.
• Security-Parität: configuración TLS, cipher, cadena de certificados, reglas HBA (Host-Based Authentication), firewall. „Endurecer más tarde“ se cobra al conmutar.
• Performance-Basis: latencia de almacenamiento, IOPS, CPU, RAM. Una actualización es un buen momento para corregir clases de almacenamiento inadecuadas o perfiles de VM obsoletos.

3) Datenübernahme: initiale Kopie und Delta-Phase

Para grandes bases de datos ERP la copia inicial suele ser el paso más largo. No tiene por qué estar dentro de la ventana de mantenimiento si la desacopla de forma limpia. Lo decisivo es que la fase delta (replicación) funcione de manera estable y esté monitorizada: retraso (lag), errores, cambios pendientes.

Operativamente importante: defina umbrales que determinen cuándo iniciar el Cutover. Si Green se queda constantemente rezagado, conmutar es posible, pero trasladará el problema al sistema en producción.

4) Validierung: fachlich und technisch, ohne Perfektionismus

La validación no es un proyecto de pruebas de meses, pero es más que un „SELECT COUNT(*)“. En entornos ERP funcionan bien las siguientes comprobaciones:

• Muestreos en tablas críticas: partidas abiertas, existencias, cabeceras/posiciones de documentos, tablas de determinación de precios, deudores/acreedores.
• Comparaciones de agregados: sumas sobre periodos definidos (ventas, cantidades) para detectar divergencias groseras rápidamente.
• Métricas técnicas: estado de índices y estadísticas, actividad de autovacuum, lag de replicación, límites de conexiones, latencias de consultas.

Lo importante es decidir qué necesita realmente la aceptación. Una actualización no es un release funcional. Quiere demostrar: mismos datos, mismo comportamiento, rendimiento estable. Para ello bastan puntos de comprobación fiables y reproducibles.

5) Cutover: der Umschaltmoment muss wie ein Runbook funktionieren

El Cutover en sí rara vez es complejo, pero es crítico en tiempo. Un buen runbook no solo describe pasos, sino también puntos de comprobación y criterios de abortar. Bloques típicos:

• Controlar el paro de escritura: bien mediante el modo de mantenimiento de la aplicación o mediante un bloqueo técnico (p. ej., cortar conexiones para roles de escritura). Objetivo: no haya nuevas escrituras en Blue en la fase final.
• Llevar la replicación a „cero“: esperar hasta que Green haya aplicado todos los cambios (RPO≈0).
• Conmutación de la aplicación: Connection-Strings, DNS, VIP, regla de proxy. Decisivo: consistente para todos los componentes, no solo para el ERP-Backend.
• Pruebas de humo: Login, abrir datos maestros, contabilizar un documento, informe típico, ping de interfaces. Corto, pero significativo.

Plan de retroceso (Rollback) sin ilusiones: lo que realmente puede revertir

El plan de retroceso es la parte que a uno le gustaría „no necesitar“. Precisamente por eso debe ser concreto. En setups Blue/Green, el retroceso es en el fondo una conmutación de vuelta a Blue. Pero: tan pronto como, después del Cutover, se produzcan Writes productivos en Green, „volver“ se convierte en un problema funcional si Blue no ha recibido también todas las Writes en el ínterin.

Variantes de rollback y sus consecuencias

• Rollback inmediato antes de Writes productivos: caso ideal. Si usted detecta antes de liberar a los usuarios que algo no funciona en lo fundamental, puede conmutar de vuelta sin conflictos de datos.
• Rollback tras pocas Writes: posible, pero solo con una estrategia clara: o bien registrar manualmente los asientos posteriormente (funcional) o aplicar una contrarreplicación temporal/absorción de deltas (técnico), lo cual en procesos ERP rara vez es indoloro.
• No rollback, sino “Fix forward”: si Green ya escribe en producción y el estado de datos allí es la nueva „Single Source of Truth“, conmutar de vuelta suele ser más peligroso que una estabilización dirigida hacia adelante. Eso debe aceptarse como opción de antemano.

Un plan de retroceso sólido por tanto especifica explícitamente:

• hasta cuándo el rollback es „seguro“ (ventana temporal o fase en el Runbook)
• qué criterios de aborto aplican (p. ej. falla la prueba de humo, errores en interfaces, sumas no plausibles)
• cómo se gestionan la comunicación y las aprobaciones (quién decide, quién se informa)

Más importante que el rollback: el “modo de emergencia” para las interfaces

En entornos ERP, las interfaces son la causa más frecuente de situaciones agitadas tras un Cutover. Cuando las conexiones con socios o los servicios de integración internos dejan de entregar de repente, necesita un modo de emergencia: buffers intermedios (Queues), reglas de reinicio, estrategias claras de retry. El „Retry“ debe ser idempotente (repetible sin duplicar asientos). Esto no es una función de la base de datos, sino diseño de aplicación e integración —pero determina si realmente puede alcanzar una actualización sin parada.

Rendimiento y estabilidad tras la actualización: por qué las primeras 48 horas son decisivas

Muchos equipos consideran la actualización como „completada“ tan pronto como se realiza el Cutover. En la práctica comienza entonces la fase en la que los perfiles de carga, el comportamiento del caché y Autovacuum se estabilizan. Medidas típicas que han demostrado su eficacia:

• Monitoreo intensivo en las primeras 48 horas: latencias de consultas, bloqueos, tiempos de espera de I/O, volumen de WAL, ejecuciones de Autovacuum.
• Detectar regresiones de planes: consultas individuales que antes estaban “ok” pueden dominar tras la actualización. Aquí ayudan las listas Top-Query y una escalación clara sobre quién puede optimizar (DBA vs. equipo de aplicación).
• Monitorear por separado Reporting/ETL: las herramientas orientadas a lectura suelen ser las primeras en generar problemas (consultas largas, nuevos planes). Las Read Replicas pueden ayudar, pero deben encajar en el concepto global.

Para la dirección de TI es importante: planifique esta estabilización como parte del cambio. Una actualización sin tiempo de inactividad no significa “sin esfuerzo”, sino esfuerzo en el momento adecuado y con un riesgo controlado.

Decisiones arquitectónicas típicas en torno al ERP: DNS, Connection Strings, Proxies

El cutover será más limpio cuanto más claro sea el punto de conmutación. Variantes comunes:

• Alias DNS (p. ej. db-erp.prod): sencillo, pero el TTL (Time To Live) y el caché del cliente pueden prolongar los tiempos de conmutación. Para algunos controladores, el caché de DNS es sorprendentemente persistente.
• IP virtual / Load Balancer: la conmutación es técnicamente rápida, pero necesita un concepto claro de comprobaciones de salud; de lo contrario enrutará hacia estados inestables.
• Connection string mediante configuración/secret: fácil de controlar si dispone de una distribución central de configuración. Riesgo: no todos los componentes aplican la nueva configuración al mismo tiempo.
• DB-Proxy: puede ayudar a centralizar la conmutación, pero añade complejidad adicional y un nuevo servicio crítico en la cadena.

Para software empresarial consolidado suele ser realista una combinación: los servicios centrales se conmutan por configuración, las componentes heredadas por DNS. Es importante reflejarlo y probarlo en el runbook —incluyendo los jobs “olvidados” en un servidor de aplicaciones antiguo.

Seguridad y cumplimiento: la actualización como oportunidad, pero no como un frente secundario

Las actualizaciones de PostgreSQL son una buena ocasión para cerrar fallos de seguridad: métodos de autenticación obsoletos, roles demasiado amplios, permisos de red poco claros. Al mismo tiempo, la seguridad no debe convertirse en un crecimiento incontrolado del alcance.

Enfoque pragmático:

• Paridad de seguridad para el cutover: Green debe ser al menos tan seguro como Blue, preferiblemente con pequeñas mejoras claras (p. ej. valores predeterminados de TLS, SCRAM en lugar de MD5, reglas HBA más RESTrictivas).
• Realizar reformas mayores posteriormente: refactorización de roles, segmentación de red estricta o rotación completa de secretos son valiosos, pero es mejor tratarlos como un paquete de cambio independiente tras la estabilización.

Evaluar el esfuerzo de forma realista: dónde los proyectos pierden tiempo en la práctica

Para la planificación y la comunicación ayuda una estructura de esfuerzo honesta. Por experiencia, los consumidores de tiempo no son “instalar PostgreSQL”, sino:

• Inventario de consumidores: localizar todos los lectores/escritores, aclarar los responsables, definir la vía de conmutación.
• Datos de prueba y entorno de prueba: datos cercanos a producción (respetando la protección de datos) y carga realista son decisivos, de lo contrario las pruebas no reflejarán el problema.
• Runbooks y aprobaciones: ¿Quién puede hacer qué durante la ventana de mantenimiento? ¿Quién decide sobre el rollback? ¿Quién comunica? Sin claridad se generan retrasos en el momento crítico.
• Aspectos de controladores/TLS: pequeñas incompatibilidades pueden generar grandes síntomas (desconexiones esporádicas, errores de autenticación, timeouts).

Si gestiona estos puntos desde el principio como paquetes de trabajo independientes, la “actualización” se convertirá en un proyecto controlable en lugar de un fin de semana nervioso.

Conclusión: una actualización de PostgreSQL sin tiempo de inactividad es, sobre todo, un diseño operativo

Una actualización de PostgreSQL sin tiempo de inactividad no se logra con un truco aislado, sino con una arquitectura que hace manejable la conmutación y la reversión. Blue/Green aporta la separación necesaria, la replicación proporciona el puente de datos y un plan de reversión realista evita que el equipo, en caso de fallo, tenga que elegir entre pérdida de datos y una interrupción de varias horas.

Si realiza un inventario preciso del panorama de consumidores, monta Green como un entorno operativo (monitorización, copias de seguridad, seguridad), supervisa la transferencia de datos y ensaya el Cutover como un runbook con criterios de abortar, el salto de versión se convierte en un cambio controlado — incluso en bases de datos ERP productivas con muchas interfaces.

Si desea preparar de forma estructurada la actualización de su base de datos ERP y considerar conjuntamente la arquitectura, las interfaces y el plan de reversión, hable con nosotros:

Para este tema también son importantes el Blue/Green Deployment y el plan de Cutover. El artículo contextualiza estos aspectos de forma clara y muestra qué importa en la operativa diaria.

Hablar sobre un proyecto o iniciativa de modernización con Net-Base.