Привет всем и заранее спасибо за вашу помощь. У нас возникают проблемы с группами доступности 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%.
проблемы
Симптомы, похоже, улучшаются после отработки отказа, но возвращаются в течение нескольких дней, независимо от того, какой сервер является основным - симптомы идентичны на обоих серверах.
Спорадические тайм-ауты клиента и сбои подключения, такие как
... произошла ошибка при установлении соединения ...
или
Тайм-аут выполнения истек
Иногда они продолжаются до 40 секунд, а затем стихают.
Задание резервного копирования журнала транзакций выполняется в 10 раз дольше, чем раньше. Раньше на резервное копирование журналов всех 500 баз данных уходило 2–3 минуты, а сейчас - 15–25. Мы убедились, что само Backup работает нормально с хорошей пропускной способностью. Однако есть небольшая задержка после завершения резервного копирования одного журнала и перед запуском следующего. это начинается очень низко, но в течение дня или двух достигает 2-3 секунд. Умножается на 500 баз, и разница есть.
Иногда некоторые, казалось бы, случайные базы данных застряли в состоянии «Не синхронизируется» после аварийного переключения вручную. Единственный способ решить эту проблему - перезапустить службу SQL Server на вторичной реплике или удалить и снова присоединить эти базы данных к AG.
Еще одна проблема, появившаяся в 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?
Заранее благодарю за любую помощь!