Pular para conteúdo

Instalação de Banco de Dados

Quase todo problema grave de banco em produção nasce na instalação: storage errado, memória mal distribuída, réplicas no mesmo host físico, nenhum teste de falha antes do primeiro cliente. Corrigir depois custa janela de manutenção; acertar antes custa uma conversa.

Esta página descreve como a InteSys instala um banco novo — do dimensionamento até a entrega documentada.

Etapas de provisionamento: dimensionamento, topologia, deploy por IaC, hardening e validação, com o que é sempre entregue e o que nunca é dispensado

Nenhuma etapa é pulada, mesmo em cluster pequeno — o que muda é o tamanho, não o procedimento.

1. Dimensionamento

Dimensionamento não é escolher um plano; é responder a cinco perguntas.

Pergunta Por que decide a máquina
Qual o volume de dados hoje e a projeção de 24 meses? Define disco e, principalmente, quanto do conjunto ativo cabe em RAM
Qual a proporção entre leitura e escrita? Carga de leitura escala com réplicas; escrita escala com hardware e esquema
Qual o pico de conexões simultâneas? Determina o pool e evita que o banco morra de too many connections
Qual a maior transação e a maior consulta analítica? Define memória de trabalho e o risco de uma consulta derrubar o servidor
Qual RPO e RTO o negócio aceita? Define o modo de replicação e a política de backup

Regra prática de memória — o conjunto de dados quente deve caber no cache do banco (buffer pool no MySQL, shared buffers + cache do sistema operacional no PostgreSQL). Quando não cabe, cada consulta vira I/O e nenhum ajuste de parâmetro salva.

Storage é onde mais se erra

Banco de dados é sensível a latência de I/O, não a throughput de disco. Um volume com bom número de MB/s e latência ruim entrega desempenho pior que um disco menor e mais rápido. Toda instalação da InteSys mede latência de escrita e IOPS do volume antes de subir o banco.

2. Topologia

A decisão anterior a qualquer instalação: Kubernetes ou máquinas virtuais.

Critério Kubernetes Máquinas virtuais
Provisionamento de um novo cluster Minutos, declarativo Automatizado, porém mais lento
Reconstrução de réplica Automática, pelo operador Automatizada com scripts
Ajuste fino de kernel, I/O scheduler e huge pages Limitado pelo nó Total
Familiaridade da equipe do cliente Exige cultura Kubernetes Operação tradicional
Indicado quando A aplicação já roda em Kubernetes O banco é o componente mais crítico e isolado

Os detalhes de cada arranjo estão nos guias de alta disponibilidade: MySQL, PostgreSQL, ClickHouse.

Número de nós — a instalação padrão tem três nós de banco (ou três votantes, quando o consenso é externo). Dois nós não formam quórum e transformam qualquer partição de rede em decisão manual.

3. Provisionamento

Nada é instalado à mão.

  • Infraestrutura como Código — Terraform para os recursos, Ansible ou operador Kubernetes para o banco. O cluster é reprodutível a partir do repositório.
  • Anti-affinity obrigatória — um nó de banco por host físico. Três réplicas no mesmo hipervisor não são alta disponibilidade, são uma cópia triplicada do mesmo ponto de falha.
  • Volumes dedicados — dados, log de transação e sistema operacional em volumes separados, com o log de transação em armazenamento de baixa latência.
  • Versão fixada — versão maior e menor declaradas explicitamente; atualização é evento planejado, nunca efeito colateral de um restart.
# Trecho ilustrativo de manifesto — a topologia é declarada, não digitada no servidor
spec:
  instances: 3
  postgresql:
    parameters:
      shared_buffers: "8GB"
      max_connections: "200"
  storage:
    size: 500Gi
    storageClass: fast-nvme
  backup:
    retentionPolicy: "30d"

4. Hardening

Um banco recém-instalado é um alvo. O padrão de entrega inclui:

  • TLS obrigatório — conexões de aplicação e de replicação cifradas; certificado gerenciado e rotacionado.
  • Sem exposição pública — o banco escuta em rede privada. Acesso administrativo passa por bastion ou VPN, nunca por porta aberta na internet.
  • Contas mínimas — usuário da aplicação com privilégio de dados, sem SUPER/SUPERUSER; contas administrativas separadas e nominais.
  • Senhas fora do código — credenciais em Kubernetes Secret ou cofre, injetadas por variável de ambiente.
  • Network policy / firewall — apenas as origens previstas alcançam a porta do banco.
  • Auditoria de conexão — registro de quem conectou, de onde e quando.
  • Criptografia em repouso — volumes criptografados, incluindo os usados por snapshot.

5. Validação antes do go-live

Um cluster só é entregue depois de provar que funciona sob estresse e sob falha.

  1. Teste de carga — carga sintética no perfil real da aplicação, medindo latência de p95 e p99, não média.
  2. Teste de falha — derrubamos o primário em ambiente controlado e medimos o RTO real. Se o número não bate com o acordado, a topologia muda antes da produção.
  3. Teste de restauração — o primeiro backup é restaurado em um servidor limpo e conferido. Backup nunca restaurado não conta.
  4. Verificação de alertas — cada alerta é disparado artificialmente uma vez, para confirmar que chega a quem está de plantão.

O que é entregue junto

Entregável Conteúdo
Documento de topologia Nós, papéis, endpoints, versões e parâmetros relevantes
Runbook Failover, reconstrução de réplica, restauração, escalonamento
Painéis e alertas Métricas de replicação, conexões, latência, espaço em disco
Política de backup Frequência, retenção, destino e resultado do último teste de restauração
Credenciais Entregues por canal seguro, com contas nominais para o time do cliente

Instalação e migração andam juntas

Se o banco já existe em outro lugar, a instalação é a primeira metade do trabalho e a migração é a segunda. O cluster novo é validado antes de qualquer dado de produção ser copiado.

Páginas Relacionadas