Janelas de Manutenção
Janelas de manutenção são um contrato com usuários e engenheiros de plantão. Agende trabalhos de alto impacto no Postgres quando o raio de explosão for compreendido, comunicado e reversível.
Receita
Cartão de receita de referência rápida - pronto para copiar e colar.
## Modelo de Aviso de Manutenção
Janela: 2026-07-12 02:00-04:00 UTC (baixo tráfego)
Impacto: Picos de latência de escrita de até 30s; sem interrupção de leitura planejada
Alterações: Reconstrução do índice V2050, ensaio de switchover do Patroni
Reversão: Reverter migração V2050; DNS inalterado
Página de status: https://status.example.com/incidents/42-- Pré-janela: confirmar que não há transações longas inesperadas
SELECT count(*) FROM pg_stat_activity
WHERE state = 'idle in transaction'
AND now() - xact_start > interval '10 minutes';Quando usar isso: DDL de alto risco, simulações de failover, redimensionamento de armazenamento que requer reinicialização ou cutover de pg_upgrade.
Exemplo de Trabalho
A equipe agenda VALIDATE CONSTRAINT na tabela payments com 80 milhões de linhas durante a janela de domingo às 03:00 UTC.
# T-7 dias: e-mail ao cliente + banner no aplicativo
# T-1 dia: congelar outras alterações de alto risco
# T-0: ponte de plantão aberta, escriba designadoSET lock_timeout = '3s';
SET statement_timeout = '2h';
ALTER TABLE payments VALIDATE CONSTRAINT payments_amount_positive;# Pós-janela: verificar taxa de erro e lag de replicação
psql -c "SELECT pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) FROM pg_stat_replication;"O que isso demonstra:
- Comunique o impacto visível ao usuário, não apenas "manutenção do banco de dados".
- Congele mudanças concorrentes para evitar tempestades de locks.
- Defina timeouts de sessão antes do DDL na janela.
- Verifique se as réplicas alcançaram antes de declarar sucesso.
Análise Profunda
Dimensionamento da Janela
| Tipo de trabalho | Dica de dimensionamento |
|---|---|
CREATE INDEX CONCURRENTLY | 2-3x duração em staging |
| Validação de restrição | Tempo de varredura da tabela + buffer de retentativa de lock |
| Simulação de failover | Tempestade de cold-start do aplicativo + 15 min de observação |
pg_upgrade | Mínimo da documentação do fornecedor + buffer de 100% na primeira vez |
Escolha janelas a partir de dashboards de tráfego, não apenas conveniência do fuso horário local.
Linguagem de Impacto Honesta
| Diga isto | Não diga isto |
|---|---|
| "O checkout pode expirar por até 60 segundos" | "Manutenção breve" |
| "Modo somente leitura para a API de relatórios" | "Nenhum impacto esperado" |
| "O failover pode derrubar transações em andamento" | "Upgrade transparente" |
Política de Congelamento
Durante a janela:
- Sem implantações de aplicativos não relacionadas.
- Sem experimentos de política de autoescalonamento.
- Sem rotações de certificado, a menos que incluídas no mesmo runbook.
-- Opcional: revogar CREATE de roles do aplicativo durante a janela (casos extremos)
REVOKE CREATE ON SCHEMA public FROM app_migrator;Armadilhas
- Empilhamento de múltiplos DDLs de alto risco - Uma falha no meio da janela obscurece a causa raiz. Correção: Um objetivo principal por janela.
- Deriva silenciosa de réplica - DDL pesado no primário aumenta o lag; aplicativos que leem réplicas veem dados obsoletos. Correção: Monitore o lag de bytes; atrase o cutover do tráfego de leitura.
- Tempo de reversão ausente - A janela termina antes que a verificação seja concluída. Correção: Reserve um buffer de 30 minutos; estenda a página de status, se necessário.
- Base de usuários global - "Baixo tráfego" localmente é pico em outros lugares. Correção: Use heatmaps de tráfego UTC.
- Pools de conexão esquecidos - Aplicativos mantêm conexões durante reinicializações breves. Correção: Esvazie o PgBouncer previamente; coordene o tempo de vida máximo.
Alternativas
| Alternativa | Use quando | Não use quando |
|---|---|---|
| Somente DDL online | Cultura madura de expansão/contração | Correção de emergência requer reescrita imediata |
| Banco de dados Blue/green | Orçamento de cutover sem tempo de inatividade | Equipe pequena sem automação |
| Janela somente leitura | Proteger dados durante operação arriscada | Gravações necessárias para receita |
| Mudança imediata | Mitigação Sev-1 | Melhoria planejada de esquema |
FAQs
Com que frequência devemos executar janelas de manutenção?
Mensalmente para lotes de risco médio; ad hoc para alto risco; trimestralmente para simulações de DR.
Precisamos de uma página de status para banco de dados apenas interno?
Sim, se alguma API voltada para o cliente depender do banco de dados.
Podemos executar o índice CONCURRENTLY fora de uma janela?
Frequentemente sim para nível baixo; ainda assim, notifique o plantão e monitore o lag.
Quem aprova a extensão da janela?
Comandante de Incidente ou proprietário da mudança mais oficial de produto.
E se a migração exceder a janela?
Comunique a nova ETA; reverta se ultrapassar o SLA de reversão.
Os aplicativos devem reduzir a escala antes da manutenção?
Às vezes, aumente os workers de conexão após a reinicialização; planeje por runbook.
Como escolhemos o fuso horário?
Menor TPS de escrita global das métricas, não localização do escritório.
Simulações de failover são manutenção?
Sim. Trate-as com a mesma comunicação e rigor de reversão.
Quais métricas definem o sucesso pós-janela?
Taxa de erro, latência p95, lag de bytes de replicação, profundidade da fila de trabalhos com falha.
O que devo ler a seguir?
Veja SLOs de Uptime para Datastores para alinhamento de orçamento de erro.
Relacionados
- Noções Básicas de Gerenciamento de Mudanças - níveis de risco
- SLOs de Uptime para Datastores - orçamentos de erro
- Reversão para Migrações Falhas - caminhos reversos
- DDL Sem Tempo de Inatividade - padrões online
Versões da pilha: 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+.