Replicação¶
Replicação é a base de quase tudo o que se espera de um banco sério: alta disponibilidade, escala de leitura, migração sem parada, distribuição geográfica e recuperação em outra região. É também o mecanismo que mais silenciosamente se degrada — uma réplica parada há semanas continua respondendo consultas, com dados velhos.
Esta página trata dos mecanismos. As topologias completas por banco estão em MySQL, PostgreSQL e ClickHouse.
A escolha da topologia é uma escolha de RPO e de custo por transação — não uma preferência.
Física ou lógica¶
| Replicação física | Replicação lógica | |
|---|---|---|
| O que trafega | Blocos / registros do log de transação | Linhas alteradas, em nível de operação |
| Fidelidade | Cópia byte a byte do primário | Seletiva: tabelas e colunas escolhidas |
| Versões | Exige a mesma versão maior | Tolera versões diferentes |
| Destino | Somente leitura | Pode receber escrita própria |
| Custo | Menor | Maior, por linha aplicada |
| Uso típico | Alta disponibilidade, standby de failover | Migração, atualização de versão, extração para BI |
Um cluster de produção costuma usar as duas: física para as réplicas de failover, lógica para migrar, atualizar versão ou alimentar um consumidor externo.
Modos de confirmação¶
O modo define o RPO — quanto de dado é aceitável perder.
| Modo | Confirmação do COMMIT | RPO | Custo |
|---|---|---|---|
| Assíncrona | Imediata; o primário não espera a réplica | Segundos de dados em risco | Menor latência de escrita |
| Semi-síncrona / quórum | Após ao menos uma réplica confirmar o recebimento | Próximo de zero | Alguns milissegundos por transação |
| Síncrona estrita | Após a réplica aplicar | Zero | Maior; a réplica entra no caminho crítico |
| Entre regiões | Idem, com réplica na outra região | Próximo de zero, sobrevive à perda de uma região | Latência do enlace metropolitano |
O arranjo mais comum: uma réplica semi-síncrona para garantir o dado e uma réplica assíncrona para leitura e relatório, sem colocar o relatório no caminho crítico da escrita.
Réplica não é backup
Replicação copia fielmente também o erro. Um DROP TABLE no primário chega à réplica em milissegundos. Contra erro humano e corrupção lógica, o que protege é backup com point-in-time recovery.
Topologias¶
- Primário com réplicas — o padrão. Uma origem de escrita, várias de leitura.
- Cascata — uma réplica alimenta outras. Alivia o primário quando há muitos consumidores, ao custo de somar lag em cada salto.
- Entre regiões — réplica em br-sp-1 e br-sp-2, interligadas por links Lan2Lan ou túneis criptografados. Ver MySQL Multi-Região e PostgreSQL Multi-Região.
- Multi-escrita distribuída — sem primário único, com consenso por range. É o modelo do CockroachDB, e resolve escrita local em várias regiões — problema que replicação clássica não resolve.
Direcionamento de leitura¶
Ter réplica não escala leitura sozinho: a aplicação precisa usá-la. O direcionamento fica na camada de proxy, não espalhado pelo código:
- ProxySQL (MySQL) e PgBouncer com endpoints separados (PostgreSQL) expõem
-rwe-ro. - Consultas de relatório e exportação vão sempre para réplica.
- Leitura que exige o dado recém-escrito (read-your-writes) permanece no primário, ou usa mecanismo de espera por posição de replicação.
Lag: o que monitorar¶
Lag é a métrica de saúde da replicação, e precisa de mais de um ângulo:
| Métrica | O que revela |
|---|---|
| Atraso em segundos | A visão do negócio: quão velho é o dado da réplica |
| Distância em bytes / posição do log | Se a réplica está caindo para trás progressivamente |
| Estado dos processos de replicação | Réplica parada por erro — o pior caso, porque o atraso em segundos pode até parecer estável |
| Espaço do log retido no primário | O primário guarda log para réplicas atrasadas; réplica travada pode encher o disco do primário |
Causas frequentes de lag: escrita em lote muito grande no primário, réplica com hardware inferior, aplicação de mudanças em thread única, transação longa aberta na réplica, ou I/O saturado.
Alerta de lag precisa de dois limiares
Um para o atraso aceitável do negócio (por exemplo, 30 segundos) e outro para lag crescente por vários minutos — porque uma réplica que se afasta devagar chega ao ponto de precisar ser reconstruída.
Reconstrução de réplica¶
Quando a réplica fica atrás além do log retido, ou apresenta divergência, ela é reconstruída — não "consertada":
- remover a réplica do direcionamento de leitura;
- recriá-la a partir de backup físico ou snapshot recente;
- retomar a replicação a partir da posição registrada (GTID/LSN);
- esperar o lag zerar;
- verificar consistência por checksum de amostra;
- devolver ao direcionamento de leitura.
Em Kubernetes esse ciclo é conduzido pelo operador; em máquinas virtuais, por script versionado no runbook.
Failover em uma frase¶
Réplica só vale como proteção se a promoção for confiável: detecção com mais de um observador, fencing do primário antigo, promoção da réplica mais avançada e redirecionamento pelo proxy. O detalhamento está em MySQL, PostgreSQL e no plano de recuperação de desastres.
Páginas Relacionadas¶
- Backup e Restauração — O que a replicação não protege
- Recuperação de Desastres — Replicação entre regiões no plano de DR
- Otimização de Desempenho — Escalar leitura sem sobrecarregar o primário
- Migração — Replicação lógica como ferramenta de migração
- MySQL · PostgreSQL · ClickHouse · CockroachDB