Replicação de banco de dados: como manter seus dados em mais de um lugar

Entendendo na Prática

O que é replicação e por que é necessária

O fundamento da alta disponibilidade em bancos de dados

Replicação de banco de dados é o processo de manter cópias sincronizadas dos mesmos dados em múltiplos servidores, distribuídos geograficamente ou no mesmo datacenter. A necessidade é tripla: alta disponibilidade (se o servidor primário falhar, um secundário assume sem perda de serviço), escalabilidade de leitura (queries SELECT distribuídas entre múltiplas réplicas) e durabilidade (dados não perdidos mesmo em falhas catastróficas de hardware ou datacenter). Sem replicação, um único servidor de banco de dados é um single point of failure que pode derrubar toda a aplicação. Em sistemas de produção com SLA de 99.9% ou superior, replicação não é opcional: é o mecanismo fundamental que torna possível atingir esses níveis de disponibilidade.

Replicação síncrona vs assíncrona

O trade-off entre durabilidade e desempenho

Na replicação síncrona, o leader só confirma o write ao cliente após garantir que a réplica também persistiu a mudanca. Isso elimina perda de dados em failover mas aumenta a latência de escrita pelo tempo de ida e volta ao servidor réplica. Na replicação assíncrona, o leader confirma o write imediatamente após salvar localmente e propaga a mudanca para réplicas em segundo plano. Isso oferece latência de escrita mínima mas cria um risco de perda de dados se o leader falhar antes de propagar um write recente. Sistemas como PostgreSQL suportam configurações híbridas: uma réplica síncrona garante durabilidade e múltiplas réplicas assíncronas fornecem capacidade adicional de leitura. A escolha deve equilibrar o SLA de durabilidade com a tolerância a latência de escrita do sistema.

Leader-follower (master-slave) - o modelo mais comum

Um writer, múltiplos readers

O modelo leader-follower é a topologia de replicação mais adotada: um nó leader (primário) aceita todas as escritas, enquanto múltiplos followers (réplicas) recebem um stream de mudancas do leader e as aplicam para manter o estado sincronizado. Todas as escritas fluem obrigatoriamente pelo leader, garantindo ordenação global das mudancas e ausência de conflitos. Leituras podem ser direcionadas a qualquer follower, distribuindo a carga de queries SELECT. O log de replicação (WAL no PostgreSQL, binlog no MySQL) é a fonte de verdade do que foi escrito no leader e o que os followers precisam aplicar. Followers podem estar geograficamente distribuídos para servir usuarios em diferentes regioes com menor latência, tornando o modelo leader-follower a base de bancos de dados multi-região.

Multi-leader replication - conflitos e resolução

Escritas em múltiplos nós simultaneamente

Multi-leader replication permite que múltiplos nós aceitem escritas simultaneamente, eliminando o bottleneck do leader único. Isso é útil quando escritas precisam ocorrer em múltiplos datacenters sem latência de round-trip ao leader centralizado. O desafio fundamental é resolução de conflitos: se dois clientes em regioes diferentes modificam o mesmo registro simultaneamente em leaders diferentes, ambos acreditam que tiveram sucesso, mas as mudancas são incompatíveis. Estratégias de resolução incluem: last-write-wins (LWW) baseado em timestamp (simples mas sujeito a dessincronizacao de relógio), resolução customizada em nível de aplicação (a aplicação define como fundir escritas conflitantes) e CRDT (Conflict-free Replicated Data Types) para estruturas de dados que convergem automaticamente sem conflitos. Multi-leader é raro em bancos relacionais mas comum em banco de dados geo-distribuídos como CockroachDB e Spanner.

Leaderless replication - Cassandra e DynamoDB

Sem nó especial, todos são iguais

Leaderless replication elimina o conceito de leader: qualquer nó pode aceitar escritas, e a consistência é atingida por quorum. O conceito de quorum define que uma operação é bem-sucedida quando W nós de escrita e R nós de leitura respondem, onde W + R > N (total de nós), garantindo que pelo menos um nó na leitura sempre viu a última escrita. Cassandra usa leaderless com consistência tunável: escrever com ConsistencyLevel=QUORUM e ler com ConsistencyLevel=QUORUM garante consistência; escrever com ONE e ler com ONE maximiza disponibilidade com possível leitura de dado desatualizado. DynamoDB da AWS também usa leaderless internamente, expondo consistência eventual por padrao e leitura fortemente consistente como opcao. Leaderless oferece disponibilidade superior: sem leader, não há eleicao de leader que cause downtime durante failover.

Replication lag - dado desatualizado no follower

A consistência eventual na prática

Replication lag é o atraso entre uma escrita no leader e sua propagacao para as réplicas. Em replicação assíncrona, um cliente pode escrever no leader e imediatamente ler de uma réplica, recebendo o dado antigo porque o lag ainda não foi resolvido. Esse comportamento, chamado de read-your-writes inconsistency, é um bug sutil que manifesta como "acabei de salvar mas não aparece". Soluções incluem: direcionar reads do mesmo usuário ao leader logo após uma escrita (read-after-write consistency), usar sessao sticky (mesmo usuário sempre lê da mesma réplica), ou incluir um timestamp mínimo na query para garantir que a réplica aplique dados até aquele ponto. Monitorar o lag de replicação em produção com alertas quando supera um threshold é obrigatório para detectar réplicas atrasadas antes que causem problemas visíveis ao usuário.

Failover automático - promovendo follower a leader

Recuperação sem intervencao manual

Quando o leader falha, o sistema precisa eleger um novo leader entre os followers para restaurar a capacidade de escrita. Failover manual exige intervencao humana, causando downtime de minutos a horas. Failover automático usa protocolos de consenso ou monitoramento externo para detectar falha do leader e promover o follower mais atualizado. Em MySQL, o Group Replication usa Paxos para eleicao automática. PostgreSQL usa ferramentas como Patroni (que coordena via etcd ou ZooKeeper) ou pg_auto_failover. O risco do failover automático é o split-brain: se o leader está lento (não morto) e um follower é promovido, ambos aceitam escritas simultaneamente criando divergência. STONITH (Shoot The Other Node In The Head) é a técnica que força o nó suspeito a se desligar antes da promoção do novo leader, prevenindo split-brain.

Replicação em MongoDB - replica sets

Alta disponibilidade nativa no MongoDB

MongoDB implementa replicação via replica sets: um conjunto de nós MongoDB onde um é primary (leader) e os demais são secondaries (followers). O oplog (operations log) é o mecanismo de replicação: cada escrita no primary é registrada no oplog e replicada de forma assíncrona para os secondaries. Eleicao de novo primary é automática via protocolo baseado em Raft quando o primary fica indisponível, com downtime tipicamente menor que 30 segundos. Read preference configura como reads são distribuídos: primaryPreferred direciona ao primary quando disponível e a um secondary em falha, secondary distribui todas as leituras entre secondaries. Replica sets com 3 membros são a configuração mínima recomendada em produção: 1 primary + 2 secondaries (ou 1 secondary + 1 arbiter para economizar recurso).

Replicação em PostgreSQL - WAL streaming

Write-Ahead Log como mecanismo de replicação

PostgreSQL replica via WAL (Write-Ahead Log) streaming: o standby conecta ao primary via protocolo de replicação e recebe um stream contínuo de registros WAL que aplica em ordem, mantendo o estado sincronizado. Physical replication replica bytes exatos do WAL, mantendo a réplica idêntica ao primary incluindo a versão do PostgreSQL e a estrutura interna. Logical replication replica eventos de mudanca (INSERT, UPDATE, DELETE) a nível de tabela, permitindo replicar seletivamente tabelas específicas, para versões diferentes do PostgreSQL ou até para outros bancos via logical decoding (Debezium usa esse mecanismo para CDC). Patroni é a ferramenta de alta disponibilidade mais adotada para PostgreSQL, gerenciando automaticamente eleicao de leader, failover e configuração de réplicas usando etcd ou Consul como coordenador de consenso distribuído.

Conclusao - replicação como base de sistemas confiaveis

Nenhum sistema crítico deve ter banco de dados sem replicação

Replicação é a fundacao de qualquer banco de dados em produção que precise de disponibilidade, escalabilidade de leitura e durabilidade. Entender o trade-off entre replicação síncrona e assíncrona, replication lag e estratégias de failover é conhecimento obrigatório para qualquer engenheiro que opera banco de dados em sistemas críticos. Continue em: Fundamentos obrigatórios antes de produção.

Replication - Vídeos Essenciais

Replicação de banco de dados explicada

Leader-follower vs leaderless replication

Failover automático - como funciona na prática

MongoDB Replica Sets em produção

PostgreSQL WAL streaming e Patroni

Replication lag - detectar e mitigar