Определение причин, по которым изменения в первичной реплике не отражаются во вторичной реплике группы доступности Always On

Применимо к:SQL Server

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

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

Синхронная фиксация

Каждое успешное обновление на первичной реплике уже было синхронизировано на вторичную реплику, или эти записи журнала уже были записаны для сохранения на вторичной реплике. Таким образом, указанное узкое место должно находиться в процессе повтора, который выполняется после сохранения журнала на вторичной реплике.

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

• Длительные транзакции на первичной реплике

• Повтор на вторичной реплике

Асинхронная фиксация

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

• Длительные транзакции на первичной реплике

• Задержка в сети или пропускная способность

• Запись журнала на вторичной реплике

• Повтор на вторичной реплике

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

Активные длительные транзакции

Длительная транзакция на первичной реплике препятствует чтению изменений на вторичной реплике.

Объяснение

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

Диагностика и способ устранения

В первичной реплике выполните DBCC OPENTRAN (Transact-SQL), чтобы получить список самых старых активных транзакций и выяснить возможность их отката. После отката самых старых активных транзакций и их синхронизации со вторичной репликой рабочие нагрузки чтения на вторичной реплике могут увидеть изменения в базе данных доступности до начала транзакции, которая тогда являлась старейшей активной.

Большая задержка в сети или низкая пропускная способность сети вызывает накопление журнала на первичной реплике

Высокая задержка в сети или низкая пропускная способность могут препятствовать достаточно быстрой отправке журналов на вторичную реплику.

Объяснение

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

Диагностика и способ устранения

Высокое значение динамического административного представления log_send_queue_size может указывать на то, что журналы удерживаются на первичной реплике. Разделив это значение на log_send_rate, можно приблизительно оценить, как скоро данные можно будет перехватить на вторичной реплике.

Кроме того, полезно проверить два объекта производительности — SQL Server:Реплика доступности > Время потока управления (мс/с) и SQL Server:Реплика доступности > Поток управления/с. Произведение этих значений сообщает, сколько времени за последнюю секунду ушло на ожидание очистки управления потоком. Чем больше время ожидания управления потоком, тем ниже скорость отправки.

Ниже приведен список метрик, которые могут оказаться полезными при диагностике задержки в сети и пропускной способности. Для оценки использования сети можно применять другие средства Windows, например ping.exe.

• Динамическое административное представление log_send_queue_size

• Динамическое административное представление log_send_rate

• Счетчик производительности SQL Server:Database > Log Bytes Flushed/sec

• Счетчик производительности SQL Server:Database Mirroring > Send/Receive Ack Time

• Счетчик производительности SQL Server:Availability Replica > Bytes Sent to Replica/sec

• Счетчик производительности SQL Server:Availability Replica > Bytes Sent to Transport/sec

• Счетчик производительности SQL Server:Availability Replica > Flow Control Time (ms/sec)

• Счетчик производительности SQL Server:Availability Replica > Flow Control/sec

• Счетчик производительности SQL Server:Availability Replica > Resent Messages/sec

Чтобы устранить эту проблему, попробуйте повысить пропускную способность сети либо устранить или снизить ненужный сетевой трафик.

Другая рабочая нагрузка отчетов блокирует запуск потока повтора

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

Объяснение

Во вторичной реплике запросы только для чтения получают блокировки стабилизации схемы (Sch-S). Эти блокировки Sch-S могут мешать потоку повтора получать блокировки изменения схемы (Sch-M) для внесения изменений DDL. Заблокированный поток повтора не может применять записи журнала до разблокировки.

Диагностика и способ устранения

Когда поток повтора заблокирован, создается расширенное событие sqlserver.lock_redo_blocked. Кроме того, можно запросить динамическое административное представление sys.dm_exec_request во вторичной реплике, чтобы узнать, какой сеанс блокирует поток повтора, чтобы затем предпринять корректирующее действие. Приведенный ниже запрос возвращает идентификатор сеанса рабочей нагрузки чтения, блокирующей поток повтора.

select session_id, command, blocking_session_id, wait_time, wait_type, wait_resource   
from sys.dm_exec_requests where command = 'DB STARTUP'  

Вы можете дождаться окончания рабочей нагрузки отчетов, после чего поток повтора разблокируется автоматически, или разблокировать этот поток вручную командой KILL (Transact-SQL) с идентификатором блокирующего сеанса.

Поток повтора запаздывает из-за состязания ресурсов

Большая рабочая нагрузка отчетов на вторичной реплике замедлила работу вторичной реплики, и поток повтора запаздывает.

Объяснение

При применении записей журнала на вторичной реплике поток повтора считывает записи журнала с диска журнала, а затем для каждой записи журнала он обращается к страницам данных, чтобы применить эту запись. Обращение к странице может быть привязано к вводу-выводу (доступ к физическому диску), если данная страница еще не находится в буферном пуле. Если имеется рабочая нагрузка отчетов, привязанная к вводу-выводу, она конкурирует за ресурсы ввода-вывода с потоком повтора и может замедлить его работу. Это повлияет не только на способность других рабочих нагрузок отчетов видеть обновленные данные, но также и на RTO.

Диагностика и способ устранения

Вы можете использовать приведенный ниже запрос динамического административного представления, чтобы узнать, насколько сильно отстает поток повтора, измерив разницу между last_redone_lsn и last_received_lsn.

select recovery_lsn, truncation_lsn, last_hardened_lsn, last_received_lsn,   
   last_redone_lsn, last_redone_time  
from sys.dm_hadr_database_replica_states  
  

Если поток повтора на самом деле запаздывает, нужно исследовать первопричину снижения производительности на вторичной реплике. Если присутствует состязание ввода-вывода с рабочей нагрузкой отчетов, можно использовать Resource Governor для управления циклами ЦП, которые рабочая нагрузка отчетов использует для косвенного управления использованными циклами ввода-вывода. Например, если рабочая нагрузка отчетов использует 10 процентов ресурсов ЦП, но она привязана к вводу-выводу, можно с помощью Resource Governor ограничить использование ресурсов ЦП на 5 процентов для регулирования рабочей нагрузки чтения, что минимизирует влияние на операции ввода-вывода.

Дальнейшие действия

Устранение связанных с производительностью неполадок в SQL Server 2008