Vérifier le routage en lecture seule depuis l'application

Ajouter ApplicationIntent=ReadOnly ne prouve pas que les rapports quittent le primaire. Le routage dépend du listener, de la base nommée, de la configuration des réplicas et du client. Le premier test consiste à demander à la nouvelle connexion où elle est arrivée.

Observer la destination réelle

Exécutez cette vérification via la connexion de reporting de l'application, pas dans une session SSMS indépendante.

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;

Pour une base d'availability group, IsPrimaryReplica distingue les rôles. NULL peut indiquer une base non participante ou non résolue dans ce contexte ; ce n'est pas une preuve de connexion secondaire. Enregistrez serveur et base avec le test.

Un client compatible contacte normalement le listener, nomme une base du groupe et fournit ApplicationIntent=ReadOnly. Server=tcp:listener.example,1433;Database=ReportingDb;ApplicationIntent=ReadOnly illustre seulement la partie routage, sans constituer une configuration complète d'authentification et TLS.

Un nom de réplica direct contourne la décision du listener. Omettre la base visée peut aussi empêcher la route attendue. Vérifiez la configuration effective après toutes les surcharges, en excluant les secrets des journaux.

Le client doit atteindre la destination redirigée. Une connexion TCP réussie au listener ne démontre pas l'accès à l'URL et au port du réplica. Contrôlez DNS, pare-feu, confiance des certificats et pilote pour la véritable cible.

Examiner chaque primaire possible

Les listes indiquent où diriger les connexions lorsqu'un réplica donné est primaire. Cette requête de métadonnées affiche les relations avec les droits de visibilité adaptés.

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;

Vérifiez tous les réplicas susceptibles de devenir primaires. Un routage qui cesse après basculement peut manquer de configuration pour le nouveau propriétaire du rôle. Les cibles doivent aussi accepter les lectures secondaires et posséder une URL valide.

La liste peut prioriser des destinations et, dans les configurations prises en charge, grouper des cibles pour répartir les connexions. Le choix se fait à l'ouverture ; il ne déplace pas une requête active. Le pooling peut donc produire une répartition inégale et conserver des connexions existantes.

Décidez si le retour sur primaire est acceptable lorsque les secondaires sont indisponibles. C'est une politique de charge. Surveillez ce repli autorisé, car il peut ramener les rapports lourds sur le serveur transactionnel pendant l'incident.

ApplicationIntent ne remplace pas les permissions. Une identité connectée à un primaire inscriptible peut conserver ses droits d'écriture. Utilisez un compte de reporting restreint plutôt que ce paramètre comme frontière d'autorisation.

Tester fraîcheur et changements de rôle

Les secondaires rejouent les modifications et peuvent être en retard. Même le commit synchrone ne garantit pas que chaque changement validé soit déjà rejoué et visible à la lecture. Une page qui écrit sur primaire puis lit immédiatement sur secondaire peut ne pas retrouver sa modification.

Définissez les opérations tolérant ce délai. Les lectures immédiates après écriture doivent emprunter un chemin cohérent approprié, ou une stratégie d'attente et de réconciliation testée. Surveillez progression redo et ancienneté des données, pas seulement la réussite de connexion.

Testez l'application pendant un basculement planifié, une cible indisponible et avec un pool contenant d'anciennes connexions. Réexécutez la vérification après reconnexion. Limitez les reprises des erreurs transitoires aux opérations de lecture appropriées.

Enfin, les rapports utilisent CPU, mémoire et I/O également nécessaires au redo. Une route correcte peut malgré tout dégrader la fraîcheur sous charge. Validez débit des rapports et retard redo ensemble. Conservez la sonde de destination dans le diagnostic opérationnel pour vérifier les futurs changements de configuration.

Références techniques: Microsoft Learn: Read-only routing configuration · Microsoft Learn: Readable secondary replicas.