Replication: copiando dados para aumentar disponibilidade e resiliência

O que é replicacao e por que é necessária

O fundamento da alta disponibilidade em bancos de dados

Replicacao 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 servico), escalabilidade de leitura (queries SELECT distribuídas entre múltiplas réplicas) e durabilidade (dados nao perdidos mesmo em falhas catastróficas de hardware ou datacenter). Sem replicacao, um único servidor de banco de dados é um single point of failure que pode derrubar toda a aplicacao. Em sistemas de producao com SLA de 99.9% ou superior, replicacao nao é opcional: é o mecanismo fundamental que torna possível atingir esses níveis de disponibilidade.

Replicacao síncrona vs assíncrona

O trade-off entre durabilidade e desempenho

Na replicacao 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 replicacao 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 configuracoes 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 replicacao 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 ordenacao global das mudancas e ausência de conflitos. Leituras podem ser direcionadas a qualquer follower, distribuindo a carga de queries SELECT. O log de replicacao (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 resolucao

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 é resolucao de conflitos: se dois clientes em regioes diferentes modificam o mesmo registro simultaneamente em leaders diferentes, ambos acreditam que tiveram sucesso, mas as mudancas sao incompatíveis. Estratégias de resolucao incluem: last-write-wins (LWW) baseado em timestamp (simples mas sujeito a dessincronizacao de relógio), resolucao customizada em nível de aplicacao (a aplicacao 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 sao 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 operacao é 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, nao 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 replicacao assíncrona, um cliente pode escrever no leader e imediatamente ler de uma réplica, recebendo o dado antigo porque o lag ainda nao foi resolvido. Esse comportamento, chamado de read-your-writes inconsistency, é um bug sutil que manifesta como "acabei de salvar mas nao aparece". Solucoes 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 replicacao em producao 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

Recuperacao 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 (nao 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 promocao do novo leader, prevenindo split-brain.

Replicacao em MongoDB — replica sets

Alta disponibilidade nativa no MongoDB

MongoDB implementa replicacao via replica sets: um conjunto de nós MongoDB onde um é primary (leader) e os demais sao secondaries (followers). O oplog (operations log) é o mecanismo de replicacao: 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 sao 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 sao a configuracao mínima recomendada em producao: 1 primary + 2 secondaries (ou 1 secondary + 1 arbiter para economizar recurso).

Replicacao em PostgreSQL — WAL streaming

Write-Ahead Log como mecanismo de replicacao

PostgreSQL replica via WAL (Write-Ahead Log) streaming: o standby conecta ao primary via protocolo de replicacao 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 versao 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 versoes 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 configuracao de réplicas usando etcd ou Consul como coordenador de consenso distribuído.

Conclusao — replicacao como base de sistemas confiaveis

Nenhum sistema crítico deve ter banco de dados sem replicacao

Replicacao é a fundacao de qualquer banco de dados em producao que precise de disponibilidade, escalabilidade de leitura e durabilidade. Entender o trade-off entre replicacao 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.