Verificar roteamento de leitura pela aplicação SQL Server

Adicionar ApplicationIntent=ReadOnly não prova que relatórios saíram da primária. O roteamento depende do listener, da base indicada, das réplicas e do caminho cliente. A primeira verificação útil pergunta à nova conexão onde ela realmente chegou.

Conferir o destino efetivo

Execute esta consulta pela conexão de relatórios da aplicação, não por uma sessão SSMS separada.

SELECT
    CONVERT(nvarchar(128), SERVERPROPERTY('ServerName')) AS ConnectedServer,
    DB_NAME() AS ConnectedDatabase,
    sys.fn_hadr_is_primary_replica(DB_NAME()) AS IsPrimaryReplica,
    DATABASEPROPERTYEX(DB_NAME(), 'Updateability') AS Updateability;

Em uma base do grupo, IsPrimaryReplica diferencia primária e secundária. NULL pode indicar ausência no grupo ou impossibilidade de resolução naquele contexto. Não interprete isso como sucesso secundário. Registre servidor e base com o teste.

Um cliente compatível normalmente conecta ao listener, informa uma base do grupo e usa ApplicationIntent=ReadOnly. Server=tcp:listener.example,1433;Database=ReportingDb;ApplicationIntent=ReadOnly exemplifica apenas roteamento, sem completar autenticação ou TLS.

Conectar diretamente ao host da réplica evita a decisão do listener. Omitir a base pretendida também pode impedir a rota esperada. Confira a configuração efetiva depois de sobrescritas, excluindo segredos dos logs.

O cliente precisa alcançar o destino redirecionado. Abrir TCP no listener não comprova acesso à URL e porta da réplica. Verifique DNS, firewall, confiança de certificados e driver para o destino real.

Revisar todas as possíveis primárias

As listas definem destinos quando determinada réplica assume o papel primário. Esta consulta de metadados mostra as relações com permissões apropriadas.

SELECT
    ag.name AS AvailabilityGroup,
    source.replica_server_name AS WhenPrimary,
    rl.routing_priority,
    target.replica_server_name AS RouteTo,
    target.read_only_routing_url
FROM sys.availability_read_only_routing_lists AS rl
JOIN sys.availability_replicas AS source
    ON source.replica_id = rl.replica_id
JOIN sys.availability_replicas AS target
    ON target.replica_id = rl.read_only_replica_id
JOIN sys.availability_groups AS ag
    ON ag.group_id = source.group_id
ORDER BY ag.name, source.replica_server_name, rl.routing_priority;

Revise toda réplica capaz de virar primária. Uma configuração que falha após failover pode não ter a lista para o novo proprietário do papel. Destinos também precisam aceitar leitura secundária e possuir URL válida.

As listas podem priorizar destinos e configurações compatíveis permitem agrupá-los para distribuição de conexões. A decisão ocorre na abertura e não move consultas em andamento. O pool pode criar distribuição desigual e manter conexões antigas até fechamento ou falha.

Defina se retornar à primária é aceitável quando as secundárias não estão disponíveis. Isso é política de carga. Monitore o fallback permitido, pois ele pode devolver relatórios pesados ao servidor transacional durante um incidente.

ApplicationIntent não substitui permissões. Uma identidade na primária gravável pode continuar tendo direitos de escrita. Use uma identidade restrita para relatórios, sem tratar o parâmetro como fronteira de autorização.

Testar atualização dos dados e troca de papel

As secundárias refazem alterações e podem estar atrasadas. Mesmo commit síncrono não garante que toda mudança confirmada já tenha passado por redo e esteja visível. Uma tela que grava na primária e lê logo na secundária pode não encontrar sua alteração.

Determine quais operações toleram atraso. Mantenha leitura imediata após escrita em um caminho coerente ou use uma estratégia de espera e reconciliação testada. Acompanhe progresso de redo e idade dos dados além do sucesso da conexão.

Teste a aplicação em failover planejado, destino temporariamente indisponível e pool com conexões anteriores. Confira novamente o destino após reconexão. Trate erros transitórios com tentativas limitadas adequadas à operação de leitura.

Por fim, relatórios consomem CPU, memória e E/S também usados pelo redo. Uma rota correta pode prejudicar a atualização dos dados sob carga. Valide vazão dos relatórios e atraso conjuntamente. Preserve a consulta de destino no diagnóstico operacional para conferir mudanças futuras, em vez de confiar em um teste antigo que representava somente os papéis daquele momento.

Referências técnicas: Microsoft Learn: Read-only routing configuration · Microsoft Learn: Readable secondary replicas.