El Clúster de PostgreSQL

En PostgreSQL, la palabra "clúster" no significa un grupo de máquinas en red como lo hace en casi todas partes del vocabulario de bases de datos.

Significa la única instancia de servidor en ejecución, y todo lo que esa instancia posee: su directorio de datos, su memoria compartida, sus roles y cada base de datos creada dentro de ella.

Resumen

• Un clúster de PostgreSQL es la única instancia de servidor creada por initdb, que contiene todas las bases de datos, roles y memoria compartida que esa instancia gestiona conjuntamente.
• Por Qué Importa: La configuración, los reinicios, las actualizaciones y los límites de conexión se aplican a nivel de clúster, no a nivel de base de datos, por lo que comprender el alcance del clúster evita suposiciones erróneas sobre el aislamiento.
• Conceptos Clave: clúster, PGDATA, postmaster, base de datos plantilla, tablespace, rol.
• Cuándo Usar: Decidir si una nueva aplicación obtiene su propia base de datos dentro de un clúster existente o un clúster propio, razonar sobre max_connections como un presupuesto compartido, o planificar el aislamiento multi-inquilino.
• Limitaciones / Compensaciones: Compartir un clúster significa compartir el radio de explosión de fallos, las actualizaciones de versión y la capacidad de conexión entre todas las bases de datos dentro de él.
• Temas Relacionados: roles y privilegios, agrupación de conexiones, patrones multi-inquilino, alcance de copia de seguridad y restauración.

Fundamentos

Cada servidor PostgreSQL comienza su vida con un único comando: initdb.

Ese comando crea un directorio en el disco, convencionalmente llamado PGDATA, y todo lo que la instancia del servidor gestionará alguna vez vive dentro de él.

Este directorio PGDATA, más el proceso postmaster en ejecución que lo sirve, es a lo que se refiere la palabra "clúster" en PostgreSQL.

Una analogía útil es un edificio de oficinas: el clúster es el edificio en sí, las bases de datos son los pisos, los esquemas son las habitaciones en cada piso, y las tablas son los archivadores dentro de cada habitación.

Un edificio tiene un solo vestíbulo, un solo conjunto de ascensores y un solo puesto de seguridad, sin importar cuántos pisos tenga.

De la misma manera, un clúster tiene un solo proceso postmaster, una sola región de memoria compartida y un solo conjunto de roles, sin importar cuántas bases de datos vivan dentro de él.

CREATE DATABASE no inicia un nuevo proceso de servidor ni asigna un bloque separado de memoria compartida.

Copia una base de datos plantilla (template1 por defecto) a una nueva entrada de base de datos dentro de la misma instancia en ejecución.

Esa única instancia compartida es también la razón por la que el término es confuso al principio: no tiene nada que ver con el clustering de alta disponibilidad, los conjuntos de réplicas o los grupos de failover gestionados por Patroni, que son un concepto completamente diferente y de nivel superior construido sobre clústeres individuales.

Mecánicas e Interacciones

Un único archivo postgresql.conf rige todo el clúster, por lo que configuraciones como shared_buffers y max_connections son presupuestos generales del clúster, no asignaciones por base de datos.

ALTER DATABASE ... SET y ALTER ROLE ... SET le permiten anular configuraciones específicas para una base de datos o rol, pero se superponen a los valores predeterminados generales del clúster en lugar de reemplazar la instancia compartida subyacente.

Los roles son el ejemplo más claro de este alcance compartido, porque un rol creado en una base de datos es visible y utilizable desde todas las bases de datos del clúster, aunque sus privilegios a nivel de objeto normalmente se otorgan por base de datos.

Un proceso backend se conecta a exactamente una base de datos a la vez, y no hay JOIN entre bases de datos incorporado; acceder a otra base de datos en el mismo clúster requiere dblink o un wrapper de datos foráneos, tratándola casi como un servidor remoto.

-- Hechos generales del clúster frente a hechos por base de datos
SHOW data_directory;                 -- una ruta, clúster completo
SELECT datname FROM pg_database;     -- cada base de datos que posee este clúster
SELECT rolname FROM pg_roles;        -- los roles son visibles en todo el clúster

Los tablespaces le permiten colocar bases de datos, tablas o índices individuales en discos físicos diferentes mientras permanecen dentro del mismo clúster lógico, lo cual es una decisión de diseño de almacenamiento en lugar de una decisión de aislamiento.

WAL (write-ahead log) se genera como un único flujo general del clúster, que es exactamente por qué la replicación y la recuperación en un punto en el tiempo se configuran una vez por clúster en lugar de una vez por base de datos.

Debido a que el flujo WAL y el grupo de búferes compartidos son generales del clúster, un pico de actividad de escritura en una base de datos compite directamente por el mismo presupuesto de E/S y memoria que cualquier otra base de datos en esa instancia.

Consideraciones Avanzadas y Aplicaciones

Las actualizaciones de versión principal operan sobre todo el clúster a la vez, ya que pg_upgrade migra todas las bases de datos en PGDATA juntas y no hay forma de ejecutar PostgreSQL 17 para una base de datos y PostgreSQL 18 para otra dentro de la misma instancia.

Esa restricción de versión única es una entrada de planificación real para sistemas multi-inquilino, ya que significa que cada inquilino que comparte un clúster se ve obligado a seguir el mismo calendario de actualizaciones, independientemente de si están listos para ello o no.

max_connections es la restricción de recurso compartido más crítica en la práctica, ya que se establece una vez para todo el clúster y cada base de datos, cada rol y cada aplicación compiten por el mismo grupo de ranuras de backend, que es exactamente por qué la agrupación de conexiones es importante incluso en un clúster con poca carga.

La granularidad de la copia de seguridad sigue la misma división que todo lo demás: pg_basebackup captura todo el clúster como una unidad física, mientras que pg_dump puede dirigirse a una sola base de datos para una copia de seguridad lógica y más selectiva.

Los límites de seguridad necesitan la misma corrección, porque las credenciales de inicio de sesión de un rol funcionan en todas las bases de datos del clúster, aunque las sentencias GRANT delimitan sus privilegios reales por base de datos o por objeto, por lo que "base de datos diferente" no es la misma garantía que "inicio de sesión diferente".

Conceptos Erróneos Comunes

• "Un clúster significa múltiples servidores trabajando juntos." El término es anterior y no tiene nada que ver con el clustering de alta disponibilidad; es simplemente el nombre de una instancia creada por initdb, sin importar cuán confusa sea esa superposición con el vocabulario moderno de HA.
• "Los roles pertenecen a una sola base de datos." Los roles se crean y son visibles en todo el clúster; solo los privilegios otorgados a un rol están limitados por base de datos u objeto.
• "Diferentes bases de datos en un clúster pueden ejecutar diferentes versiones de PostgreSQL." Un binario y un postmaster en ejecución sirven a todas las bases de datos en PGDATA, por lo que todo el clúster se actualiza conjuntamente a través de pg_upgrade.
• "Reiniciar el servidor solo afecta a la base de datos en la que estoy trabajando." Un reinicio detiene e inicia todo el proceso postmaster, lo que interrumpe todas las bases de datos del clúster a la vez.
• "Más bases de datos siempre significa más aislamiento, por lo que siempre es la opción más segura." Las bases de datos adicionales todavía comparten max_connections, búferes compartidos y rendimiento WAL, por lo que las ganancias de aislamiento vienen con compensaciones reales de recursos compartidos.

Preguntas Frecuentes

Relacionado

• Fundamentos de Instalación - instalación de los binarios que crean su primer clúster
• initdb y Directorio de Datos - qué crea realmente initdb en el disco
• Esenciales de postgresql.conf - el archivo de configuración general del clúster que esta página asume
• Fundamentos de Roles - por qué los roles son generales del clúster, no por base de datos
• Base de Datos, Esquema y Ruta de Búsqueda - la jerarquía de objetos dentro de una base de datos

Versiones de Stack: Esta página fue escrita para PostgreSQL 18.4 (estable 18, línea de mantenimiento 17).