Master-Slave (Replica de Leitura)

A replicação do tipo master-slave é o modelo clássico em que um nó de banco de dados, o primário, concentra todas as escritas, enquanto um ou mais nós espelhos, as réplicas de leitura, mantêm uma cópia quase sincronizada dos dados. Cada transação confirmada no primário é propagada para as réplicas por um fluxo contínuo de alterações, seja como stream de bytes do log transacional, seja como eventos lógicos por tabela. O termo master-slave ainda aparece em documentações antigas, mas a indústria migrou para primário e réplica (primary e replica), terminologia adotada pelos principais SGBDs e provedores de nuvem. Esse arranjo é a fundação da escala de leitura em produção: réplicas absorvem consultas que de outro modo competiriam com transações de negócio no primário. É igualmente a base da alta disponibilidade, pois uma réplica íntegra pode ser promovida a primário após uma falha. Qualquer sistema com tráfego relevante de leitura eventualmente precisa dominar esse modelo e seus efeitos colaterais de consistência.

Conceito e terminologia atual

O primário (master, primary ou writer) é o único nó que aceita INSERT, UPDATE e DELETE; ele registra cada alteração no log de escrita antes de confirmar a transação ao cliente. As réplicas (slave, standby, read replica ou reader) aplicam esse log na mesma ordem, reproduzindo as mudanças sem aceitar conexões de escrita. A ordem de aplicação é preservada, o que garante que cada réplica percorra o mesmo histórico de transações, ainda que com atraso variável ao longo do tempo.

A troca de terminologia não é cosmética, pois nomes carregam contrato. Falar de primário e réplica deixa claro que papéis são transitórios, já que uma réplica pode se tornar primária em um failover. Termos modernos reforçam o papel: no Aurora fala-se de writer e reader, no SQL Server de principal e secundário, no patroni de leader e replica.

• Primário: fonte da verdade transacional, gera o log de alterações e coordena a confirmação de cada transação.
• Réplica: cópia somente leitura que aplica o log do primário, usada para consultas, relatórios e backups consistentes.
• Promoção: operação que transforma uma réplica em primário, encerrando sua dependência do nó original.
• Lag (defasagem): intervalo entre uma escrita confirmada no primário e sua aplicação efetiva na réplica.

O problema que resolve

Bancos relacionais têm dificuldade histórica em escalar leitura em um único nó. Consultas analíticas pesadas, relatórios administrativos e leituras de alto volume disputam os mesmos buffers, locks e capacidade de I/O das transações críticas de negócio. Em picos, um relatório mal planejado pode degradar o checkout de um e-commerce porque ambos brigam pelo mesmo disco e pelo mesmo pool de conexões.

A replicação resolve esse conflito movendo leituras para nós dedicados. O primário fica livre para o caminho transacional, e cada réplica serve um perfil distinto de consulta. A réplica funciona ainda como backup quente: como contém os dados em tempo quase real, é o ponto de partida natural para dumps consistentes e para recuperação de desastres, sem tocar em tabelas do primário.

Há um segundo benefício menos visível: o isolamento de falhas de consulta. Uma instrução mal escrita que gera varredura completa mata o desempenho de uma réplica, mas deixa o primário transacional intacto; na direção oposta, a queda de uma réplica reduz capacidade de leitura sem interromper vendas. Esse confinamento de dano é razão suficiente, em muitos projetos, para adicionar a primeira réplica mesmo sem pressão de escala.

Funcionamento interno

O ciclo básico tem três etapas encadeadas. Primeiro, o primário grava as alterações no log de escrita (WAL no PostgreSQL, binlog no MySQL) antes de confirmar a transação. Segundo, um processo de envio (walsender no PostgreSQL, dump thread no MySQL) transmite esse log pela rede para cada réplica conectada. Terceiro, cada réplica recebe o fluxo, persiste localmente e aplica as mudanças, mantendo-se um passo atrás do primário em intervalos que variam de milissegundos a segundos.

# PostgreSQL: parâmetros mínimos no primário para habilitar streaming replication
listen_addresses = '*'          # aceita conexões das réplicas na rede interna
wal_level = replica             # gera log suficiente para réplicas físicas
max_wal_senders = 5             # processos que transmitem WAL, um por réplica
wal_keep_size = 1GB             # WAL retido para réplicas atrasadas se recuperarem

# pg_hba.conf: autoriza o usuário de replicação a receber o stream de WAL
# host replication replicador 10.0.0.0/16 scram-sha-256

Na réplica, a configuração aponta para o primário e libera consultas durante a aplicação do log:

# PostgreSQL: arquivo standby.signal marca o papel de réplica
# e primary_conninfo define o destino do stream
primary_conninfo = 'host=10.0.0.10 port=5432 user=replicador password=***'
hot_standby = on                # permite consultas enquanto o log é aplicado

A verificação de saúde é leitura direta das views de sistema, base de qualquer monitoramento:

-- No primário: estado de cada réplica conectada
SELECT client_addr, state, sync_state,
       replay_lag AS atraso_de_aplicacao
FROM pg_stat_replication;

-- Na réplica: quanto tempo falta para alcançar o primário
SELECT now() - pg_last_xact_replay_timestamp() AS defasagem;

Replicação física versus lógica

Os dois grandes mecanismos produzem resultados parecidos com custos bem diferentes. A replicação física copia o log de blocos de disco byte a byte, exigindo que a réplica tenha a mesma versão e arquitetura do primário; em contrapartida, reproduz fielmente qualquer operação, incluindo DDL. A replicação lógica decodifica o log em eventos por tabela, permitindo réplicas em versões diferentes, seleção de tabelas e até escritas locais na réplica, ao preço de não replicar DDL automaticamente e de consumir mais processamento no primário.

No PostgreSQL as duas coexistem: réplicas físicas servem escala de leitura e alta disponibilidade, enquanto a replicação lógica atende migrações online e pipelines de CDC. No MySQL, o binlog já é um log lógico por linha ou por instrução, e o GTID identifica unicamente cada transação no cluster.

Replication lag e leitura defasada

Replication lag é o atraso entre a confirmação da escrita no primário e sua aplicação na réplica; ele é inevitável na replicação assíncrona e oscila com a carga. Causas típicas incluem consultas longas na réplica bloqueando a aplicação do log, hardware inferior ao do primário, largura de banda saturada entre nós e picos de escrita que superam a taxa de aplicação. A consequência direta é a leitura defasada: um cliente que escreve no primário e consulta imediatamente uma réplica pode não ver o próprio dado.

Esse efeito é aceitável para listagens, dashboards e conteúdo onde segundos de defasagem não causam dano percebido. Para fluxos sensíveis, como confirmação de pedido ou atualização de cadastro, o sistema precisa de estratégias explícitas, detalhadas no arquivo de roteamento de consultas deste módulo. Monitorar o lag é obrigatório: sem a métrica, o roteamento decide no escuro e os bugs de consistência aparecem como relatos intermitentes de usuários.

Sincronia versus assincronia

Na replicação síncrona, o primário confirma a transação somente depois que ao menos uma réplica informou ter gravado o dado. O ganho é a eliminação de perda de transações confirmadas em caso de falha do primário; o custo é latência extra em cada commit e o risco de bloqueio total das escritas se a réplica sincronizada ficar indisponível. Na replicação assíncrona, o primário confirma imediatamente e envia o log depois; o throughput é alto e a falha da réplica não afeta escritas, mas uma queda súbita pode perder transações ainda não transmitidas.

A escolha é um trade-off direto entre durabilidade e latência, e a maioria dos sistemas de produção opera assíncrono com monitoramento rigoroso do lag. O PostgreSQL oferece modos intermediários de synchronous_commit, do remote_write ao on_apply, e o MySQL apresenta o semisync, em que o primário aguarda apenas o recebimento do evento pela réplica, sem exigir sua aplicação completa.

Aplicação prática: escrita no primário, leitura nas réplicas

Em produção, a regra de consumo é simples de enunciar e exigente de operar: tudo que escreve vai ao primário, tudo que apenas lê pode ir a uma réplica. Pools de conexão nomeados por papel, configuração de ORM e endpoints distintos materializam a separação, e cada serviço escolhe o alvo por operação e não por configuração global estática. A divisão de trabalho usual segue este formato:

• Réplicas servem listagens, dashboards, buscas e leituras de sessão tolerantes a segundos de defasagem.
• O primário reserva-se a transações de negócio, checagens de unicidade e leituras imediatamente seguidas de escrita.
• Relatórios pesados ganham réplica dedicada, isolando consultas longas do tráfego interativo.
• Backups físicos e dumps lógicos são extraídos de réplicas para não penalizar o primário em horário comercial.

A decisão de qual réplica atender cada consulta também é parte da aplicação prática. Réplicas por região aproximam os dados do usuário final e reduzem latência de rede; réplicas por perfil separam carga interativa de carga analítica; e a contagem mínima de duas réplicas garante que a manutenção de uma delas não devolva todo o tráfego de leitura ao primário.

Failover manual

No modelo master-slave puro, a promoção de uma réplica a primário é decisão do operador ou de um orquestrador externo, não um comportamento autônomo da réplica. Quando o primário falha, o fluxo típico escolhe a réplica mais avançada no log, executa a promoção, redireciona as conexões dos serviços e valida o novo nó. Ferramentas como Patroni, repmgr e MHA automatizam etapas, mas o conceito permanece: alguém decide e executa a troca de papel.

O risco central é o split brain, cenário em que o primário antigo volta à operação e continua aceitando escritas enquanto a réplica promovida também o faz, gerando divergências de dados quase impossíveis de reconciliar. As mitigações clássicas são o fencing do nó antigo, que o isola ou desliga antes da promoção, e a recuperação posterior do antigo primário como réplica da nova fonte, com rewind quando necessário.

# Promoção manual de uma réplica no PostgreSQL 16
pg_ctl promote -D /var/lib/postgresql/16/main   # a réplica assume o papel de primário
# Após a promoção: apontar as aplicações para o novo endpoint,
# isolar o nó antigo e reprovisioná-lo como réplica

Erros comuns e boas práticas

• Erro: enviar leitura crítica para a réplica sem considerar o lag, gerando o relato clássico de usuário que escreve e não vê o próprio dado; prática: leitura pós-escrita direcionada ao primário ou espera pelo marcador de transação.
• Erro: abrir exceção de escrita na réplica física durante testes, quebrando a replicação de forma silenciosa; prática: réplica é somente leitura por contrato, inclusive para o DBA.
• Erro: operar sem monitoramento do lag, descobrindo defasagem crescente por reclamação de cliente; prática: alarme em replay_lag e em atraso de aplicação, com remoção automática da réplica do roteamento acima do limite.
• Erro: dimensionar réplicas com hardware inferior ao do primário; elas acumulam defasagem exatamente nos picos em que são mais necessárias; prática: réplicas de tamanho igual ou superior ao primário.
• Erro: promover réplicas sem runbook ensaiado; a promoção de emergência revela autenticação pendente, backup desatualizado e DNS esquecido; prática: teste periódico de failover em janela controlada.

As boas práticas concentram-se em três vigilâncias permanentes: lag, integridade e promoção. O lag define se as réplicas são utilizáveis para cada perfil de consulta; a integridade confirma que o stream não parou silenciosamente; a promoção é o ensaio do plano B de recuperação. Com esses três pontos instrumentados, o modelo primário e réplica entrega escala de leitura previsível e um caminho de recuperação confiável.