Replicação

Dez minutos antes da abertura das vendas, o banco do catálogo está a 90% de CPU — quase tudo vindo de SELECTs da página do evento. O time adiciona duas réplicas de leitura e direciona as leituras para elas. A CPU cai para 30%. Então o canal de suporte se acende: "Eu paguei, o e-mail de confirmação chegou, mas Meus ingressos está vazio!" Nada se perdeu. A leitura seguinte do fã simplesmente foi para uma réplica que ainda não tinha recebido a escrita.

A replicação — manter uma cópia dos mesmos dados em várias máquinas — é a ferramenta de escalabilidade e disponibilidade mais usada em bancos de dados, e ela vem exatamente com esse tipo de surpresa. Esta página cobre as três formas de replicar (líder único, multilíder e sem líder), o que o atraso de replicação faz com os usuários e o que acontece quando o líder morre.

Por que replicar

A replicação não escala escritas: toda cópia precisa aplicar todas as escritas. Para isso você precisa de particionamento.

Replicação com líder único

Um nó, o líder (primário), aceita todas as escritas. Ele registra cada mudança no seu log — o write-ahead log (WAL) no PostgreSQL, o binlog no MySQL — e envia o log para os seguidores (réplicas, standbys), que o reaplicam na mesma ordem. As leituras podem ir para qualquer nó¹.

flowchart LR
    app["serviço catalog"] -->|"escritas"| P[("primário")]
    P -->|"fluxo de WAL"| R1[("réplica 1")]
    P -->|"fluxo de WAL"| R2[("réplica 2")]
    app -->|"leituras"| R1
    app -->|"leituras"| R2
    app -->|"leituras que precisam ser atuais"| P

Esse é o modelo da streaming replication do PostgreSQL, da replicação do MySQL, do SQL Server Always On, dos replica sets do MongoDB e da maioria dos serviços gerenciados (réplicas de leitura do Amazon RDS, Cloud SQL, Azure Database). É simples de raciocinar porque existe exatamente uma ordem de escritas — a do líder.

Síncrona, assíncrona, semissíncrona

A decisão-chave é quando o líder diz ao cliente "confirmado":

sequenceDiagram
    participant C as Cliente
    participant P as Primário
    participant S as Standby síncrono
    participant A as Réplica assíncrona
    C->>P: COMMIT da reserva A-12
    P->>P: grava o WAL localmente
    P->>S: envia o WAL
    S-->>P: gravado em disco
    P-->>C: confirmado
    P->>A: envia o WAL (depois)
    Note over A: pode ficar ms … s atrás

No PostgreSQL, isso são as configurações synchronous_commit e synchronous_standby_names⁵; ANY 1 (s1, s2) significa "espere qualquer um dos dois standbys" — um quorum que tolera um standby lento. Dentro de uma região, uma ida e volta síncrona custa cerca de um milissegundo; entre continentes custa de dezenas a centenas de milissegundos, e é por isso que réplicas entre regiões são quase sempre assíncronas.

Atraso de replicação e suas anomalias

Uma réplica assíncrona fica atrás do líder pelo atraso de replicação (replication lag): normalmente milissegundos, mas segundos ou minutos quando o líder recebe uma rajada de escritas, uma réplica reaplica uma transação enorme ou a rede está congestionada. O atraso cria três anomalias visíveis para o usuário²:

sequenceDiagram
    participant F as Fã
    participant O as serviço order
    participant P as Primário
    participant R as Réplica (atraso de 800 ms)
    F->>O: POST /orders/9001/confirm
    O->>P: UPDATE orders SET status = 'PAID'
    P-->>O: confirmado
    O-->>F: 200 "Pagamento confirmado"
    F->>O: GET /me/tickets
    O->>R: SELECT … WHERE customer_id = 7
    R-->>O: (ainda nenhuma linha)
    O-->>F: "Você não tem ingressos"

Qual a chance de isso acontecer? Num modelo ilustrativo — atraso distribuído exponencialmente em torno de uma média, e o próximo clique do fã indo para uma réplica — a resposta depende inteiramente do atraso naquele momento:

Num dia tranquilo o bug é invisível; durante a abertura das vendas — justamente quando há mais fãs olhando — a maioria deles esbarra nele. É por isso que bugs de atraso sobrevivem aos testes.

Corrigindo o read-your-writes

Monitore o atraso como métrica de primeira classe — pg_stat_replication.replay_lag no PostgreSQL, ReplicaLag no Amazon RDS — e crie alertas sobre ele (veja Observabilidade). Uma réplica minutos atrás é pior do que nenhuma réplica.

/**
 * Two connection pools — primary and replica — behind one DataSource.
 * A transaction marked @Transactional(readOnly = true) gets a replica connection;
 * every other transaction gets a primary connection. The choice happens when the
 * transaction runs its first statement (that is what "lazy" means here).
 */
@Configuration
public class DataSourceConfig {

    @Bean
    @ConfigurationProperties("inventory.datasource.primary")
    HikariDataSource primaryDataSource() {
        return new HikariDataSource();
    }

    @Bean
    @ConfigurationProperties("inventory.datasource.replica")
    HikariDataSource replicaDataSource() {
        return new HikariDataSource();
    }

    @Bean
    @Primary
    DataSource dataSource(HikariDataSource primaryDataSource, HikariDataSource replicaDataSource) {
        var routing = new LazyConnectionDataSourceProxy(primaryDataSource);
        routing.setReadOnlyDataSource(replicaDataSource);     // Spring Framework 6.2+
        return routing;
    }

Experimente. No cenário db-replicas, um primário recebe as escritas e as réplicas atendem as leituras. Adicione réplicas e veja a vazão de leitura subir enquanto a carga do primário fica estável; depois aumente a taxa de escrita e veja o atraso de replicação crescer — e, com ele, a fração de leituras desatualizadas.

Pool de conexões

As réplicas multiplicam para onde as consultas podem ir; os pools de conexões decidem quantas podem rodar ao mesmo tempo. No PostgreSQL, cada conexão é um processo separado do sistema operacional, com memória própria; milhares de conexões ociosas custam RAM e CPU de verdade — e o banco não fica mais rápido além de algumas poucas consultas concorrentes por núcleo de CPU.

Dimensione os pools com a Lei de Little, não no chute: conexões ocupadas = consultas por segundo × tempo de consulta. Com 2.000 consultas/s × 5 ms = 10 conexões ocupadas em média. Um pool de 20–30 absorve as rajadas; um pool de 500 só acrescenta contenção.

O problema nos microsserviços: 20 pods × um pool de 50 = 1.000 conexões num único primário. Um pooler de conexões como o PgBouncer (ou o RDS Proxy, ou o Cloud SQL Auth Proxy com pooling) fica entre eles, multiplexando milhares de conexões de clientes em poucas dezenas de conexões com o servidor. No modo transaction pooling, uma conexão com o servidor é emprestada por transação, então o estado de sessão (SET, tabelas temporárias, alguns usos de prepared statements) não pode vazar de uma transação para outra. Você vai medir isso no Hands-on 6.

; transaction pooling: a server connection is lent for ONE transaction, then returned
pool_mode = transaction
; real connections to PostgreSQL per (database, user) pair
default_pool_size = 20
; client connections PgBouncer accepts (all services and replicas together)
max_client_conn = 1000

Failover: quando o líder morre

Se um seguidor morre, ele se reconecta e alcança o líder a partir do log. Se o líder morre, o sistema precisa fazer failover:

sequenceDiagram
    participant M as Gerenciador de failover (ex.: Patroni + etcd)
    participant P as Primário antigo
    participant S as Standby
    participant A as Aplicações
    M->>P: health check
    Note over P: sem resposta por 10 s
    M->>S: promove a primário
    S-->>M: promovido (nova timeline)
    M->>A: atualiza DNS / IP virtual / proxy
    A->>S: escritas retomadas
    Note over P: se voltar, precisa ser isolado (fencing)<br/>e reentrar como seguidor

Cada passo esconde um problema difícil:

• A detecção usa timeouts. Curto demais: uma pausa de GC ou um soluço de rede dispara um failover desnecessário. Longo demais: minutos sem escritas.
• Escritas perdidas. Com replicação assíncrona, as escritas confirmadas pelo líder antigo mas ainda não enviadas desaparecem. Se eram reservas de assentos, o novo primário pode vender os mesmos assentos de novo.
• Split brain. Se o líder antigo estava apenas particionado, e não morto, dois nós podem aceitar escritas. Os sistemas evitam isso com consenso sobre quem é o líder (o Patroni guarda a chave do líder no etcd; veja Consenso) e com fencing: o líder antigo é isolado (STONITH, "shoot the other node in the head") ou suas escritas são rejeitadas por fencing tokens.
• Os clientes precisam acompanhar. Por DNS, IP virtual, proxy ou um driver que conhece a topologia.

Os serviços gerenciados empacotam tudo isso — Amazon RDS Multi-AZ com standby síncrono, Aurora com armazenamento em quorum, alta disponibilidade do Cloud SQL, HA com redundância de zona no Azure — com failovers que costumam levar de dezenas de segundos a alguns minutos; a pergunta de design para você é o que a aplicação faz enquanto isso (novas tentativas com backoff, veja Confiabilidade).

# pg_rewind copies back only the blocks that changed since the timelines split,
# discarding the writes the old primary made that never reached the new one.
pg_rewind --target-pgdata="$PGDATA" --progress \
  --source-server="host=$NEW_PRIMARY user=$POSTGRES_USER password=$POSTGRES_PASSWORD dbname=$POSTGRES_DB"

# Same as pg_basebackup -R: start as a standby, streaming from the new primary.
touch "$PGDATA/standby.signal"
echo "primary_conninfo = 'host=$NEW_PRIMARY user=replicator password=${REPLICATION_PASSWORD:-replicator}'" \
  >> "$PGDATA/postgresql.auto.conf"

Experimente. O cenário db-failover é um checkout de venda relâmpago num cluster com um primário e um seguidor assíncrono: 1.500 req/s, metade escritas. Em t = 90 s o primário morre. Execute-o e leia o relatório: com a semente padrão cerca de 1.600 escritas se perdem (confirmadas pelo primário antigo, nunca enviadas ao seguidor) e a disponibilidade cai para cerca de 90,6%, porque toda escrita falha durante os 30 s de failover. Selecione orders-db e mude Replicação para sync: as escritas perdidas caem para 0, mas a disponibilidade não se mexe. Volte para async e ponha o Tempo de failover em 5 s: a disponibilidade sobe para cerca de 98%, e as escritas voltam a se perder. Os dois controles respondem a perguntas diferentes: o modo de replicação define quanto você perde (o RPO), a detecção e a promoção definem quanto tempo você fica fora (o RTO). A solução possível (abra no playground completo ↗) combina replicação por quórum com 2 seguidores, 2 shards e failover de 5 s: 0 escritas perdidas, cerca de 99,2% de disponibilidade.

Replicação multilíder

Na replicação multilíder (multi-leader, multi-primary, ativo-ativo), vários nós aceitam escritas e replicam entre si de forma assíncrona. Motivos típicos: um líder por região, para que as escritas sejam locais; clientes offline-first (um app móvel ou um editor colaborativo é, na prática, um líder); um segundo data center que precisa aceitar escritas durante uma partição.

O preço são os conflitos de escrita: dois líderes aceitam escritas diferentes no mesmo registro ao mesmo tempo.

Replicação sem líder

O artigo do Dynamo da Amazon (2007)³ popularizou um terceiro design, usado por Cassandra, ScyllaDB e Riak: nenhum líder. O cliente (ou um nó coordenador) envia cada escrita para todas as N réplicas de uma chave e a considera bem-sucedida quando W delas confirmam; lê de R réplicas e fica com a versão mais nova.

Se R + W > N, todo conjunto de leitura se sobrepõe a todo conjunto de escrita em pelo menos uma réplica, então uma leitura vê a última escrita confirmada (com ressalvas sob escritas concorrentes e falhas — quoruns sozinhos não são linearizáveis). Com N = 3:

As escritas perdidas são reparadas por read repair (uma leitura que vê uma versão antiga grava a nova de volta), hinted handoff (um vizinho guarda as escritas de um nó fora do ar e as reaplica depois; com um sloppy quorum, esses guardiões temporários até contam para W) e anti-entropia (comparação em segundo plano entre réplicas com árvores de Merkle). O Cassandra expõe a escolha por consulta como níveis de consistência ONE, QUORUM, LOCAL_QUORUM, ALL.

Comparando os designs

Como se conecta

flowchart LR
    WHY["por que replicar: disponibilidade,<br/>escala de leitura, latência"] --> SL["líder único"]
    SL --> SYNC["síncrona vs assíncrona<br/>durabilidade vs latência do commit"]
    SL --> LAG["atraso de replicação"]
    LAG --> RYW["ler as próprias escritas,<br/>leituras monotônicas"]
    RYW -.-> CM["modelos de consistência<br/>→ Distribuídos"]
    SL --> FO["failover: Patroni + etcd<br/>→ Consenso distribuído"]
    SL --> POOL["pool de conexões<br/>PgBouncer"]
    WHY --> ML["multilíder<br/>conflitos, LWW"]
    WHY --> LL["sem líder<br/>R + W > N"]
    LL --> PART["armazenamentos particionados<br/>→ Particionamento"]

Componentes da paleta: sql (um primário com réplicas de leitura; um standby síncrono para assentos e dinheiro) · nosql (quóruns sem líder: Cassandra, DynamoDB) · app (roteia leituras e escritas, faz retry com backoff durante um failover) · cache (fica na frente das réplicas do catálogo) · dns (um jeito de os clientes seguirem o novo líder). Cenários: db-replicas, db-failover, multi-region. Continua em: Particionamento, Distribuídos — consistência, Distribuídos — consenso, Confiabilidade — recuperação de desastres, Hands-on 6 (réplica de leitura, PgBouncer), Exercício: cache + banco.