Read-only Routing aus der SQL-Server-Anwendung prüfen

ApplicationIntent=ReadOnly in einer Verbindungszeichenfolge beweist nicht, dass Berichte die primäre Replik verlassen haben. Routing hängt von Listener, Datenbank, Replikakonfiguration und Clientpfad ab. Prüfen Sie zuerst, wo eine neue Verbindung tatsächlich ankommt.

Das Ziel über die echte Verbindung feststellen

Führen Sie diese Abfrage über die Berichtsverbindung der Anwendung aus, nicht in einer unabhängigen SSMS-Sitzung.

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;

Bei einer Datenbank in einer Availability Group unterscheidet IsPrimaryReplica primäre und sekundäre Rolle. NULL kann auf fehlende Teilnahme oder fehlende Auflösung im Kontext hinweisen. Werten Sie es nicht als erfolgreichen Sekundärnachweis. Speichern Sie Server und Datenbank beim Verbindungstest.

Ein geeigneter Client verbindet sich normalerweise zum Gruppenlistener, nennt eine Datenbank der Gruppe und setzt ApplicationIntent=ReadOnly. Server=tcp:listener.example,1433;Database=ReportingDb;ApplicationIntent=ReadOnly zeigt nur den Routingteil, keine vollständige Anmeldung oder TLS-Konfiguration.

Eine direkte Verbindung zum Replikahost umgeht die Listenerentscheidung. Auch eine fehlende Zieldatenbank kann die erwartete Weiterleitung verhindern. Prüfen Sie die tatsächlich wirksame Konfiguration nach allen Überschreibungen, ohne Geheimnisse zu protokollieren.

Der Client muss das weitergeleitete Ziel erreichen können. Eine erfolgreiche Listenerverbindung beweist keinen Zugriff auf Routing-URL und Port der Replik. Prüfen Sie DNS, Firewallpfad, Zertifikatsvertrauen und Treiberunterstützung am tatsächlichen Ziel.

Alle möglichen primären Rollen berücksichtigen

Routinglisten legen fest, wohin Verbindungen gehen, wenn eine bestimmte Replik primär ist. Diese Leseabfrage zeigt die Beziehungen mit passenden Metadatenrechten.

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;

Prüfen Sie jede Replik, die primär werden kann. Funktioniert Routing nur bis zum Failover, fehlt möglicherweise die Liste des neuen Rolleninhabers. Ziele benötigen außerdem lesbare Sekundärkonfiguration und eine gültige Routing-URL.

Listen können Ziele priorisieren; unterstützte Konfigurationen erlauben Gruppen zur Verteilung neuer Verbindungen. Eine laufende Abfrage wird dadurch nicht zwischen Repliken verschoben. Pooling kann daher ungleichmäßige Verteilung erzeugen und bestehende Verbindungen bis zum Schließen oder Abbruch erhalten.

Definieren Sie, ob bei Ausfall der Berichtsziele die primäre Replik verwendet werden darf. Das ist eine Lastpolitik, kein automatischer Erfolg. Erlaubter Rückfall gehört überwacht, weil er während eines Vorfalls große Berichte auf den Transaktionsserver zurückbringen kann.

ApplicationIntent ersetzt keine Datenbankrechte. Auf einer schreibbaren primären Replik kann die Identität weiterhin ihre vorhandenen Schreibrechte besitzen. Verwenden Sie eine entsprechend eingeschränkte Berichtsidentität und keine reine Vertrauensannahme aus dem Verbindungsparameter.

Aktualität und Rollenwechsel testen

Lesbare Sekundärrepliken spielen Änderungen nach und können zurückliegen. Selbst synchroner Commit bedeutet nicht, dass jede bestätigte Änderung dort bereits durch Redo sichtbar ist. Eine Oberfläche, die primär schreibt und sofort sekundär liest, kann ihre eigene Änderung zunächst vermissen.

Legen Sie fest, welche Funktionen diese Verzögerung tolerieren. Unmittelbares Lesen nach Schreiben benötigt einen passenden konsistenten Weg oder eine ausdrücklich getestete Warte- und Abgleichstrategie. Beobachten Sie Redo-Fortschritt und Datenalter zusätzlich zum Verbindungsstatus.

Testen Sie geplantes Failover, nicht erreichbare Ziele und einen Pool mit älteren Verbindungen über die Anwendung. Prüfen Sie das Ziel nach dem Neuverbinden erneut. Behandeln Sie vorübergehende Verbindungsfehler mit begrenzten Wiederholungen für geeignete Leseoperationen.

Berichte verbrauchen auf der Sekundärreplik CPU, Speicher und I/O, die auch Redo benötigt. Korrektes Routing kann deshalb unter Last trotzdem die Aktualität verschlechtern. Prüfen Sie Berichtsdurchsatz und Redo-Verzug gemeinsam. Bewahren Sie die Zielabfrage als Betriebsdiagnose auf, damit spätere Konfigurationsänderungen messbar bleiben.

Technische Referenzen: Microsoft Learn: Read-only routing configuration · Microsoft Learn: Readable secondary replicas.