Verificar el enrutamiento de solo lectura desde la aplicación

Añadir ApplicationIntent=ReadOnly no demuestra que los informes salgan de la primaria. El enrutamiento depende del listener, la base indicada, las réplicas y el cliente. La primera prueba útil pregunta a la conexión recién abierta dónde llegó realmente.

Comprobar el destino efectivo

Ejecuta esta consulta mediante la conexión de informes de la aplicación, no en una ventana SSMS independiente.

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;

En una base del grupo, IsPrimaryReplica distingue primaria y secundaria. NULL puede significar que la base no participa o no se resuelve en ese contexto. No lo interpretes como éxito secundario. Registra servidor y base junto al intento de conexión.

Un cliente compatible normalmente conecta al listener, nombra una base del grupo y envía ApplicationIntent=ReadOnly. Server=tcp:listener.example,1433;Database=ReportingDb;ApplicationIntent=ReadOnly muestra la parte de enrutamiento, no una configuración completa de credenciales o TLS.

Conectar directamente al host de una réplica evita la decisión del listener. Omitir la base prevista también puede impedir la ruta. Examina la cadena efectiva tras sobrescrituras de configuración, sin registrar secretos.

El cliente debe poder alcanzar el destino redirigido. Abrir TCP al listener no prueba acceso a la URL y puerto de la réplica. Comprueba DNS, firewall, confianza de certificados y controlador para el destino real.

Revisar cada posible primaria

Las listas describen dónde enviar conexiones cuando una réplica concreta es primaria. Esta consulta de metadatos muestra esas relaciones con permisos adecuados.

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;

Revisa todas las réplicas que puedan asumir el rol. Una configuración que deja de funcionar tras failover puede carecer de lista para la nueva primaria. Los destinos también necesitan configuración de lectura secundaria y URL válida.

Las listas priorizan destinos y las configuraciones compatibles pueden agruparlos para distribuir conexiones. La decisión ocurre al abrir, no mueve consultas que ya se ejecutan. El pool puede producir reparto desigual y mantener conexiones anteriores hasta cerrarlas o perderlas.

Define si se permite volver a la primaria cuando no haya secundarias disponibles. Es una política de carga, no una señal automática de éxito. Monitoriza ese retorno, porque puede llevar informes pesados al servidor transaccional durante un incidente.

ApplicationIntent no sustituye permisos. Una identidad en la primaria de lectura y escritura puede conservar privilegios de modificación. Usa una cuenta restringida de informes; el parámetro no es una frontera de autorización.

Probar frescura y cambios de rol

Las secundarias reproducen cambios y pueden retrasarse. Incluso commit síncrono no garantiza que toda modificación confirmada haya pasado por redo y sea visible. Una pantalla que escribe en primaria y lee inmediatamente en secundaria puede no encontrar su cambio.

Decide qué operaciones toleran ese retraso. Mantén lecturas inmediatas tras escritura en una ruta coherente o define una estrategia probada de espera y reconciliación. Observa progreso de redo y antigüedad de datos además de conexión exitosa.

Prueba la aplicación durante failover planificado, destino temporalmente inaccesible y pool con conexiones antiguas. Repite la comprobación tras reconectar. Usa reintentos limitados para errores transitorios adecuados a la lectura.

Finalmente, los informes consumen CPU, memoria y E/S también necesarios para redo. Una ruta correcta puede perjudicar la frescura bajo carga. Valida rendimiento de informes y retraso conjuntamente. Conserva la consulta de destino como diagnóstico operativo para comprobar futuras modificaciones, en lugar de confiar en una prueba antigua que solo reflejaba el rol de aquel día.

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