O Cluster PostgreSQL

Em PostgreSQL, a palavra "cluster" não significa um grupo de máquinas em rede como em quase todos os outros lugares do vocabulário de bancos de dados.

Significa a única instância de servidor em execução e tudo o que essa instância possui: seu diretório de dados, sua memória compartilhada, suas roles e cada banco de dados criado dentro dela.

Resumo

• Um cluster PostgreSQL é a única instância de servidor criada por initdb, mantendo todos os bancos de dados, roles e memória compartilhada que essa instância gerencia em conjunto.
• Por que Importa: Configurações, reinicializações, atualizações e limites de conexão se aplicam no nível do cluster, não no nível do banco de dados, portanto, entender o escopo do cluster evita suposições erradas sobre isolamento.
• Conceitos Chave: cluster, PGDATA, postmaster, banco de dados template, tablespace, role.
• Quando Usar: Decidir se um novo aplicativo recebe seu próprio banco de dados dentro de um cluster existente ou um cluster próprio, raciocinar sobre max_connections como um orçamento compartilhado, ou planejar o isolamento multi-tenant.
• Limitações / Trade-offs: Compartilhar um cluster significa compartilhar o raio de explosão de falhas, atualizações de versão e capacidade de conexão entre todos os bancos de dados dentro dele.
• Tópicos Relacionados: roles e privilégios, pool de conexões, padrões multi-tenant, escopo de backup e restauração.

Fundamentos

Todo servidor PostgreSQL começa sua vida com um único comando: initdb.

Esse comando cria um diretório no disco, convencionalmente chamado PGDATA, e tudo o que a instância do servidor gerenciará um dia vive dentro dele.

Este diretório PGDATA, mais o processo postmaster em execução que o atende, é o que a palavra "cluster" se refere em PostgreSQL.

Uma analogia útil é um prédio de escritórios: o cluster é o próprio prédio, os bancos de dados são os andares, os schemas são as salas em cada andar, e as tabelas são os arquivos dentro de cada sala.

Um prédio tem um saguão, um conjunto de elevadores e um balcão de segurança, não importa quantos andares ele tenha.

Da mesma forma, um cluster tem um processo postmaster, uma região de memória compartilhada e um conjunto de roles, não importa quantos bancos de dados vivam dentro dele.

CREATE DATABASE não inicia um novo processo de servidor nem aloca um bloco separado de memória compartilhada.

Ele copia um banco de dados template (template1 por padrão) para uma nova entrada de banco de dados dentro da mesma instância em execução.

Essa única instância compartilhada é também o motivo pelo qual o termo é confuso no início: não tem nada a ver com clustering de alta disponibilidade, conjuntos de réplicas ou grupos de failover gerenciados por Patroni, que são um conceito completamente diferente e de nível superior construído sobre clusters individuais.

Mecânicas e Interações

Um único arquivo postgresql.conf governa todo o cluster, então configurações como shared_buffers e max_connections são orçamentos para todo o cluster, não permissões por banco de dados.

ALTER DATABASE ... SET e ALTER ROLE ... SET permitem substituir configurações específicas para um banco de dados ou role, mas elas se sobrepõem aos padrões do cluster em vez de substituir a instância compartilhada por baixo delas.

As roles são o exemplo mais claro desse escopo compartilhado, pois uma role criada em um banco de dados é visível e utilizável de qualquer banco de dados no cluster, mesmo que seus privilégios em nível de objeto sejam tipicamente concedidos por banco de dados.

Um processo backend se conecta a exatamente um banco de dados por vez, e não há JOIN entre bancos de dados embutido; acessar outro banco de dados no mesmo cluster requer dblink ou um foreign data wrapper, tratando-o quase como um servidor remoto.

-- Fatos do cluster vs fatos por banco de dados
SHOW data_directory;                 -- um caminho, cluster inteiro
SELECT datname FROM pg_database;     -- cada banco de dados que este cluster possui
SELECT rolname FROM pg_roles;        -- roles são visíveis em todo o cluster

Tablespaces permitem que você coloque bancos de dados individuais, tabelas ou índices em discos físicos diferentes enquanto permanece dentro do mesmo cluster lógico, o que é uma decisão de layout de armazenamento em vez de uma decisão de isolamento.

O WAL (write-ahead log) é gerado como um único fluxo em todo o cluster, que é exatamente o motivo pelo qual a replicação e a recuperação point-in-time são configuradas uma vez por cluster em vez de uma vez por banco de dados.

Como o stream WAL e o pool de buffers compartilhados são ambos em todo o cluster, um pico de atividade de escrita em um banco de dados compete diretamente pelo mesmo orçamento de I/O e memória que todos os outros bancos de dados nessa instância.

Considerações Avançadas e Aplicações

Atualizações de versão principal operam em todo o cluster de uma vez, pois pg_upgrade migra todos os bancos de dados em PGDATA juntos e não há como executar o PostgreSQL 17 para um banco de dados e o PostgreSQL 18 para outro dentro da mesma instância.

Essa restrição de versão única é uma entrada de planejamento real para sistemas multi-tenant, pois significa que todos os tenants que compartilham um cluster são forçados à mesma programação de atualização, quer estejam prontos ou não.

max_connections é a restrição de recurso compartilhado mais crítica na prática, pois é definida uma vez para todo o cluster e todos os bancos de dados, todas as roles e todas as aplicações competem pelo mesmo pool de slots de backend, que é exatamente por que o pool de conexões é importante mesmo em um cluster com pouca carga.

A granularidade do backup segue a mesma divisão de tudo o mais: pg_basebackup captura o cluster inteiro como uma unidade física, enquanto pg_dump pode ter como alvo um único banco de dados para um backup lógico e mais seletivo.

Os limites de segurança precisam da mesma correção, pois as credenciais de login de uma role funcionam em todos os bancos de dados do cluster, embora as instruções GRANT escopem seus privilégios reais por banco de dados ou por objeto, então "banco de dados diferente" não é a mesma garantia que "login diferente".

Equívocos Comuns

• "Um cluster significa múltiplos servidores trabalhando juntos." O termo é anterior e não tem nada a ver com clustering de alta disponibilidade; é simplesmente o nome para uma instância criada por initdb, por mais confusa que essa sobreposição com o vocabulário moderno de HA possa parecer.
• "Roles pertencem a um único banco de dados." Roles são criadas e visíveis em todo o cluster; apenas os privilégios concedidos a uma role são escopados por banco de dados ou por objeto.
• "Diferentes bancos de dados em um cluster podem executar diferentes versões do PostgreSQL." Um binário e um postmaster em execução atendem a todos os bancos de dados em PGDATA, então todo o cluster é atualizado em conjunto via pg_upgrade.
• "Reiniciar o servidor afeta apenas o banco de dados em que estou conectado." Uma reinicialização para e inicia todo o processo postmaster, o que derruba todos os bancos de dados no cluster de uma vez.
• "Mais bancos de dados sempre significam mais isolamento, então é sempre a escolha mais segura." Bancos de dados extras ainda compartilham max_connections, buffers compartilhados e taxa de transferência WAL, então os ganhos de isolamento vêm com trade-offs reais de recursos compartilhados.

FAQs

Relacionados

• Noções Básicas de Instalação - instalando os binários que criam seu primeiro cluster
• initdb e Diretório de Dados - o que initdb realmente cria no disco
• Essenciais do postgresql.conf - o arquivo de configuração de todo o cluster que esta página pressupõe
• Noções Básicas de Roles - por que as roles são globais no cluster, não por banco de dados
• Banco de Dados, Schema e Caminho de Busca - a hierarquia de objetos dentro de um banco de dados

Versões da Stack: Esta página foi escrita para PostgreSQL 18.4 (estável 18, linha de manutenção 17).