PostgreSQL
postgres es el servidor de bases de datos de Sora: una VM con PostgreSQL del repositorio PGDG y PgBouncer delante, su exporter de Prometheus, un volcado nocturno de todas las bases de datos a NFS y un script de restauración manual.
Un único servidor por entorno guarda las bases de datos de todas las aplicaciones, cada una con su propio usuario y base de datos.
| PostgreSQL | Del repositorio PGDG. postgres_version fija una versión mayor; vacío instala la última |
| Conexiones | Aplicaciones por PgBouncer :6432 en modo transacción; administración por :5432; scram-sha-256 en todo |
| Ajustes | Calculados según la memoria y los núcleos de la máquina, sobrescribibles uno a uno |
| Métricas | Node Exporter en 9100, postgres_exporter en 9187 |
| Copias | Todas las bases de datos a NFS según backup_cron, siete copias |
| Hardware | 4 vCPU, 8 GiB, disco raíz de 32 GiB y disco de datos de 100 GiB por defecto |
Despliegue
La plantilla PostgreSQL Server se despliega en tres fases:
| Fase | Trabajo | Qué instala |
|---|---|---|
1 infra | vm | La máquina con su disco de datos |
2 database | postgres | PostgreSQL en /data, pg_hba.conf, los ajustes y la contraseña del superusuario |
3 services | pooler, exporter, backup | PgBouncer, el exporter y las copias de seguridad, en paralelo |
Antes de crear el stack, en Inventario › Carpetas compartidas hay que dar acceso de escritura a la dirección de la VM en la carpeta NFS de copias de seguridad. Horizon solo ofrece las carpetas NFS en las que la máquina puede escribir. El propio servidor NFS también debe permitirle el acceso.
Después, crear el stack con su registro DNS, llave SSH y servidor Proxmox, y responder:
| Sección | Qué decidir |
|---|---|
| PostgreSQL | La versión mayor (vacío para la última) y la contraseña del superusuario (vacío para generarla) |
| Tuning | storage_type (qué es realmente el disco de datos) y cualquier ajuste extra en settings |
| Pooler | Los valores por defecto, salvo que una aplicación necesite el modo session |
| Backup | El servidor y la carpeta NFS, y la hora del volcado |
La contraseña del superusuario queda en la salida pgadmin_password del trabajo postgres.
Además de los checks base, Nagios vigila PostgreSQL (5432), PgBouncer (6432), la copia de seguridad y el exporter.
Crear un usuario
Cada aplicación necesita su propio usuario y base de datos. Se crean con la acción Create User del stack: los datos de conexión llegan ya rellenados desde el trabajo postgres, así que solo se pregunta el nombre. Si la contraseña se deja vacía, se genera y se devuelve en dbuser_password.
El usuario puede conectarse por PgBouncer al momento: PgBouncer consulta las credenciales directamente a PostgreSQL, así que no hay que registrar nada en él. Destruir una instancia de la acción borra el usuario y la base de datos; los volcados del NFS se mantienen.
Una conexión al servidor pertenece a un cliente solo durante una transacción. No sobreviven: los SET de sesión (usar SET LOCAL o ALTER ROLE app SET ...), los advisory locks entre transacciones, LISTEN/NOTIFY, los cursores WITH HOLD y las tablas temporales. Los prepared statements de los drivers sí funcionan. Si una aplicación necesita algo de lo anterior, se conecta al 5432 o el stack usa pool_mode = session.
Cambiar ajustes
Cada ajuste es una variable, y editarla vuelve a ejecutar únicamente su trabajo:
- Los ajustes de tuning reescriben la configuración y recargan; solo reinician si el parámetro lo necesita (
shared_buffers,max_connections, ...). Si PostgreSQL rechaza un valor, se restaura la configuración anterior. - Los ajustes del pooler reinician PgBouncer.
- El horario de la copia reescribe el cron y el check de Nagios.
Para ampliar la máquina, cambiar CPU o memoria en el trabajo vm y después usar Run again en postgres, que recalcula los ajustes. Cambiar postgres_version en un servidor desplegado se rechaza: una versión mayor se actualiza a mano con pg_upgradecluster.
Copias de seguridad
El volcado se ejecuta cada noche según backup_cron y una vez durante el despliegue, de forma que un servidor nuevo nunca queda sin copia. Rota las carpetas numeradas en /mnt/backup/<vm>/ (01 es la más reciente, se mantienen siete) y escribe un pg_dump por cada base de datos. Una base de datos nueva entra en la copia sin hacer nada.
El check de Nagios se pone en warning si la copia no ha terminado bien tras backup_check_warning minutos desde su hora, y en critical tras backup_check_critical.
Restaurar
La restauración siempre es manual, con el script que se instala junto a los de copia:
ls /mnt/backup/mioakiyama/01/
sudo /opt/scripts/restore_PostgreSQL.sh keycloak /mnt/backup/mioakiyama/01/keycloak_2026-09-04_06-00-01.sql
Documentación
- architecture.md: componentes, puertos, credenciales y tamaño.
- tuning.md: cada ajuste, su motivo y las medidas que lo respaldan.
- operations.md: despliegue, usuarios, el pooler, cambios y actualizaciones.
- backup.md: la copia, su monitorización y la restauración.