Проверка read-only routing из приложения SQL Server

ApplicationIntent=ReadOnly в строке соединения не доказывает, что отчеты ушли с первичной реплики. Маршрут зависит от listener, указанной базы, настройки реплик и клиента. Первая полезная проверка спрашивает новое соединение, куда оно действительно попало.

Проверить фактическое назначение

Выполните запрос через отчетное соединение приложения, а не через отдельное окно SSMS.

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;

Для базы группы IsPrimaryReplica различает первичную и вторичную роли. NULL может означать отсутствие участия или невозможность разрешения базы в контексте. Не считайте это успешным попаданием на вторичную. Сохраните сервер и базу вместе с проверкой.

Совместимый клиент обычно обращается к listener, указывает базу группы и передает ApplicationIntent=ReadOnly. Server=tcp:listener.example,1433;Database=ReportingDb;ApplicationIntent=ReadOnly показывает только маршрутную часть, а не полную настройку аутентификации и TLS.

Прямое подключение к имени реплики обходит решение listener. Отсутствие нужной базы также может нарушить ожидаемое направление. Проверяйте итоговую конфигурацию после всех переопределений, исключая секреты из журнала.

Клиент должен достигать перенаправленного адреса. Успешный TCP к listener не доказывает доступность URL и порта реплики. Проверьте DNS, firewall, доверие сертификату и драйвер для настоящего назначения.

Проверить каждого возможного владельца роли

Списки определяют направление, когда конкретная реплика является первичной. Читающий запрос метаданных показывает эти связи при соответствующих правах.

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;

Рассмотрите все реплики, способные стать первичными. Если маршрут ломается после failover, может отсутствовать список нового владельца роли. Целевые реплики также должны разрешать чтение и иметь правильный URL.

Списки задают приоритет, а поддерживаемые конфигурации позволяют группировать назначения для распределения соединений. Решение принимается при открытии; работающий запрос между репликами не переносится. Пул поэтому может давать неравномерность и сохранять прежние соединения до закрытия или разрыва.

Определите допустимость возврата на первичную при недоступных отчетных репликах. Это политика нагрузки, а не автоматический признак успеха. Отслеживайте такой возврат: он способен принести тяжелые отчеты на транзакционный сервер во время аварии.

ApplicationIntent не заменяет права. На доступной для записи первичной реплике пользователь может сохранять свои разрешения изменения. Используйте ограниченную отчетную учетную запись и не рассматривайте метку соединения как границу авторизации.

Проверить свежесть и смену ролей

Вторичные реплики применяют изменения и могут отставать. Даже синхронный commit не гарантирует, что каждое подтвержденное изменение уже прошло redo и видно чтению. Экран, записавший на первичную и сразу прочитавший вторичную, может временно не найти свою правку.

Определите операции, допускающие задержку. Немедленное чтение после записи должно использовать подходящий согласованный путь либо проверенную стратегию ожидания и сверки. Наблюдайте прогресс redo и возраст данных наряду с успешностью соединения.

Проверьте приложение при плановом failover, временно недоступном назначении и пуле со старыми соединениями. Повторите определение сервера после переподключения. Используйте ограниченные повторы для подходящих временных ошибок чтения.

Отчеты потребляют CPU, память и ввод-вывод, необходимые также redo. Поэтому корректный маршрут может ухудшать свежесть под нагрузкой. Проверяйте производительность отчетов и отставание вместе. Сохраните диагностический запрос назначения в эксплуатационной инструкции, а в результатах теста укажите, какая реплика была первичной и сколько соединений открыли заново. Это позволяет отличить ошибку настройки от поведения уже существующего пула и не опираться на единственную старую проверку.

Техническая документация: Microsoft Learn: Read-only routing configuration · Microsoft Learn: Readable secondary replicas.