SQL Server 2017 с 500 базами данных - частое отключение AG с CU9

Привет всем и заранее спасибо за вашу помощь. У нас возникают проблемы с группами доступности SQL Server 2017.

Фон

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

Физические производственные серверы, размещенные в совместном расположении, были недавно обновлены с SQL Server 2014 Enterprise на Windows Server 2012 в общей конфигурации SAN / FCI до SQL Server 2017 Enterprise на Windows Server 2016 на 2-сокетном / 32-ядерном / 768 ГБ ОЗУ и локальном SSD диски с использованием AlwaysOn AG. Трафик AG использует выделенные порты 10G NIC с перекрестным кабельным соединением.

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

Новые серверы работают с июня 2018 года. Установлены последние CU (на тот момент CU7) и обновления Windows, и система работала хорошо. Примерно через месяц после обновления серверов с CU7 до CU9 они начали замечать следующие проблемы, перечисленные в порядке приоритета.

Мы отслеживали серверы с помощью SQL Sentry и не обнаружили никаких физических узких мест. Все ключевые показатели кажутся хорошими. Процессор в среднем составляет 20%, время ввода-вывода обычно меньше 1 мс, ОЗУ используется не полностью, а сеть <1%.

проблемы

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

1. Спорадические тайм-ауты клиента и сбои подключения, такие как

   ... произошла ошибка при установлении соединения ...

   или

   Тайм-аут выполнения истек

   Иногда они продолжаются до 40 секунд, а затем стихают.

2. Задание резервного копирования журнала транзакций выполняется в 10 раз дольше, чем раньше. Раньше на резервное копирование журналов всех 500 баз данных уходило 2–3 минуты, а сейчас - 15–25. Мы убедились, что само Backup работает нормально с хорошей пропускной способностью. Однако есть небольшая задержка после завершения резервного копирования одного журнала и перед запуском следующего. это начинается очень низко, но в течение дня или двух достигает 2-3 секунд. Умножается на 500 баз, и разница есть.

3. Иногда некоторые, казалось бы, случайные базы данных застряли в состоянии «Не синхронизируется» после аварийного переключения вручную. Единственный способ решить эту проблему - перезапустить службу SQL Server на вторичной реплике или удалить и снова присоединить эти базы данных к AG.

4. Еще одна проблема, появившаяся в CU10 (но не решенная в CU11): подключения к вторичному таймауту при блокировке в базах данных master.sys.database и даже невозможность использовать обозреватель объектов SSMS для вторичной реплики. Основная причина, по-видимому, блокируется средством записи VSS Microsoft SQL Server, выдающим следующий запрос:

   select name, 
          recovery_model_desc, 
          state_desc, 
          CONVERT(integer, is_in_standby), 
          ISNULL(source_database_id,0) 
     from master.sys.databases

наблюдения

Кажется, я нашел дымящийся пистолет в журналах ошибок. Журналы ошибок полны сообщений AG, которые помечены как «только информационные», но выглядят так, как будто они не являются нормальными, и их частота очень сильно коррелирует с ошибками приложения.

Ошибки бывают нескольких типов и поступают в последовательности:

• DbMgrPartnerCommitPolicy :: SetSyncState: GUID

• DbMgrPartnerCommitPolicy :: SetSyncAndRecoveryPoint: GUID

• Подключение групп доступности AlwaysOn к вторичной базе данных прервано для первичной базы данных «XYZ» в реплике доступности «БД» с идентификатором реплики: {GUID}. Это только информационное сообщение. От пользователя не потребуется никаких действий.

• AlwaysOn Availability Groups устанавливает соединение с вторичной базой данных для первичной базы данных «ABC» в реплике доступности «DB» с идентификатором реплики: {GUID}. Это только информационное сообщение. От пользователя не потребуется никаких действий.

В некоторые дни их десятки тысяч.

В этой статье обсуждается тот же тип последовательности ошибок в SQL 2016, и там говорится, что это ненормально. Это также объясняет явление «несинхронизации» после отработки отказа. Обсуждаемая проблема касалась 2016 года и была исправлена ​​ранее в этом году в ТС. тем не менее, это единственная релевантная ссылка, которую я смог найти для первых 2 типов сообщений, кроме ссылок на сообщения об автоматическом начальном заполнении, которые не должны быть здесь, поскольку AG уже установлена.

Вот сводка ежедневных ошибок на прошлой неделе для дней, в которых было более 10 000 ошибок на тип в PRIMARY (вторичный показывает «потеря соединения с первичным ...»):

Date        Message Type (First 50 characters)                  Num Errors
10/8/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  61953
10/3/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  56812
10/4/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  27951
10/2/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  24158
10/7/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  14904
10/8/2018   Always On Availability Groups connection with seco  13301
10/3/2018   DbMgrPartnerCommitPolicy::SetSyncState: 783CAF81-4  11057
10/3/2018   Always On Availability Groups connection with seco  10080

Мы также иногда видим «странные» сообщения, такие как:

База данных группы доступности «DB» меняет роли с «SECONDARY» на «SECONDARY», потому что сеанс зеркального отображения или группа доступности перенесены из-за синхронизации ролей. Это только информационное сообщение. От пользователя не потребуется никаких действий.

... среди множества изменяющихся состояний с "ВТОРИЧНОГО" на "РАЗРЕШЕНИЕ".

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

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

Мы попытались проверить, что это действительно CU9, который начал проблему, но мы смогли понизить оба узла только до CU9. Попытки понизить любой узел до CU8 привели к тому, что этот узел застрял в состоянии «Разрешение», показывая ту же ошибку в журнале:

Не удается прочитать постоянную конфигурацию группы доступности Always On с соответствующим идентификатором ресурса '…. Постоянная конфигурация записывается более поздней версией SQL Server, на котором размещена первичная реплика доступности. Обновите локальный экземпляр SQL Server, чтобы локальная реплика доступности стала вторичной репликой.

Это означает, что нам придется ввести время простоя, чтобы иметь возможность одновременно понизить оба узла до CU8. Это также говорит о том, что в AG было какое-то серьезное обновление, которое может объяснить, что мы испытываем.

Мы уже пытались корректировать max_worker_threads с его значения по умолчанию 0 (= 960 для нашего бокса, основанного на этой статье ) постепенно до 2000 без видимого влияния на ошибки.

Что мы можем сделать, чтобы решить эти разъединения AG? Кто-нибудь испытывает подобные проблемы? Могут ли другие люди с большим количеством баз данных в AG увидеть подобные сообщения в журнале ошибок SQL, начиная с CU9 или CU8?

Заранее благодарю за любую помощь!

Обновить:

1. Отключения группы доступности были подтверждены как регрессия, введенная CU9, и они были устранены после установки CU12.

2. Проблемы блокировки на вторичной реплике были подтверждены как проблема с обновлением кода модуля записи VSS, который был представлен в CU10. Надеемся, что это будет решено в CU 13. Промежуточное решение состоит в том, чтобы вручную заменить библиотеки записи VSS на библиотеки DLL библиотеки Pre-CU10 ...

   BEGIN RANT-SACTION;

   К сожалению, Microsoft, похоже, неоднократно не могла должным образом обеспечить контроль не только обновлений Windows 10, но и критически важного программного обеспечения предприятия, такого как SQL Server.

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

   COMMIT RANT-SACTION;

Вы проверили рабочие темы? Обычно всегда используется больше рабочих потоков для работы, и обычно значения по умолчанию недостаточно. У меня была та же проблема с 600 базами данных в постоянно включенном состоянии, поэтому мы добавили больше потоков к параметру экземпляра, и это решило нашу проблему. Надеюсь это поможет!