Actualización de versión menor de PostgreSQL (patch)

Actualización menor dentro de la misma versión principal (por ejemplo, 17.4 → 17.x): revisión de las release notes, copia de seguridad y conservación de los RPM/deb actuales para la marcha atrás. En un solo servidor, con una interrupción breve; en un cluster con streaming replication se actualizan primero los standby y después el primary mediante switchover (rolling); en un cluster Patroni, las réplicas se actualizan con patronictl restart y el leader tras patronictl switchover. Incluye la actualización de extensiones, la verificación y un runbook de marcha atrás (downgrade). Al final, todos los servidores ejecutan la misma versión menor nueva y usted conserva los archivos de la versión anterior para volver atrás.

Si cambia la versión principal (por ejemplo, 16 → 17), no use esta guía sino pg-major-upgrade; la actualización del propio software de Patroni está en pg-patroni.

Topología: 1 servidor, primary + standby o un cluster Patroni

Escenarios

• Actualización menor — Paso a una versión menor más reciente dentro de la misma versión principal (por ejemplo, 17.4 → 17.6): correcciones de seguridad y de errores. Interrupción breve en un solo servidor; rolling en un cluster.
• Marcha atrás: volver a la versión menor anterior (downgrade) — Ha aparecido un error o una regresión en la nueva versión menor: se vuelve atrás con los RPM/deb guardados de la versión anterior. El directorio de datos no cambia.

Antes de empezar

• PostgreSQL … está instalado desde el repositorio PGDG y en ejecución (pg-install). La actualización se hace dentro de la misma versión principal; para pasar de … a otra versión principal use la guía pg-major-upgrade.
• Se han leído las release notes de cada versión menor entre la versión actual y la de destino. En particular, se ha anotado si la sección "Migration to Version …" pide alguna acción adicional (REINDEX, un cambio de configuración): https://www.postgresql.org/docs/release/
• Los servidores acceden al repositorio PGDG o a un mirror interno, y el mirror está actualizado.
• La ventana de mantenimiento está aprobada… (el servicio queda parado entre unos segundos y unos minutos)… (las conexiones se cortan unos segundos en el switchover/reinicio)…; el equipo de la aplicación está informado.
• La última copia de seguridad terminó bien… (pgbackrest info status ok)… y se pueden tomar snapshots de máquina virtual/disco de los servidores.
• Todos los standby están en streaming y sin retraso.
• Como los roles cambian tras el switchover, el pg_hba.conf de cada nodo permite conexiones replication desde los demás nodos, y la contraseña de … está en el archivo ~/.pgpass del usuario postgres en todos los nodos.
• El cluster no está gestionado por una herramienta de HA como Patroni o repmgr. Si lo gestiona Patroni, elija Patroni en Topología; para repmgr, consulte las Notas. Los pasos de switchover manual de esta vía entran en conflicto con las decisiones de la herramienta de HA.
• El cluster Patroni está sano: un Leader, todas las réplicas en streaming, Lag pequeño y Maintenance mode desactivado. … es el leader actual; los nombres de las réplicas coinciden con los nombres de miembro de Patroni.
• Los comandos de patronictl que hacen cambios (restart, switchover) requieren autenticación en la API REST; el usuario y la contraseña están en /etc/patroni/patroni.env en todos los nodos (instalación de pg-patroni). Si usa otra organización, restapi.authentication debe estar definido en el archivo que patronictl lee con -c.
• Antes de la actualización se guardaron en el directorio … los archivos RPM/deb de la versión anterior y el número de esa versión está en …/prev-version.txt. Si no existen, tendrá que descargar la versión anterior del repositorio (EL: PGDG conserva las versiones antiguas; Debian/Ubuntu: apt-archive.postgresql.org).

Fases de la guía

• Comprobaciones previas — Registrar la versión actual · Listar las versiones del repositorio · Revisar las release notes · Listar las extensiones instaladas · Comprobar las transacciones largas y las prepared transactions
• Copia de seguridad y punto de retorno — Hacer copia de seguridad (pgBackRest) · Hacer copia de seguridad (pg_dumpall + snapshot) · Conservar los archivos RPM/deb actuales
• Cluster Patroni: comprobación previa — Verificar el estado del cluster y los roles
• Actualización — Ejecutar un checkpoint · Parar PostgreSQL · Actualizar el software · Iniciar PostgreSQL
• Actualización del primary (interrupción breve) — Ejecutar un checkpoint · Parar el primary · Actualizar el software · Iniciar el primary
• Switchover y actualización del primary antiguo — Verificar que la replicación está al día · Detener las escrituras de la aplicación · Parar limpiamente el primary antiguo y anotar el último checkpoint · …: verificar que ha llegado todo el WAL y promover · Redirigir las aplicaciones al nuevo primary · Crear un replication slot para el primary antiguo …
• Leader: switchover y actualización del leader antiguo — Leader antiguo: actualizar el software · Switchover: hacer leader a … · Reiniciar el leader antiguo (…) · Verificar el estado final del cluster
• Extensiones y verificación — Actualizar las extensiones (ALTER EXTENSION … UPDATE) · Actualizar las extensiones (ALTER EXTENSION … UPDATE) · Aplicar las acciones adicionales de las release notes · Verificar la versión y el estado · Buscar errores en los logs · Copia de seguridad tras la actualización …
• Marcha atrás (downgrade) — Comprobar la versión anterior · …: parar, instalar la versión anterior, iniciar · …: instalar la versión anterior y reiniciar con Patroni · Leader: instalar la versión anterior · Ceder el leader y reiniciar el leader antiguo · …Parar el primary…Parar PostgreSQL… …