Привіт усім і заздалегідь дякую за допомогу. У нас виникають проблеми з групами доступності 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 із схрещеним кабельним з'єднанням.
Їх вимога полягає в тому, щоб всі бази даних відмовлялися разом, тому їм довелося об'єднати їх у єдину АГ. Це єдина нечитабельна синхронна репліка на ідентичному сервері.
Нові сервери випускаються з червня 2018 року. Останнє оновлення CU (CU7 на той час) та оновлення windows було встановлено, а система працювала добре. Приблизно через місяць, після оновлення серверів з CU7 до CU9, вони почали помічати наступні проблеми, перелічені в порядку пріоритетності.
Ми контролювали сервери за допомогою SQL Sentry і не спостерігали фізичних вузьких місць. Усі ключові показники здаються хорошими. Процесор складає в середньому 20%, час введення-виводу зазвичай менше 1 мс, оперативна пам’ять не використовується повністю, а мережа <1%.
Виклики
Симптоми, схоже, покращуються після відмови, але повертаються протягом декількох днів, незалежно від того, який сервер є основним - симптоми однакові на обох серверах.
Спорадичні клієнтські тайм-аути та збої підключення, такі як
... сталася помилка під час встановлення з'єднання ...
або
Термін закінчення виконання закінчився
Іноді вони триватимуть до 40 секунд, а потім вщухають.
Робота резервного копіювання журналу транзакцій займає 10 разів більше часу, ніж раніше. Раніше для резервного копіювання журналів усіх 500 баз даних було потрібно 3 - 3 хвилини, зараз потрібно 15-25. Ми перевірили, що сам Backup працює з хорошою пропускною здатністю. Однак є невелика затримка після завершення резервного копіювання одного журналу та перед початком наступного. вона починається дуже низько, але через день-два дістається до 2-3 секунд. Помножимо на 500 баз даних, і різниця є.
Іноді деякі, здавалося б, випадкові бази даних застрягають у стані "Не синхронізується" після ручного відмови. Єдиний спосіб вирішити це - або перезапустити сервіс SQL Server у вторинній репліку, або видалити та повторно приєднати ці бази даних до АГ.
Ще одна проблема, введена CU10 (і не вирішена в CU11): підключення до вторинного тайм-ауту при блокуванні на master.sys.databases і навіть не в змозі використовувати провідник об’єктів 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" на репліку доступності "DB" з ідентифікатором репліки: {GUID}. Це лише інформаційне повідомлення. Жодних дій користувача не потрібно.
Підключення AlwaysOn груп доступності з вторинною базою даних, встановленою для первинної бази даних "ABC", на репліці доступності "DB" з ідентифікатором репліки: {GUID}. Це лише інформаційне повідомлення. Жодних дій користувача не потрібно.
Деяких днів є 10 тисяч із них.
У цій статті розглядається однотипний послідовність помилок у SQL 2016, і там написано, що це ненормально. Це також пояснює явище "не синхронізації" після відмови. Питання, яке обговорювалося, було на 2016 рік і було вирішено на початку цього року в МС. однак це єдина відповідна посилання, яку я міг би знайти для перших 2 типів повідомлень, окрім посилань на повідомлення про автоматичну початкову посівку, що тут не повинно бути, оскільки AG вже створено.
Ось підсумок щоденних помилок минулого тижня, для днів, які мали> 10 К помилок на тип у ПЕРВИНЕННІ (вторинне показує "втрата зв'язку з первинним ..."):
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 секунд все повертається до норми з точки зору очікування, але повідомлення АГ продовжують заливати журнали помилок різними темпами та в різний час доби, здавалося б випадкові часи, включаючи години пік. Одночасне збільшення навантаження під час цих сплесків помилок, звичайно, погіршує ситуацію. Якщо лише кілька баз даних відключаються, це, як правило, не спричиняє затримки з’єднань, оскільки вона досить швидко вирішується самостійно.
Ми намагалися переконатись, що це справді було запущено проблему, але нам вдалося повернути обидва вузли лише до CU9. Спроба повернути будь-який вузол до CU8 призвела до того, що той вузол застряг у стані «Розв’язання», показуючи ту саму помилку в журналі:
Неможливо прочитати збережену конфігурацію групи "Завжди увімкнено" з відповідним ідентифікатором ресурсу "…. Постійна конфігурація записана версією SQL Server вищої версії, яка розміщує репліки первинної доступності. Оновіть локальний екземпляр SQL Server, щоб дозволити репліці локальної доступності стати вторинною реплікою.
Це означає, що нам доведеться ввести час вниз, щоб мати можливість одночасно знизити обидва вузли до CU8. Це також говорить про те, що для AG було зроблено значне оновлення, яке може пояснити, що ми відчуваємо.
Ми вже намагалися коригувати max_worker_threads за замовчуванням 0 (= 960 у нашій коробці на основі цієї статті ) поступово до 2000, не спостерігаючи впливу на помилки.
Що ми можемо зробити для вирішення цих АР роз'єднань? Хтось там відчуває подібні проблеми? Чи можуть інші люди з великою кількістю баз даних в АГ можуть бачити подібні повідомлення в журналі помилок SQL, починаючи з CU9 або CU8?
Заздалегідь дякую за будь-яку допомогу!