Поделиться через

Устранение неполадок с постановкой в очередь отправки журналов в группе доступности Always On

  • Статья

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

Что такое очередь отправки журналов?

Изменения, внесенные в базу данных группы доступности на первичной реплика (напримерINSERT, , UPDATEи DELETE), записываются в журнал транзакций и отправляются во вторичные реплики группы доступности. Очередь отправки журнала определяет количество записей журнала в файлах журнала базы данных-источника, которые не были отправлены во вторичные реплики.

Симптомы и последствия очереди отправки журналов

Очередь отправки журналов хранит все уязвимые данные

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

Растущая очередь отправки журналов приводит к росту файлов журнала транзакций

Для базы данных, определенной в группе доступности, Microsoft SQL Server должна хранить в основном реплика все транзакции в журнале транзакций, которые еще не были доставлены во вторичные реплики. Очередь отправки журнала представляет количество зарегистрированных изменений на основном реплика, которые не могут быть усечены во время обычных событий усечения журнала (например, во время резервного копирования журнала базы данных). Большая и растущая очередь отправки журналов может истощать свободное место на диске, на котором размещен файл журнала базы данных, или может превысить настроенный максимальный размер файла журнала транзакций. Дополнительные сведения см. в статье Ошибка 9002 при большом размере журнала транзакций.

Различные функции диагностики, отчеты о очереди отправки журнала группы доступности

Панель мониторинга Always On в SQL Server Management Studio сообщает об очередях отправки журналов. Он может сообщить, что группа доступности неработоспособна.

Как проверка для очереди отправки журналов

Очередь отправки журнала — это измерение для каждой базы данных. Это значение можно проверка с помощью панели мониторинга Always On на основном реплика или с помощью динамических административных представлений (DMV) sys.dm_hadr_database_replica_states на основном или дополнительном реплика. счетчики Монитор производительности используются для проверка для отправки журналов в очередь для вторичного реплика.

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

Sys.dm_hadr_database_replica_state запросов

Динамическое административное sys.dm_hadr_database_replica_states представление сообщает по строке для каждой базы данных группы доступности. Одним из столбцов в этом отчете является log_send_queue_size. Это значение — размер очереди отправки журнала в килобайтах (КБ). Вы можете настроить запрос, например следующий запрос, чтобы отслеживать любую тенденцию в размере очереди отправки журнала. Запрос выполняется на основном реплика. Он использует is_local=0 предикат для передачи данных для вторичного реплика, где log_send_queue_size и log_send_rate являются актуальными.

WHILE 1=1
BEGIN
  SELECT drcs.database_name, ars.role_desc, drs.log_send_queue_size, drs.log_send_rate,
ars.recovery_health_desc, ars.connected_state_desc, ars.operational_state_desc, ars.synchronization_health_desc, *
  FROM sys.dm_hadr_availability_replica_states ars JOIN sys.dm_hadr_database_replica_cluster_states drcs ON ars.replica_id=drcs.replica_id
  JOIN sys.dm_hadr_database_replica_states drs ON drcs.group_database_id=drs.group_database_id
  WHERE ars.role_desc='SECONDARY' AND drs.is_local=0
  waitfor delay '00:00:30'
END

Вот как выглядят выходные данные.

Снимок экрана: мониторинг любой тенденции в размере очереди отправки журнала.

Просмотр очереди отправки журналов на панели мониторинга Always On

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

  1. Откройте панель мониторинга Always On в SQL Server Management Studio (SSMS), щелкнув правой кнопкой мыши группу доступности в обозреватель объектов SSMS.

  2. Выберите Показать панель мониторинга.

    Базы данных группы доступности перечислены последними, и в них отображаются некоторые данные. Хотя размер очереди отправки журнала (КБ) и скорость отправки журнала (КБ/с) по умолчанию не указаны, их можно добавить в это представление, как показано на снимке экрана на следующем шаге.

  3. Чтобы добавить эти столбцы, щелкните правой кнопкой мыши заголовок столбца базы данных группы доступности и выберите из списка доступных столбцов.

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

    Снимок экрана: добавление размера очереди отправки журнала.

    По умолчанию панель мониторинга Always On автоматически обновляет эти данные каждые 60 секунд.

    Снимок экрана: автоматическое обновление данных на панели мониторинга Always On каждые 60 секунд.

Просмотрите очередь отправки журналов в Монитор производительности

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

  1. Откройте Монитор производительности на дополнительном реплика.

  2. Нажмите кнопку Добавить (счетчик).

  3. В разделе Доступные счетчики выберите счетчикиSQLServer:Database Replica (Реплика базы данных ) и Log Send Queue (Очереди отправки журналов ).

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

  5. Выберите Добавить и ОК.

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

    Снимок экрана: увеличение очереди отправки журнала.

Интерпретация значений очереди отправки журнала

В этом разделе объясняется, как интерпретировать значения размера очереди отправки журнала.

Когда ошибка очереди отправки журнала? Сколько должно быть разрешено отправки журналов?

Можно предположить, что если очередь отправки журнала сообщает о значении 0, это означает, что очередь отправки журнала не выполняется во время создания отчета. Однако если ваша рабочая среда занята, следует ожидать, что очередь отправки журналов часто сообщает о значении, отличном от нуля, даже в работоспособной среде AlwaysOn. Во время обычной рабочей среды следует ожидать, что это значение будет колебаться в диапазоне от 0 до значения, отличного от нуля.

Если вы наблюдаете увеличение очереди отправки журналов с течением времени, требуется дальнейшее исследование. Это дополнительное действие указывает на то, что что-то изменилось. Если вы наблюдаете внезапное увеличение очереди отправки журналов, для устранения неполадок полезны следующие измерения:

  • Скорость отправки журнала (КБ/с) (панель мониторинга AlwaysOn)
  • sys.dm_hadr_database_replica_states (динамическое административное представление)
  • Реплика базы данных::зеркальные транзакции/с (Монитор производительности)

Получение базовых показателей скорости отправки журналов и зеркальных транзакций/с

При работоспособной производительности AlwaysOn отслеживайте скорость отправки журналов и зеркальные значения транзакций/с для загруженных баз данных группы доступности. Как они выглядят в обычно занятое рабочее время? Как они выглядят в периоды обслуживания, когда большие транзакции требуют более высокой пропускной способности транзакций в системе? Эти значения можно сравнить при наблюдении за ростом очереди отправки журналов, чтобы определить, что изменилось. Рабочая нагрузка может быть больше, чем обычно. Если скорость отправки журнала меньше обычного, может потребоваться дальнейшее исследование, чтобы определить причину.

Тома рабочей нагрузки имеют значение

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

Диагностика очереди отправки журналов

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

Важно!

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

Система слишком занята

Проверьте, перегружает ли рабочая нагрузка на основном реплика ЦП системы. Если вы видите увеличение очереди отправки журнала, запросите динамическое административное sys.dm_os_schedulers представление и монитор для high runnable_tasks_count. Это число указывает на невыполненные задачи, которые выполнялись в это время.

SELECT scheduler_address, scheduler_id, cpu_id, status, current_tasks_count, runnable_tasks_count, current_workers_count, active_workers_count
FROM sys.dm_os_schedulers

В следующей таблице приведен пример результатов. Увеличение runnable_tasks_count значения указывает на то, что большое количество задач ожидает времени ЦП.

scheduler_address scheduler_id cpu_id status current_tasks_count runnable_tasks_count current_workers_count active_workers_count
0x000002778D 200040 г. 0 0 ВИДИМЫЙ В АВТОНОМНОМ РЕЖИМЕ 1 0 2 1
0x000002778D 220040 г. 1 1 ВИДИМЫЙ В СЕТИ 108 12 115 107
0x000002778D 240040 2 2 ВИДИМЫЙ В СЕТИ 113 2 123 113
0x000002778D 260040 3 3 ВИДИМЫЙ В СЕТИ 105 11 116 105
0x000002778D 480040 4 4 ВИДИМЫЙ В СЕТИ 108 15 117 108
0x000002778D 4A0040 5 5 ВИДИМЫЙ В СЕТИ 100 25 110 99
0x000002778D 4C0040 6 6 ВИДИМЫЙ В СЕТИ 105 23 113 105
0x000002778D 4E0040 7 7 ВИДНЫ 109 25 116 109
0x000002778D 700040 8 8 ВИДИМЫЙ В СЕТИ 98 10 112 98
0x000002778D 720040 9 9 ВИДИМЫЙ В СЕТИ 114 1 130 114
0x000002778D 740040 10 10 ВИДИМЫЙ В СЕТИ 110 25 120 110
0x000002778D 760040 11 11 ВИДИМЫЙ В СЕТИ 83 8 93 83
0x000002778D A00040 12 12 ВИДИМЫЙ В СЕТИ 104 4 117 104
0x000002778D A20040 13 13 ВИДИМЫЙ В СЕТИ 108 32 118 108
0x000002778D A40040 14 14 ВИДИМЫЙ В СЕТИ 102 12 113 102
0x000002778D A60040 15 15 ВИДИМЫЙ В СЕТИ 104 16 116 103

Решение. Если вы обнаружите высокий runnable_task_countуровень, уменьшите рабочую нагрузку в системе или увеличьте количество ЦП, доступных системе.

Задержка сети

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

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

Важно!

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

Проверка задержки в сети

  • Проверьте, влияют ли параметры управления потоком на задержку сети

    Группы доступности Microsoft SQL Server используют шлюзы управления потоком, чтобы избежать чрезмерного использования сетевых ресурсов, памяти и других ресурсов во всех репликах доступности. Эти шлюзы управления потоком не влияют на состояние работоспособности синхронизации реплик доступности. Однако они могут повлиять на общую производительность баз данных доступности, включая RPO.

    Более поздние версии SQL Server изменять пороговые значения, при которых вводится управление потоком. Это может помочь облегчить влияние управления потоком на такие симптомы, как очередь отправки журналов. Дополнительные сведения об управлении потоком и журнале изменений пороговых значений управления потоком см. в разделе Шлюзы управления потоком.

    Вы можете отслеживать управление потоком, используя Монитор производительности для сбора данных на основной реплика. Чтобы отслеживать управление потоком базы данных, добавьте счетчики SQLServer:Database Replica и выберите счетчики Database Flow Control Delay (Задержка управления потоком базы данных ) и Database Flow Controls/sec (Управление потоком базы данных/с ). В диалоговом окне Экземпляр выберите базу данных группы доступности, которую необходимо проверка для управления потоком базы данных. Для обнаружения и мониторинга доступности реплика управления потоком добавьте счетчики SQLServer:Availability Replica и выберите счетчики Время управления потоком (мс/с) и Управление потоком/с.

  • Проверьте, влияет ли перегрузка Windows на задержку в сети

    Проблемы с производительностью сети, которые вызывают очередь отправки журналов, могут быть вызваны тем, что для параметра TCP перезагрузить перегрузку Windows задано значение True. Это был параметр по умолчанию в Windows Server 2016. Убедитесь, что для перезагрузки окна перегрузки установлено значение False на серверах Windows, на которых размещаются реплики групп доступности, на которых наблюдается очередь отправки журналов.

    PS C:\WINDOWS\system32> Get-NetTCPSetting | Select SettingName, CwndRestart

    Снимок экрана, на котором показано, влияет ли перегрузка Перезагрузка Windows на задержку в сети.

    Дополнительные сведения о том, как задать для свойства Tcp Перегрузка Windowsзначение False, см. в разделе Set-NetTCPSetting (NetTCPIP) .

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

  • Использование ping для получения примера задержки

    В командной строке на узле node1 (основной реплика) ping node2 (вторичная реплика):

    C:\Users\customer>ping node2
Pinging node2.customer.corp.company.com [<ip address>] with 32 bytes of data:
Reply from 2001:4898:4018:3005:25f3:d931:2507:e353: time=94ms
Reply from 2001:4898:4018:3005:25f3:d931:2507:e353: time=97ms
Reply from 2001:4898:4018:3005:25f3:d931:2507:e353: time=94ms
Reply from 2001:4898:4018:3005:25f3:d931:2507:e353: time=119ms

Ping statistics for 2<ip address>:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 94ms, Maximum = 119ms, Average = 101ms

  • Тестирование пропускной способности сети от основного к вторичному с помощью независимого средства

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

    Важно!

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

    Вы можете скачать NTttcp на сайте Github — microsoft/ntttcp.

    Чтобы запустить NTttcp, выполните следующие действия.

    1. Скачайте и скопируйте средство на серверы на основе основного и дополнительного SQL Server.

    2. На сервере-получателе реплика откройте окно командной строки с повышенными привилегиями, измените каталог на папку средства NTttcp, а затем выполните следующую команду:

      ntttcp.exe -r -m 1,0,<secondaryipaddress>-a 16 -t 60

      Примечание.

      В этой команде <secondaryipaddress> — заполнитель для фактического IP-адреса вторичного сервера реплика.

    3. На основном сервере реплика откройте окно командной строки с повышенными привилегиями, измените каталог на папку средства NTttcp, а затем выполните следующую команду, еще раз указав фактический IP-адрес дополнительного сервера реплика:

      ntttcp.exe -s -m 1,0,<secondaryipaddress>-a 16 -t 60

      На следующих снимках экрана показана работа NTttcp на вторичной и первичной репликах. Из-за задержки в сети средство может отправлять только 739 КБ/с данных. Это то, что вы можете ожидать, SQL Server сможете отправлять.

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

      Снимок экрана: NTttcp, запущенный на дополнительном реплика.

      NTttcp в первичной реплике

      Снимок экрана: NTttcp, запущенный на основном реплика.

Проверка счетчиков Монитор производительности

Проверьте, что сообщает NTttcp. Большая транзакция выполняется в SQL Server на основном реплика. После запуска Монитор производительности на основной реплика добавьте счетчик Сетевой интерфейс::Байт отправлено/с. Этот счетчик подтверждает, что основной реплика может отправлять около 777 КБ/с данных. Это аналогично значению 739 КБ/с, которое сообщается тестом NTttcp.

Снимок экрана: запуск Монитор производительности.

Также полезно сравнить значение SQL Server::D atabases::Log Bytes Flushed/sec в основном реплика со значением SQL Server::D atabase Replica::Log Bytes Received/sec для той же базы данных на вторичном реплика. В среднем мы наблюдаем около 20 МБ/с изменений, созданных в базе данных agdb. Однако вторичная реплика получает в среднем только 5,4 МБ изменений. Это приведет к постановке в очередь отправки журналов на первичном реплика невыполненных изменений в журнале транзакций базы данных, которые еще не были отправлены во вторичный реплика.

Количество байтов в журнале первичной реплики в секунду для базы данных agdb

Снимок экрана: количество байтов основного реплика журнала.

Получено байтов в журнале вторичной реплики в секунду для базы данных agdb

Снимок экрана: количество полученных дополнительных реплика байтов журнала.