Pular para conteúdo

Administração de Banco de Dados

Instalar é o dia um. Administrar são todos os outros — e é onde o banco silenciosamente deixa de ser confiável: privilégio concedido "temporariamente" há dois anos, réplica parada há três semanas, disco a 92%, versão com CVE conhecida, ALTER TABLE que travou a maior tabela do sistema no horário de pico.

Administração, aqui, é o conjunto de rotinas que impedem cada um desses cenários.

Ciclo de operação do dia a dia: observar, agir por runbook e registrar toda mudança

Toda ação sai de um sinal observado e volta como registro. Nada é resolvido só no terminal.

Rotinas contínuas

Rotina Frequência O que evita
Verificação de replicação e lag Contínua, com alerta Réplica parada descoberta na hora do failover
Verificação de backup e restauração Diária / mensal Backup corrompido descoberto no desastre
Revisão de espaço e crescimento Semanal Disco cheio, que trava escrita e derruba o banco
Revisão de consultas lentas Semanal Degradação gradual até o incidente
Revisão de usuários e privilégios Trimestral Acesso acumulado de quem já saiu
Aplicação de correções de segurança Por janela planejada Exposição a vulnerabilidade conhecida
Simulado de failover Semestral Plano de DR que só existe no papel

Usuários e privilégios

O modelo padrão separa três tipos de conta:

  • Conta de aplicação — privilégio apenas sobre os dados de que precisa (SELECT, INSERT, UPDATE, DELETE no seu esquema). Sem SUPER, sem SUPERUSER, sem DROP de banco.
  • Conta administrativa nominal — uma por pessoa, nunca compartilhada. É o que torna a auditoria útil: root não diz quem fez.
  • Conta de serviço — backup, monitoramento e replicação, cada uma com o mínimo necessário e senha rotacionada.
-- PostgreSQL: papel de aplicação sem privilégio administrativo
CREATE ROLE app_pedidos LOGIN PASSWORD :'senha';
GRANT CONNECT ON DATABASE pedidos TO app_pedidos;
GRANT USAGE ON SCHEMA public TO app_pedidos;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO app_pedidos;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app_pedidos;

Privilégio concedido no incidente precisa ter data para sair

A concessão emergencial é legítima; o que não é legítimo é ela sobreviver ao incidente. Toda concessão temporária entra no registro de mudanças com prazo de revogação.

Mudança de esquema sem parar a aplicação

ALTER TABLE em tabela grande é a causa mais comum de indisponibilidade autoinfligida. Dependendo da versão e da operação, ele reescreve a tabela inteira segurando um lock — e a aplicação para.

O procedimento padrão:

  1. Classificar a operação — algumas são instantâneas (adicionar coluna com valor padrão em versões recentes), outras reescrevem a tabela.
  2. Usar ferramenta online quando reescreve — gh-ost ou pt-online-schema-change no MySQL; no PostgreSQL, o padrão de criar coluna nova, preencher em lotes e trocar.
  3. Índices sem bloqueio — CREATE INDEX CONCURRENTLY no PostgreSQL; criação online no MySQL.
  4. Preencher em lotes — nunca um UPDATE único sobre milhões de linhas: lotes pequenos, com pausa, para não estourar o log de transação nem o lag de replicação.
  5. Compatibilidade nos dois sentidos — o esquema novo precisa funcionar com o código antigo e o código novo, para que deploy e migração de esquema possam ser revertidos separadamente.

Atualização de versão

Tipo Risco Procedimento
Correção (patch) Baixo Réplicas primeiro, depois failover planejado e primário
Versão menor Médio Igual à correção, com teste de regressão de consultas críticas antes
Versão maior Alto Ambiente de teste com cópia real, comparação de plano de execução e, quando possível, migração por replicação lógica com rollback

A ordem é sempre réplica antes do primário: se a versão nova tiver problema, ele aparece em um nó que não atende escrita.

Gestão de capacidade

Três curvas são acompanhadas o tempo todo, com alerta antes do limite, não no limite:

  • Espaço em disco — inclui dados, índices, log de transação e arquivo de log retido. O alerta dispara com folga para agir em horário comercial.
  • Memória e taxa de acerto do cache — queda na taxa de acerto costuma ser o primeiro sinal de que o conjunto ativo passou a não caber em RAM.
  • Conexões — pico de conexões contra o limite configurado; sem pool, uma rajada de tráfego vira too many connections.

Retenção também é capacidade

Tabela de log e histórico crescem para sempre se ninguém definir política. Particionamento por data com descarte de partição antiga é mais barato do que DELETE em massa — e não gera inchaço.

Plantão e runbooks

Cada alerta tem um runbook escrito, com sintoma, verificação, ação e critério de escalonamento. O que está sempre documentado:

  • promoção manual de réplica e fencing do primário antigo;
  • reconstrução de réplica que ficou para trás demais;
  • restauração completa e restauração pontual (point-in-time);
  • resposta a disco cheio, sem apagar o que ainda é necessário para recuperação;
  • encerramento de sessão travada e diagnóstico de bloqueio em cadeia.

Improviso em banco de dados custa dado. O plantão executa procedimento; se o caso não tem procedimento, escala.

Registro de mudanças

Toda alteração relevante — parâmetro, versão, esquema, privilégio, topologia — é registrada com o que mudou, por que, quem aprovou, quanto tempo levou e qual era o rollback. Esse registro é o que permite ligar uma degradação de desempenho de terça-feira à mudança de parâmetro de segunda.

Páginas Relacionadas