Replicação transacional no SQL Server: como tirar a leitura da API do banco de produção

Publicado em 11 de outubro de 2026 · Leitura de 8 min

Edson Feitosa de Oliveira Junior Fundador · PruPru Digital Services · Natal/RN

Uma empresa precisava expor dados do ERP para uma nova API interna. O banco de produção tinha cerca de 200 GB e já atendia o sistema principal o dia todo. Colocar as consultas da API direto nele significava disputar CPU, memória e bloqueios com quem estava faturando pedidos.

A solução que desenhei e coloquei em produção foi a replicação transacional do SQL Server para um servidor clone somente leitura. A API só lê do clone. Abaixo está o passo a passo e os cuidados que aprendi no caminho.

Quando a replicação transacional faz sentido

• Você precisa de dados quase em tempo real (segundos de atraso) num segundo servidor.
• A leitura extra (API, BI, relatórios) atrapalha o banco principal.
• Você quer criar índices só no clone, otimizados para as consultas da API, sem pesar nas gravações da produção.
• Não dá (ou não compensa) usar Always On com réplica legível, que exige edição Enterprise para o cenário completo.

Se um atraso de horas é aceitável, um restore diário de backup costuma ser mais simples.

A arquitetura

• Publisher (publicador): o banco de produção.
• Distributor (distribuidor): no nosso caso, no mesmo servidor do Publisher, para não precisar de uma terceira máquina.
• Subscriber (assinante): o servidor clone, recebendo por push subscription (o distribuidor empurra as mudanças).

Três agentes do SQL Server Agent fazem o trabalho: o Snapshot Agent gera a carga inicial, o Log Reader Agent lê o log de transações do publicador e o Distribution Agent aplica as mudanças no assinante.

Pré-requisitos que valem uma auditoria antes

Antes de configurar, escrevi um script T-SQL de auditoria para verificar tudo de uma vez. Os pontos que mais derrubam a configuração:

• Toda tabela publicada precisa de chave primária. Tabelas sem PK não entram em publicação transacional. Liste-as antes:

SELECT s.name AS esquema, t.name AS tabela
FROM sys.tables t
JOIN sys.schemas s ON s.schema_id = t.schema_id
WHERE OBJECTPROPERTY(t.object_id, 'TableHasPrimaryKey') = 0
ORDER BY 1, 2;

• SQL Server Agent rodando e configurado para iniciar automaticamente nos dois servidores.
• Nome do servidor correto: SELECT @@SERVERNAME precisa bater com o nome real da máquina. Servidor renomeado depois da instalação quebra a replicação.
• Firewall: porta do SQL Server (1433 por padrão) liberada do distribuidor para o assinante, e uma pasta de snapshot acessível pela conta dos agentes.
• Espaço em disco para o snapshot inicial e para o crescimento do log de transações.

Os 4 passos de configuração

1. Configurar o distribuidor (Replication → Configure Distribution), definindo o banco distribution e a pasta de snapshot.
2. Criar a publicação transacional com apenas as tabelas que a API precisa. Publicar o banco inteiro aumenta o snapshot e o tráfego sem necessidade.
3. Criar a assinatura push apontando para o banco do clone.
4. Gerar e aplicar o snapshot inicial, de preferência fora do horário comercial: numa base grande, essa é a etapa mais pesada.

Monitoramento: o que vigiar todo dia

Replicação que ninguém monitora para em silêncio. Montei uma rotina diária que verifica dois números e envia alerta por e-mail quando passam do limite:

• Latência: tempo entre a gravação na produção e a chegada no clone. O Replication Monitor mostra esse valor, e os tracer tokens (sp_posttracertoken) permitem medir isso de forma automatizada.
• Crescimento do log no publicador: se o Log Reader Agent parar, o log de transações não é liberado e cresce até encher o disco. Fique de olho nisto:

SELECT name, log_reuse_wait_desc
FROM sys.databases
WHERE name = 'SEU_BANCO';
-- REPLICATION de forma persistente = Log Reader parado ou atrasado

Alterações de esquema sem quebrar a replicação

• Adicionar coluna com ALTER TABLE ... ADD na produção é replicado automaticamente (opção replicate_ddl, ativa por padrão).
• Renomear coluna ou trocar o tipo de uma coluna publicada exige planejamento. Normalmente é preciso tirar o artigo da publicação, alterar e reinicializar só aquele artigo.
• Nunca altere tabelas replicadas direto no clone. Uma linha a mais ou a menos no assinante faz o Distribution Agent parar com erro de “linha não encontrada”.

Segurança e desempenho do clone

• A API conecta com um usuário somente leitura (apenas db_datareader ou permissões SELECT por esquema), separado de qualquer usuário de manutenção.
• Conexão com TLS habilitado entre a API e o clone.
• Pool de conexões próprio na aplicação (usei HikariCP com 20 conexões e um datasource exclusivo para o BI), para a API não competir com outras partes do sistema.
• Índices criados só no clone, de acordo com as consultas reais da API.

Checklist de go-live

Antes de apontar a API para o clone, conferi itens como estes (a versão completa tinha 14 pontos):

• Snapshot aplicado e contagem de linhas igual nas tabelas principais.
• Latência medida com tracer token dentro do limite combinado.
• Alerta de e-mail testado de verdade (parando o agente de propósito).
• Usuário da API sem permissão de escrita, testado com um INSERT que precisa falhar.
• Procedimento de recuperação escrito para três cenários: agente parado, assinante fora de sincronia e reinicialização completa.

Essa arquitetura roda hoje por trás de um portal interno em produção. O documento de operação começou na versão 1.0 e chegou à 2.0 com base nos problemas reais que apareceram no uso.

Perguntas frequentes