Melhores Práticas de Instalação

Regras operacionais para inicializar clusters PostgreSQL que sobrevivem a auditorias, atualizações e chamadas às 3 da manhã.

Como Usar Esta Lista

• Aplique durante a primeira instalação em produção, não como uma correção após um incidente.
• Marque os itens na sua PR de infraestrutura como código antes de marcar o host como em produção.
• Revise após atualizações de versão principal - os padrões de inicialização e os caminhos podem mudar.

A - Plataforma e Versão

• Execute uma versão principal suportada em um sistema operacional secundário suportado. Sistemas operacionais EOL ou versões principais do Postgres em fim de vida são um defeito de conformidade à espera de acontecer.
• Fixe a versão principal do PostgreSQL nos nomes dos pacotes ou imagens. Metapacos postgresql variam entre distribuições.
• Ative --data-checksums no initdb. Não pode ser adicionado posteriormente sem reconstrução.
• Use codificação UTF8 e documente a escolha da collation. C.UTF-8 vs. específico de locale afeta a ordem de classificação para sempre.
• Registre a string de versão exata no inventário. SELECT version(); na sua CMDB.

B - Layout do Armazenamento

• Separe o WAL em seu próprio volume quando houver gargalo de IO. O WAL com muitas escritas compete com o IO aleatório do heap.
• Dimensiona o sistema de arquivos PGDATA com 30%+ de espaço livre. Disco cheio para escritas e pode corromper a recuperação.
• Use chmod 700 e propriedade postgres:postgres no PGDATA. Diretórios de dados legíveis por qualquer pessoa falham em auditorias.
• Prefira XFS ou ext4 com noatime em volumes de dados. Documente as opções de montagem nos runbooks.
• Evite NFS para PGDATA primário, a menos que aprovado pelo fornecedor. Latência e travamentos causam problemas.

C - Configuração

• Documente cada GUC não padrão com justificativa. Operadores futuros não podem adivinhar por que max_connections = 400.
• Defina shared_buffers, work_mem, max_connections conservadores na primeira passagem. Ajuste com métricas, não com posts de blog.
• Use include_if_exists para substituições locais. Mantenha postgresql.conf compatível com o gerenciador de pacotes.
• Defina log_line_prefix com pid, usuário, db, nome do aplicativo. Você precisará disso no primeiro incidente.
• Ative log_connections e log_disconnections até que esteja estável, depois reduza. Ajuda a rastrear falhas de autenticação.

D - Rede e Autenticação

• Negação padrão em pg_hba.conf; permita apenas sub-redes explícitas. A primeira correspondência vence - ordene as regras cuidadosamente.
• Use scram-sha-256 para autenticação de senha. Desative md5 e proíba trust em TCP.
• Exija hostssl para conexões remotas de aplicativos. Combine com certificados TLS válidos.
• Vincule listen_addresses apenas a NICs internas. Listener público + HBA fraco é um padrão de violação.
• Crie roles dedicadas de replicação e administração. Nunca reutilize senhas de aplicativos para replicação.

E - Gerenciamento de Serviço

• Ative a unidade systemd na inicialização com TimeoutStopSec adequado. 300s+ em sistemas com muita memória.
• Verifique se o PGDATA na unidade corresponde a SHOW data_directory. Hosts multi-instância confundem isso facilmente.
• Teste os procedimentos de reload vs restart em um teste. Operadores devem saber qual configuração precisa de qual.
• Envie logs para armazenamento centralizado. O journald sozinho é perdido em caso de falha de disco.
• Automatize o backup antes de declarar pronto para produção. Um runbook vazio não é um cluster.

FAQs

Relacionado

• Noções Básicas de Instalação - exemplos de instalação de plataforma
• initdb e Diretório de Dados - layout do PGDATA
• Essenciais do postgresql.conf - primeira passagem de ajuste
• pg_hba.conf e Autenticação - regras de autenticação de rede

Versões de Stack: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x e PostGIS 3.5+.