Entenda por que réplicas de leitura existem, quais problemas resolvem e quando ajudam (ou atrapalham). Inclui casos de uso comuns, limites e dicas práticas para decidir.
Uma réplica de leitura é uma cópia do seu banco de dados principal (frequentemente chamado de primário) que se mantém atualizada recebendo mudanças continuamente. Sua aplicação pode enviar consultas somente de leitura (como SELECT) para a réplica, enquanto o primário continua a processar todas as gravações (como INSERT, UPDATE e DELETE).
A promessa é simples: mais capacidade de leitura sem aumentar a pressão sobre o primário.
Se seu app tem muito tráfego de “buscar” — páginas iniciais, páginas de produto, perfis de usuário, dashboards — mover parte dessas leituras para uma ou mais réplicas pode liberar o primário para focar nas gravações e nas leituras críticas. Em muitas configurações, isso exige mudanças mínimas na aplicação: você mantém um banco como fonte de verdade e adiciona réplicas como lugares adicionais para consultar.
Réplicas de leitura são úteis, mas não são um botão mágico de desempenho. Elas não:
Pense em réplicas como uma ferramenta de escala de leitura com trade-offs. O resto deste artigo explica quando elas realmente ajudam, as formas mais comuns pelas quais falham, e como conceitos como lag de replicação e consistência eventual afetam o que os usuários veem quando você começa a ler de uma cópia em vez do primário.
Um único servidor de banco de dados primário frequentemente começa parecendo “grande o suficiente”. Ele processa gravações (inserções, atualizações, deleções) e também responde a todas as requisições de leitura (SELECT) da sua aplicação, dashboards e ferramentas internas.
Conforme o uso cresce, leituras geralmente se multiplicam mais rápido que gravações: cada visualização de página pode disparar várias consultas, telas de busca podem se desdobrar em muitas buscas, e consultas analíticas podem varrer muitas linhas. Mesmo se o volume de gravação for moderado, o primário ainda pode se tornar um gargalo porque precisa fazer duas tarefas ao mesmo tempo: aceitar mudanças com segurança e rapidez, e servir um volume de leitura crescente com baixa latência.
Réplicas de leitura existem para dividir esse trabalho. O primário fica focado em processar gravações e manter a “fonte da verdade”, enquanto uma ou mais réplicas lidam com consultas somente de leitura. Quando sua aplicação consegue rotear algumas consultas para réplicas, você reduz a pressão de CPU, memória e I/O no primário. Isso normalmente melhora a capacidade de resposta geral e deixa mais margem para picos de gravação.
Replicação é o mecanismo que mantém réplicas atualizadas copiando mudanças do primário para outros servidores. O primário registra mudanças, e as réplicas aplicam essas mudanças para poderem responder consultas usando dados quase idênticos.
Esse padrão é comum em vários sistemas de banco de dados e serviços gerenciados (por exemplo PostgreSQL, MySQL e variantes em nuvem). A implementação exata difere, mas o objetivo é o mesmo: aumentar a capacidade de leitura sem forçar o primário a escalar verticalmente para sempre.
Pense no banco primário como a “fonte da verdade”. Ele aceita cada gravação — criando pedidos, atualizando perfis, registrando pagamentos — e atribui uma ordem definida a essas mudanças.
Uma ou mais réplicas então seguem o primário, copiando essas mudanças para poderem responder consultas de leitura (como “mostre meu histórico de pedidos”) sem colocar mais carga no primário.
Leituras podem ser servidas pelas réplicas, mas gravações continuam indo ao primário.
A replicação pode ocorrer em dois modos amplos:
Esse atraso — réplicas ficando atrás do primário — é chamado de lag de replicação. Não é automaticamente uma falha; muitas vezes é o trade-off normal que você aceita para escalar leituras.
Para o usuário final, o lag aparece como consistência eventual: depois que você muda algo, o sistema ficará consistente em todos os lugares, mas não necessariamente instantaneamente.
Exemplo: você atualiza seu endereço de e-mail e atualiza a página de perfil. Se a página for servida por uma réplica que está alguns segundos atrás, você pode ver temporariamente o e-mail antigo — até a réplica aplicar a atualização e “alcançar” o primário.
Réplicas de leitura ajudam quando seu banco primário está saudável para gravações mas fica sobrecarregado atendendo tráfego de leitura. Elas são mais eficazes quando você pode descarregar uma parcela relevante do SELECT sem mudar como você grava dados.
Procure padrões como:
SELECT comparada a INSERT/UPDATE/DELETEAntes de adicionar réplicas, valide com alguns sinais concretos:
SELECT (do slow query log/APM).Frequentemente, o melhor primeiro passo é ajustar: adicionar o índice certo, reescrever uma consulta, reduzir chamadas N+1 ou cachear leituras quentes. Essas mudanças podem ser mais rápidas e mais baratas do que operar réplicas.
Escolha réplicas se:
Escolha ajuste primeiro se:
Réplicas de leitura são mais valiosas quando o primário lida com gravações (checkouts, cadastros, atualizações), mas uma grande parcela do tráfego é intensiva em leitura. Numa arquitetura primário–réplica, direcionar as consultas corretas para réplicas melhora o desempenho sem mudar funcionalidades da aplicação.
Dashboards costumam executar consultas longas: agrupamentos, filtros em grandes intervalos, ou junções múltiplas. Essas consultas competem com trabalho transacional por CPU, memória e cache.
Uma réplica de leitura é um bom lugar para:
Você mantém o primário focado em transações rápidas e previsíveis enquanto as leituras analíticas escalam de forma independente.
Navegação de catálogo, perfis de usuários e feeds de conteúdo podem gerar um alto volume de consultas semelhantes. Quando essa pressão de escala de leitura é o gargalo, réplicas podem absorver tráfego e reduzir picos de latência.
Isso é especialmente eficaz quando leituras têm muitos misses de cache (muitas consultas únicas) ou quando não dá para confiar apenas no cache da aplicação.
Exportações, backfills, recomputação de resumos e jobs tipo “encontre todos os registros que batem X” podem causar thrash no primário. Executar essas varreduras numa réplica costuma ser mais seguro.
Apenas garanta que o job tolere consistência eventual: com lag de replicação, ele pode não ver as atualizações mais recentes.
Se você atende usuários globalmente, posicionar réplicas mais perto deles pode reduzir o tempo de ida e volta. O trade-off é maior exposição a leituras obsoletas durante lag ou problemas de rede, então é melhor para páginas onde “quase atualizado” é aceitável (navegação, recomendações, conteúdo público).
Réplicas são ótimas quando “próximo o suficiente” é aceitável. Elas falham quando seu produto assume que cada leitura reflete imediatamente a última gravação.
Um usuário edita o perfil, envia um formulário ou altera configurações — e o próximo carregamento vem de uma réplica alguns segundos atrás. A atualização teve sucesso, mas o usuário vê dados antigos, tenta novamente, faz submissões duplicadas ou perde confiança.
Isso é particularmente doloroso em fluxos onde o usuário espera confirmação imediata: mudar e-mail, alternar preferências, enviar um documento, postar um comentário e depois ser redirecionado.
Algumas leituras não toleram obsolescência, nem que seja momentânea:
Se uma réplica estiver atrás, você pode mostrar total de carrinho errado, vender estoque em excesso ou exibir saldo desatualizado. Mesmo que o sistema corrija depois, a experiência do usuário (e o volume de suporte) sofre.
Dashboards internos frequentemente guiam decisões reais: revisão de fraude, suporte ao cliente, atendimento de pedidos, moderação e respostas a incidentes. Se uma ferramenta administrativa lê de réplicas, você corre o risco de agir sobre dados incompletos — por exemplo, reembolsar um pedido já reembolsado ou perder o último status.
Um padrão comum é rotear condicionalmente:
Isso preserva os benefícios das réplicas sem transformar consistência em um jogo de adivinhação.
Lag de replicação é o atraso entre quando uma gravação é confirmada no primário e quando essa mesma mudança fica visível numa réplica. Se sua app ler de uma réplica durante esse atraso, pode retornar resultados “obsoletos” — dados que eram verdadeiros há pouco, mas já não são.
Lag é normal e normalmente cresce sob estresse. Causas comuns:
Lag não afeta só “frescura” — afeta a correção do ponto de vista do usuário:
Comece decidindo o que sua feature tolera:
Monitore lag de réplica (tempo/bytes atrás), taxa de aplicação da réplica, erros de replicação e CPU/disk I/O da réplica. Alerta quando o lag ultrapassar sua tolerância acordada (por exemplo, 5s, 30s, 2m) e quando o lag continuar crescendo com o tempo (sinal de que a réplica não vai conseguir alcançar sem intervenção).
Réplicas de leitura são uma ferramenta para escala de leitura: adicionar mais lugares para servir SELECT. Não são uma ferramenta para escala de gravação: aumentar quantas operações de INSERT/UPDATE/DELETE seu sistema pode aceitar.
Quando você adiciona réplicas, você adiciona capacidade de leitura. Se sua aplicação está limitada por endpoints pesados de leitura (páginas de produto, feeds, buscas), você pode espalhar essas consultas por várias máquinas.
Isso costuma melhorar:
SELECT)Uma ideia errada comum é “mais réplicas = mais throughput de gravação.” Num setup primário–réplica típico, todas as gravações ainda vão para o primário. De fato, mais réplicas podem aumentar levemente o trabalho do primário, porque ele precisa gerar e enviar dados de replicação para cada réplica.
Se sua dor é throughput de gravação, réplicas não vão resolver. Você geralmente mira outras abordagens (tuning de queries/índices, batch, particionamento/sharding ou mudar o modelo de dados).
Mesmo que réplicas deem mais CPU para leituras, você ainda pode bater em limites de conexão primeiro. Cada nó de banco tem um número máximo de conexões concorrentes, e adicionar réplicas pode multiplicar os lugares que sua app poderia conectar — sem reduzir a demanda total.
Regra prática: use pooling de conexões (ou um pooler) e mantenha contagens intencionais de conexões por serviço. Caso contrário, réplicas podem simplesmente virar “mais bancos para sobrecarregar”.
Réplicas adicionam custos reais:
O trade-off é simples: réplicas podem comprar folga para leituras e isolamento, mas adicionam complexidade e não movem o teto de gravação.
Réplicas de leitura podem melhorar a disponibilidade de leitura: se seu primário estiver sobrecarregado ou temporariamente indisponível, você ainda pode servir parte do tráfego somente de leitura a partir das réplicas. Isso pode manter páginas visíveis ao cliente (para conteúdo que tolera ligeira obsolescência) e reduzir o impacto de um incidente no primário.
O que réplicas não fornecem sozinhas é um plano completo de alta disponibilidade. Uma réplica normalmente não está pronta para aceitar gravações automaticamente, e uma “cópia legível existe” é diferente de “o sistema pode aceitar gravações de forma segura e rápida”.
Failover normalmente significa: detectar falha do primário → escolher uma réplica → promovê-la a novo primário → redirecionar gravações (e normalmente leituras) para o nó promovido.
Alguns bancos gerenciados automatizam grande parte disso, mas a ideia central é a mesma: você está mudando quem pode aceitar gravações.
Trate failover como algo a praticar. Faça exercícios em staging (e com cuidado em produção em janelas de baixo risco): simule perda do primário, meça tempo de recuperação, verifique roteamento e confirme que a aplicação lida com períodos somente leitura e reconexões de forma limpa.
Réplicas só ajudam se o tráfego realmente alcançá-las. “Separação de leitura e gravação” é o conjunto de regras que envia gravações ao primário e leituras elegíveis às réplicas — sem quebrar a correção.
A abordagem mais simples é roteamento explícito na camada de acesso a dados:
INSERT/UPDATE/DELETE, mudanças de esquema) vão para o primário.Isso é fácil de raciocinar e de desfazer. Também é onde você pode codificar regras de negócio como “após checkout, sempre ler o status do pedido no primário por um tempo”.
Algumas equipes preferem um proxy de banco ou driver inteligente que entende endpoints de primário vs réplica e roteia com base no tipo de consulta ou nas configurações da conexão. Isso reduz mudanças no código da aplicação, mas cuidado: proxies não conseguem saber com segurança quais leituras são “seguras” do ponto de vista do produto.
Bons candidatos:
Evite rotear leituras que seguem imediatamente uma gravação do usuário (por exemplo, “atualizar perfil → recarregar perfil”) a menos que você tenha uma estratégia de consistência.
Dentro de uma transação, mantenha todas as leituras no primário.
Fora de transações, considere sessões “leia-sua-gravação”: depois de uma gravação, fixe esse usuário/sessão ao primário por um TTL curto, ou direcione consultas de acompanhamento específicas ao primário.
Adicione uma réplica, roteie um conjunto limitado de endpoints/consultas e compare antes/depois:
Expanda o roteamento somente quando o impacto for claro e seguro.
Réplicas de leitura não são “configure e esqueça”. São servidores de banco extras com limites de desempenho próprios, modos de falha e tarefas operacionais. Um pouco de disciplina de monitoramento costuma ser a diferença entre “réplicas ajudaram” e “réplicas adicionaram confusão”.
Foque em indicadores que expliquem sintomas visíveis ao usuário:
Comece com uma réplica se seu objetivo é descarregar leituras. Adicione mais quando houver uma restrição clara:
Regra prática: escale réplicas somente depois de confirmar que leituras são o gargalo (não índices, consultas lentas ou cache da aplicação).
Réplicas de leitura são uma das ferramentas para escala de leitura, mas raramente são a primeira alavanca. Antes de adicionar complexidade operacional, verifique se uma solução mais simples traz o mesmo resultado.
Cache pode remover classes inteiras de leituras do banco. Para páginas majoritariamente de leitura (detalhes de produto, perfis públicos, configuração), um cache na aplicação ou CDN pode reduzir muito a carga — sem introduzir lag de replicação.
Índices e otimização de consultas frequentemente superam réplicas no caso comum: algumas consultas caras consumindo CPU. Adicionar o índice certo, reduzir colunas retornadas, evitar N+1 e consertar junções ruins pode transformar “precisamos de réplicas” em “só precisávamos de um plano melhor”.
Views materializadas / pré-agregação ajudam quando o workload é inerentemente pesado (analytics, dashboards). Em vez de reexecutar consultas complexas, você armazena resultados calculados e atualiza em um cronograma.
Se suas gravações são o gargalo (hot rows, contenção de locks, limites de I/O de escrita), réplicas não ajudarão muito. É aí que particionar tabelas por tempo/cliente ou shardear por ID de cliente pode espalhar a carga de gravação e reduzir contenção. É um passo arquitetural maior, mas resolve a restrição real.
Faça quatro perguntas:
Se você está prototipando um produto novo ou levantando um serviço rapidamente, ajuda incorporar essas restrições na arquitetura desde cedo. Por exemplo, equipes que usam o Koder.ai muitas vezes começam com um único primário por simplicidade e só migraram para réplicas quando dashboards, feeds ou relatórios internos passaram a competir com tráfego transacional. Um fluxo de trabalho orientado ao planejamento facilita decidir quais endpoints toleram consistência eventual e quais devem sempre ler a partir do primário.
Se quiser ajuda para escolher um caminho, veja /pricing para opções ou navegue por guias relacionados em /blog.
Uma réplica de leitura é uma cópia do seu banco de dados primário que recebe alterações continuamente e pode responder a consultas somente de leitura (por exemplo, SELECT). Ela ajuda a adicionar capacidade de leitura sem aumentar a carga no primário para essas consultas.
Não. Em uma configuração típica primário–réplica, todas as gravações ainda vão para o primário. Réplicas podem até acrescentar um pouco de sobrecarga porque o primário precisa enviar as mudanças para cada réplica.
Principalmente quando você está limitado por leitura: muito tráfego de SELECT que consome CPU/I/O ou causa pressão nas conexões do primário, enquanto o volume de gravações permanece estável. Elas também são úteis para isolar leituras pesadas (relatórios, exportações) das cargas transacionais.
Nem sempre. Se uma consulta é lenta por falta de índices, junções ineficientes ou varredura de muitos dados, ela provavelmente estará lenta também numa réplica — apenas em outro nó. Otimize consultas e índices primeiro quando poucas consultas dominam o tempo total.
Lag de replicação é o atraso entre quando uma gravação é confirmada no primário e quando essa mudança fica visível numa réplica. Durante o lag, leituras na réplica podem estar obsoletas, por isso sistemas que usam réplicas frequentemente operam com consistência eventual para algumas leituras.
Causas comuns incluem:
Evite réplicas para leituras que devem refletir imediatamente a última gravação, como:
Para esses casos, prefira ler do primário, pelo menos nos caminhos críticos.
Use uma estratégia de leitura após gravação:
Monitore um conjunto pequeno de sinais:
Alerta quando o lag ultrapassar a tolerância do produto (por exemplo, 5s/30s/2m).
Alternativas comuns:
Réplicas são melhores quando leituras já estão razoavelmente otimizadas e você pode tolerar alguma obsolescência.