SQL Server Групи доступності Always On [Посібник 2026]

Групи доступності Always On (AG) – це SQL Server Enterprise висока доступність та рішення для аварійного відновлення, яке працює на рівні бази даних. Група доступності об'єднує одну або кілька баз даних користувачів в єдиний блок відновлення після збою та реплікує їх до восьми вторинних реплік шляхом безперервної доставки журналу транзакцій. Коли первинна репліка виходить з ладу, призначена синхронна вторинна репліка автоматично бере на себе її роботу, відновлюючи доступ за лічені секунди без спільного сховища чи ручного втручання.

1.2 Групи доступності Always On проти екземплярів відмовостійкого кластера

SQL Server Always On включає дві окремі технології: групи доступності (AG) та екземпляри відмовостійкого кластера (FCI):

	Завжди доступні групи доступності	Екземпляри кластера AlwaysOn Failover
Область резервного перемикання	Рівень бази даних	На рівні екземпляра (всі бази даних одночасно перемикаються на резервний комп'ютер)
Тиражування даних	Реплікація на основі журналів до кожного вторинного	Немає — усі вузли використовують одне й те саме сховище
Спільне сховище	Не потрібно	Обов'язково (мережа зберігання даних (SAN), iSCSI, S2D або SMB)
Читабельні вторинні	Так	Немає
Аварійного відновлення	Вбудований (асинхронні репліки на різних сайтах)	Не вбудовано без сполучення з AG

Коли використовувати кожен з них: Використовуйте FCI, коли вам потрібне резервне копіювання на рівні екземпляра та ви вже маєте спільну інфраструктуру сховища. Використовуйте AG, коли вам потрібна гранулярність на рівні бази даних, читабельні вторинні ресурси або аварійне відновлення. Для найповнішого захисту поєднайте обидва варіанти: запускайте кожну репліку як вузол FCI та зв’язуйте їх в AG.

1.3 Переваги та обмеження

Переваги:

Автоматичне перемикання на резервний комп'ютер з майже нульовим цільовим часом відновлення (RTO) для синхронних реплік;
нульова втрата даних (цільова точка відновлення (RPO) = 0) у режимі синхронної фіксації;
спільне сховище не потрібне — кожна репліка використовує незалежне локальне сховище;
читабельні вторинні сервери розвантажують робочі навантаження звітності та резервного копіювання з основного;
підтримує як локальну високу доступність (HA), так і міжсайтове аварійне відновлення (DR) в рамках однієї конфігурації.

Обмеження:

Потрібна кластеризація Windows Server Failover Clustering на всіх репліках;
Enterprise Edition для повного набору функцій (Standard Edition підтримує Basic AG зі значними обмеженнями);
режим синхронного фіксування додає затримку до операцій запису, пропорційну часу обміну даними в мережі;
логіни, завдання агента SQL та підключені сервери не синхронізуються автоматично в SQL Server 2019 та раніше (вирішено в SQL Server 2022 містив групи доступності).

2. Архітектура груп доступності Always On

2.1 Основні компоненти та концепції

2.1.1 Бази даних доступності

Бази даних доступності – це бази даних користувачів, що беруть участь у групі доступності. Ці бази даних повинні відповідати певним вимогам: вони повинні використовувати модель повного відновлення, мати повну резервну копію та існувати на основній репліці, перш ніж їх буде додано до групи доступності.

Коли база даних приєднується до групи доступності, вона стає частиною синхронізованого набору, який переходить на резервне копіювання як єдине ціле. Усі бази даних у групі доступності мають однаковий стан перемикання на резервне копіювання, тобто якщо основна репліка виходить з ладу, усі бази даних одночасно перемикаються на ту саму вторинну репліку. Це забезпечує узгодженість для програм, які покладаються на кілька пов'язаних баз даних.

2.1.2 Репліки доступності

Репліки доступності є SQL Server екземпляри, що містять копії баз даних доступності. Кожна репліка зберігає власну фізичну копію баз даних, синхронізовану через доставку записів журналу транзакцій. Група доступності може містити до дев'яти реплік: одну основну репліку та до восьми вторинних реплік.

2.1.3 Первинна репліка

Первинна репліка містить копію баз даних доступності для читання та запису. Усі зміни даних (INSERT, UPDATE, DELETE) відбуваються на первинній репліці. Клієнтські програми підключаються до первинної репліки для всіх операцій запису, а за замовчуванням і для операцій читання.

2.1.4 Вторинні репліки

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

2.2 Режими доступності

2.2.1 Режим синхронного фіксування

Режим синхронного фіксування транзакцій забезпечує захист від втрати даних, вимагаючи від основної репліки очікування підтвердження того, що записи журналу транзакцій були захищені на вторинній репліці, перш ніж фіксувати транзакції. Цей режим є важливим для конфігурацій високої доступності, де втрата даних неприйнятна.

2.2.2 Режим асинхронного фіксування змін

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

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

2.3 Типи резервного перемикання

2.3.1 Автоматичне перемикання на резервний комп'ютер

Автоматичне перемикання на резервний комп’ютер дозволяє групі доступності виявляти збій основної репліки та автоматично переводити вторинну репліку на основну без втручання адміністратора. Ця можливість мінімізує час відновлення (RTO), усуваючи необхідність ручного реагування на збої.

Для автоматичного перемикання на резервний комп’ютер потрібен режим синхронної фіксації, щоб забезпечити нульову втрату даних. Якщо цю функцію ввімкнено, група доступності постійно контролює стан основної репліки. Якщо основна репліка перестає відповідати або виходить з ладу, кластер перемикання на резервний комп’ютер Windows Server ініціює автоматичне перемикання на призначену вторинну репліку.

2.3.2 Ручне перемикання на резервний ПК

Ручне перемикання на резервний архів дозволяє адміністраторам навмисно перемикати роль основної репліки на вторинну, зазвичай для цілей планового обслуговування або тестування. На відміну від автоматичного перемикання на резервний архів, ручне перемикання на резервний архів вимагає явних дій адміністратора для його запуску.

Для реплік із синхронним фіксуванням доступне ручне перемикання на резервний архів без втрати даних. Адміністратор ініціює перемикання на резервний архів через SQL Server Management Studio, Transact-SQL або PowerShell. Первинна репліка завершує обробку поточних транзакцій, надсилає всі записи журналу, що залишилися, до цільової вторинної репліки та очікує підтвердження перед передачею основної ролі.

Ручне перемикання на резервний архів також може відбуватися з репліками з асинхронним фіксуванням, але це вимагає примусового перемикання на резервний архів із можливою втратою даних. Адміністратори повинні використовувати примусове ручне перемикання на резервний архів лише під час реальних аварійних сценаріїв, коли основна репліка недоступна, а втрата даних є прийнятною порівняно з тривалим простоєм.

2.3.3 Примусове перемикання на резервний комп'ютер

Примусове перемикання на резервний сервер дозволяє перемикатися на асинхронну вторинну репліку або на вторинну репліку, яка не повністю синхронізована, з явним підтвердженням потенційної втрати даних. Цей варіант слугує крайнім заходом, коли первинна репліка недоступна, а синхронізована вторинна репліка не існує.

2.4 Синхронізація даних

2.4.1 Як працює синхронізація даних

Синхронізація даних у групах доступності Always On відбувається шляхом безперервної доставки записів журналу транзакцій з основної репліки до всіх вторинних реплік. Така синхронізація на основі журналів забезпечує узгодженість, водночас дозволяючи незалежне зберігання для кожної репліки.

2.4.2 Записи журналу транзакцій та посилення захисту

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

2.5 Вторинні репліки масштабу читання та репліки з можливістю читання

2.5.1 Розвантаження робочих навантажень лише для читання

Зчитувані вторинні репліки дозволяють організаціям розвантажувати з первинної репліки навантаження, що потребує інтенсивного читання, покращуючи загальну продуктивність системи та використання ресурсів. Ця можливість масштабування читання є однією з ключових переваг груп доступності порівняно зі старими рішеннями високої доступності.

Організаціям слід враховувати вимоги до робочого навантаження лише для читання під час розробки конфігурацій груп доступності. Кілька вторинних серверів з можливістю читання можуть розподіляти навантаження звітності між кількома серверами. Списки маршрутизації лише для читання визначають порядок, у якому вторинні сервери отримують з’єднання з наміром читання, що дозволяє використовувати стратегії балансування навантаження.

2.5.2 Операції резервного копіювання на вторинних репліках

Запуск резервних копій на вторинних репліках зменшує навантаження на операції вводу/виводу (I/O) та центральний процесор (CPU) на первинній репліці, дозволяючи їй зосередитися на транзакційних навантаженнях. Ця можливість допомагає організаціям виконувати вимоги до резервного копіювання, не впливаючи на продуктивність виробництва.

SQL Server Підтримує повне резервне копіювання бази даних, диференціальне резервне копіювання та резервне копіювання журналів транзакцій на вторинних репліках. Параметри резервного копіювання можна налаштувати так, щоб надавати перевагу вторинним реплікам, первинній, лише вторинній або будь-якій репліці. Система резервного копіювання автоматично вибирає відповідну репліку на основі цих налаштувань та поточної доступності.

Детальніше про SQL Server резервне копіювання, див. наш вичерпний посібник.

2.6 Слухачі групи доступності

2.6.1 Що таке слухач?

Слухач групи доступності – це ім’я віртуальної мережі (VNN) та IP-адреса, які клієнтські програми використовують для підключення до баз даних групи доступності. Слухач автоматично перенаправляє підключення до поточної основної репліки, що усуває необхідність для програм відстежувати, який сервер наразі є основним.

2.6.2 Маршрутизація клієнтських з'єднань

Маршрутизація клієнтських з'єднань через слухач підтримує як наміри з'єднання для читання-запису, так і для читання-лише для читання. Слухач аналізує запит на з'єднання та спрямовує його до відповідної репліки на основі наміру застосунку.

3. Передумови та вимоги

3.1 Кластеризація Windows Server для відмовостійкості груп доступності

3.1.1 Основи відмовостійкого кластерування Windows Server

Кластеризація відмовостійкості Windows Server (WSFC) забезпечує основу для груп доступності Always On, керуючи членством у кластері, моніторингом справності та оркестрацією відмовостійкості. На відміну від екземплярів кластерів відмовостійкості, групи доступності використовують WSFC лише для координації кластера, а не для керування спільним сховищем.

Кожен SQL Server Екземпляр, що бере участь у групі доступності, має бути вузлом у кластері WSFC. Кластер керує голосуванням кворуму, виявленням справності вузлів та станом ресурсів групи доступності. Коли основна репліка виходить з ладу, WSFC координує процес відновлення після відмови та оновлює ресурси кластера, щоб відобразити нову основну репліку.

3.1.2 Конфігурація кворуму кластера

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

Для груп доступності доступні кілька режимів кворуму:

Більшість вузлів використовує лише голоси вузлів кластера та добре працює для кластерів з непарною кількістю вузлів.
Більшість вузлів та спільних файлів додає голос свідка спільного доступу до файлів, що підходить для кластерів вузлів з парною кількістю.
Node and Disk Majority використовує дисковий свідок, але менш поширений для груп доступності, оскільки спільне сховище не потрібне.

3.1.3 Кластеризація кількох підмереж

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

3.2 SQL Server Вимоги до видання

3.2.1 Функції корпоративної версії

SQL Server Видання Enterprise Edition надає повний функціонал груп доступності без обмежень. Видання Enterprise Edition підтримує до восьми вторинних реплік, читабельні вторинні репліки, автоматичне заповнення, розподілені групи доступності та всі розширені функції.

3.2.2 Функції стандартного випуску (базові групи доступності)

SQL Server Стандартна версія 2016 року та пізніші версії підтримують базові групи доступності зі значними обмеженнями. Базові групи доступності забезпечують основні функції високої доступності за нижчою ціною, що підходить для організацій із простішими вимогами.

4. Налаштування груп доступності Always On

4.1 Підготовка середовища

Перед створенням групи доступності середовище має бути належним чином підготовлене, з обліковими записами Active Directory, конфігураціями сервера та мережевою інфраструктурою.

4.1.1 Налаштування контролера домену

Контролер домену Active Directory має бути налаштований для підтримки кластера групи доступності та SQL Server облікові записи послуг.

Увійдіть до контролера домену, використовуючи облікові дані адміністратора домену.
відкритий Server Manager і перейдіть до Інструменти -> Користувачі Active Directory та комп'ютери.
Створити організаційний підрозділ для SQL Server об'єкти, якщо такого не існує.
Перевірте, чи існують об'єкти комп'ютерів для всіх вузлів кластера в Active Directory.
Переконайтеся, що служби системи доменних імен (DNS) налаштовані належним чином, а всі імена серверів розпізнаються правильно.

4.1.2 Створення облікових записів служби

Створення виділених облікових записів служби Active Directory для SQL Server послуги на кожному вузлі.

відкритий Користувачі Active Directory та комп'ютери на контролері домену.
Клацніть правою кнопкою миші відповідний організаційний підрозділ і виберіть Нові -> користувач.
Введіть ім'я облікового запису служби (наприклад, svc_SQLServer) та встановіть Ім'я користувача для входу.
Натисніть Далі і введіть надійний пароль.
Виберіть Користувач не може змінити пароль та Термін дії пароля ніколи не закінчується.
Натисніть Далі ,а потім обробка щоб створити обліковий запис.
Повторіть для будь-яких додаткових необхідних облікових записів служб (SQL Server Агент, SSRS тощо).

4.1.3 Налаштування дозволів адміністратора

Облікові записи служб та облікові записи, що використовуються для налаштування SQL Server повинні мати відповідні дозволи на всіх вузлах кластера.

Увійдіть до кожного сервера вузла кластера.
відкритий управління комп'ютером від Старт меню або Диспетчер сервера.
Розширювати Локальні користувачі та групи і виберіть груп.
Клацніть правою кнопкою миші адміністратори і виберіть властивості.
Натисніть додавати та введіть назву облікового запису служби.
Натисніть Перевірити імена щоб підтвердити обліковий запис, а потім натисніть OK.
Натисніть OK щоб закрити діалогове вікно «Властивості адміністратора».
Повторіть на всіх вузлах кластера.

4.2 Встановлення та налаштування WSFC

Перш ніж увімкнути групи доступності Always On, на всіх вузлах необхідно встановити та налаштувати кластеризацію Windows Server Failover Clustering.

4.2.1 Встановлення функції кластеризації після відмови

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

відкритий Server Manager на першому вузлі кластера.
Натисніть керувати -> Додайте ролі та функції.
Натисніть Далі через вступні екрани.
Виберіть Встановлення на основі ролей або функцій і натисніть кнопку Далі.
Виберіть локальний сервер і натисніть Далі.
Пропустіть екран «Ролі» та натисніть Далі.
На екрані Функції виберіть Відмовостійка кластеризація.
Натисніть Додати функції коли буде запропоновано додати інструменти керування.
Натисніть Далі ,а потім Встановлювати.
Дочекайтеся завершення встановлення та натисніть Закрити.
Повторіть на всіх серверах, які братимуть участь у кластері.

4.2.2 Створення кластера відновлення після відмови

Після інсталяції функції кластеризації відмов на всіх вузлах створіть кластер з одного вузла.

відкритий Відмовний менеджер кластерів від Server Manager -> Інструменти.
Натисніть Створити кластер на панелі дій.
Натисніть Далі на сторінці «Перш ніж почати».
Натисніть Вклеїти та додайте всі сервери, які будуть вузлами кластера.
Натисніть Далі після додавання всіх вузлів.
Залишати Виконати всі тести (рекомендовано) вибрано та клацніть Далі.
Перегляньте результати перевірки валідації та виправте будь-які помилки або попередження.
Натисніть обробка після успішного завершення перевірки.
Введіть назву кластера та IP-адресу.
Зніміть прапорець Додайте всі придатні сховища до кластера оскільки спільне сховище не потрібне.
Натисніть Далі та перегляньте підтвердження.
Натисніть обробка щоб створити кластер.

4.2.3 Перевірка конфігурації кластера

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

In Відмовний менеджер кластерів, клацніть правою кнопкою миші назву кластера.
Виберіть Перевірити кластер з меню.
Натисніть Далі на сторінці «Перш ніж почати».
Виберіть Виконати всі тести (рекомендовано) і натисніть кнопку Далі.
Натисніть Далі щоб розпочати перевірочні випробування.
Перегляньте звіт про валідацію після завершення тестів.
Усуньте будь-які збої або попередження, виявлені у звіті.
Натисніть обробка щоб закрити майстер.

НІКОЛИ не встановлюючи SQL Server для груп доступності

Встановлювати SQL Server на кожному вузлі, який братиме участь у групі доступності, використовуючи варіант автономної інсталяції.

Запустіть SQL Server інсталяційний носій на першому вузлі.
Виберіть Нові SQL Server автономна установка.
Введіть ключ продукту або виберіть пробну версію.
Прийміть умови ліцензії та натисніть Далі.
Виконайте перевірку попередніх вимог та вирішіть будь-які проблеми.
На сторінці «Вибір функцій» виберіть Служби механізму баз даних.
Налаштуйте ім'я екземпляра (використовуйте однакове ім'я екземпляра на всіх вузлах).
На сторінці конфігурації сервера вкажіть облікові дані облікового запису служби.
Налаштуйте типи запуску служб як автоматичний.
На сторінці конфігурації об'єкта баз даних виберіть режим автентифікації.
Додайте облікові записи адміністраторів.
Налаштуйте каталоги даних, використовуючи узгоджені шляхи на всіх вузлах.
Завершіть встановлення та перевірте його успішність.
Повторіть встановлення на всіх інших вузлах кластера з ідентичними налаштуваннями.

4.4 Увімкнення функції груп доступності «Завжди ввімкнено»

після установки SQL Server на всіх вузлах увімкніть функцію груп доступності Always On на кожному екземплярі.

4.4.1 Увімкнення через SQL Server Менеджер конфігурацій

Скористайтеся кнопкою SQL Server Диспетчер конфігурацій для ввімкнення груп доступності Always On через графічний інтерфейс.

відкритий SQL Server Менеджер конфігурацій на першому вузлі.
Розширювати SQL Server Послуги на лівій панелі.
Клацніть правою кнопкою миші SQL Server екземпляр і виберіть властивості.
Натисніть Висока доступність AlwaysOn .
перевірити Увімкнути групи доступності AlwaysOn.
Перевірте правильність назви кластера відновлення після відмови Windows.
Натисніть OK зберегти зміни.
Натисніть OK на попередження про те, що службу необхідно перезапустити.
Клацніть правою кнопкою миші SQL Server послугу та виберіть перезапуск.
Зачекайте успішного перезапуску служби.
Повторіть на всіх вузлах кластера.

4.4.2 Увімкнення через PowerShell

PowerShell надає сценарний метод для ввімкнення груп доступності Always On на кількох вузлах.

Відкрийте PowerShell від імені адміністратора на першому вузлі.
Імпортуйте SQL Server Модуль PowerShell:
```
Import-Module SQLPS -DisableNameChecking
```

Увімкнути групи доступності Always On:

Enable-SqlAlwaysOn -ServerInstance "ServerName\InstanceName" -Force

Служба автоматично перезавантажиться під час використання параметра Force.

Перевірте, чи функцію ввімкнено:

Get-ItemProperty "SQLSERVER:\SQL\ServerName\InstanceName" | Select-Object IsHadrEnabled

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

4.4.3 Перевірка ввімкнення функції

Перш ніж продовжувати налаштування, переконайтеся, що групи доступності Always On увімкнено на всіх екземплярах.

Підключіться до кожного SQL Server використання екземпляра SQL Server Студія управління.
Відкрийте нове вікно запиту та виконайте команду:
```
SELECT SERVERPROPERTY('IsHadrEnabled')
```
Перевірте, чи результат дорівнює 1 (увімкнено).
Перевірте, чи SQL Server Екземпляр відображається в диспетчері кластерів відновлення після відмов у розділі ролей кластера.
Перевірте існування кінцевої точки групи доступності, виконавши команду:
```
SELECT * FROM sys.endpoints WHERE type_desc = 'DATABASE_MIRRORING'
```
Якщо кінцева точка не існує, її буде створено під час створення групи доступності.

4.5 Підготовка баз даних для груп доступності

Бази даних повинні відповідати певним вимогам, перш ніж їх можна буде додати до групи доступності.

4.5.1 Вимоги до моделі відновлення бази даних

Змініть модель відновлення бази даних на ПОВНУ на основній репліці, перш ніж додавати її до групи доступності.

Підключіться до основної репліки за допомогою SQL Server Студія управління.
Клацніть правою кнопкою миші на базі даних і виберіть властивості.
Оберіть Опції стр.
Редагувати Модель відновлення до Повний.
Натисніть OK щоб зберегти зміни.
Або ж використовуйте Transact-SQL:
```
ALTER DATABASE DatabaseName SET RECOVERY FULL;
```

4.5.2 Створення повних резервних копій бази даних

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

In SQL Server У Management Studio клацніть правою кнопкою миші на базі даних.
Виберіть Завдання -> Підтримувати.
Перевірити Тип резервного копіювання встановлений в Повний.
Виберіть місце для резервного копіювання або додайте нове місце призначення.
Натисніть OK щоб виконати резервне копіювання.

Або ж використовуйте Transact-SQL:

BACKUP DATABASE DatabaseName TO DISK = 'C:\Backup\DatabaseName.bak';

4.5.3 Створення резервних копій журналу транзакцій

Зробіть резервну копію журналу транзакцій, щоб переконатися, що ланцюжок журналів встановлено, та мінімізувати час ініціалізації.

In SQL Server У Management Studio клацніть правою кнопкою миші на базі даних.
Виберіть Завдання -> Підтримувати.
Редагувати Тип резервного копіювання до Журнал транзакцій.
Виберіть місце для резервного копіювання.
Натисніть OK щоб виконати резервне копіювання.

Або ж використовуйте Transact-SQL:

BACKUP LOG DatabaseName TO DISK = 'C:\Backup\DatabaseName.trn';

4.6 Створення групи доступності

Створіть групу доступності за допомогою одного з кількох доступних методів, залежно від ваших уподобань та вимог до автоматизації.

4.6.1 Використання майстра створення групи доступності

Майстер створення груп доступності надає графічний інтерфейс для створення груп доступності.

In SQL Server Management Studio, підключіться до екземпляра, в якому розміщуватиметься основна репліка.
Розширювати Висока доступність AlwaysOn у Провіднику об'єктів.
Клацніть правою кнопкою миші Групи доступності і виберіть Майстер нової групи доступності.
Натисніть Далі на сторінці «Вступ».
Введіть назву групи доступності та натисніть кнопку Далі.
На сторінці «Вибір баз даних» виберіть бази даних, які потрібно включити.
Перевірте, чи бази даних відповідають усім попереднім вимогам, і натисніть кнопку Далі.
На сторінці «Вказати репліки» натисніть кнопку Додати репліку.
Підключіться до кожного екземпляра вторинної репліки.
Налаштуйте властивості репліки для кожного екземпляра (режим доступності, режим відновлення після відмови).
Натисніть Кінцеві точки вкладку та перегляньте конфігурацію кінцевої точки.
Натисніть Налаштування резервного копіювання вкладку та налаштуйте пріоритети резервного копіювання.
Натисніть слухач вкладку та за потреби створіть слухач.
Натисніть Далі та виберіть метод синхронізації даних.
Перегляньте результати перевірки та вирішіть будь-які проблеми.
Натисніть Далі та перегляньте короткий зміст.
Натисніть обробка щоб створити групу доступності.
Слідкуйте за прогресом та перевіряйте успішне створення.

4.6.2 Використання Transact-SQL

Створюйте групи доступності за допомогою Transact-SQL для сценарійних, повторюваних розгортань.

Створіть групу доступності на основній репліці:

CREATE AVAILABILITY GROUP AG_Name
FOR DATABASE DatabaseName
REPLICA ON
  'PrimaryServer\Instance' WITH
    (ENDPOINT_URL = 'TCP://PrimaryServer:5022',
     AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
     FAILOVER_MODE = AUTOMATIC,
     SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL)),
  'SecondaryServer\Instance' WITH
    (ENDPOINT_URL = 'TCP://SecondaryServer:5022',
     AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
     FAILOVER_MODE = AUTOMATIC,
     SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL));

Приєднайте вторинну репліку до групи доступності:
```
ALTER AVAILABILITY GROUP AG_Name JOIN;
```
Приєднатися до вторинної бази даних:
```
ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;
```

4.6.3 Використання PowerShell

PowerShell надає можливості сценаріїв для створення та керування групами доступності.

Створіть об'єкт групи доступності:

$AG = New-SqlAvailabilityGroup -Name "AG_Name" -Path "SQLSERVER:\SQL\PrimaryServer\Instance"

Додати бази даних:

Add-SqlAvailabilityDatabase -Path "SQLSERVER:\SQL\PrimaryServer\Instance\AvailabilityGroups\AG_Name" -Database "DatabaseName"

Налаштуйте репліки з потрібними властивостями за допомогою командлета New-SqlAvailabilityReplica.
Об’єднайте вторинні репліки за допомогою командлета Join-SqlAvailabilityGroup.

4.7 Додавання реплік до групи доступності

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

4.7.1 Налаштування властивостей репліки

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

In SQL Server Студія управління, розгорнути Висока доступність AlwaysOn -> Групи доступності.
Розгорніть групу доступності, а потім розгорніть Репліки доступності.
Клацніть правою кнопкою миші на репліці та виберіть властивості.
Перегляньте та змініть параметри підключення для основної та додаткової ролей.
За потреби налаштуйте значення часу очікування сеансу.
Натисніть OK щоб зберегти зміни.

4.7.2 Налаштування режимів доступності

Налаштуйте режим доступності для керування поведінкою синхронізації між репліками.

Клацніть правою кнопкою миші групу доступності та виберіть властивості.
Перейдіть на вкладку Загальне сторінку, перейдіть до Репліки доступності .
Для кожної репліки виберіть Синхронний коміт or Асинхронний коміт з випадаючого.
Використовуйте синхронне фіксування (commit) для локальних реплік високої доступності.
Використовуйте асинхронне підтвердження (commit) для географічно віддалених реплік аварійного відновлення.
Натисніть OK щоб зберегти конфігурацію.

4.7.3 Налаштування режимів резервного перемикання

Налаштуйте режим відновлення, щоб контролювати, як відбувається відновлення для кожної репліки.

Клацніть правою кнопкою миші групу доступності та виберіть властивості.
Перейдіть на вкладку Загальне сторінку, перейдіть до Репліки доступності .
Для синхронних реплік фіксації виберіть автоматичний or Мануал режим перемикання на резервний рахунок.
Автоматичне перемикання на резервне копіювання вимагає режиму синхронного підтвердження та забезпечує автоматичне перемикання на резервне копіювання.
Для асинхронних реплік фіксації доступне лише ручне перемикання на резервний архів.
Налаштуйте до трьох реплік для автоматичного перемикання на резервний комп’ютер (одну основну та дві додаткові).
Натисніть OK , щоб застосувати параметри.

4.7.4 Налаштування параметрів резервного копіювання

Налаштуйте параметри резервного копіювання, щоб контролювати, де мають виконуватися операції резервного копіювання.

Клацніть правою кнопкою миші групу доступності та виберіть властивості.
Виберіть Налаштування резервного копіювання на лівій панелі.
Виберіть один із параметрів резервного копіювання:
- Віддаю перевагу вторинномуРезервні копії на вторинному сервері, якщо вони доступні, інакше на первинному.
- Тільки вторинніРезервні копії лише на вторинних репліках
- ПервиннийРезервні копії лише на первинній репліці
- Будь-яка реплікаРезервні копії будь-якої доступної репліки
Встановіть значення пріоритету резервного копіювання для кожної репліки (0-100).
Вищі значення пріоритету вказують на бажані цілі резервного копіювання.
Натисніть OK щоб зберегти налаштування.

4.8 Налаштування слухача групи доступності

Створіть слухач, щоб забезпечити єдину точку підключення, яка автоматично перенаправляє на поточну основну репліку.

4.8.1 Створення слухача

Додайте слухач до групи доступності для керування підключеннями клієнтів.

In SQL Server У Management Studio розгорніть групу доступності.
Клацніть правою кнопкою миші Слухачі групи доступності і виберіть Додати слухача.
Введіть DNS-ім’я для слухача (наприклад, AG_Listener).
Введіть номер порту (за замовчуванням — 1433).
Виберіть Статична IP для мережевого режиму.
Натисніть додавати щоб додати IP-адресу для кожної підмережі.
Введіть IP-адресу та виберіть підмережу.
Натисніть OK створити слухача.
Переконайтеся, що слухач відображається в провіднику об'єктів і перебуває в мережі.

4.8.2 Налаштування параметрів DNS та IP

Перевірте реєстрацію DNS та конфігурацію мережі для слухача.

Відкрийте DNS-менеджер на контролері домену.
Перевірте, чи ім'я слухача зареєстровано з усіма IP-адресами.
Перевірка розв'язання DNS-запитів з клієнтських машин:
```
nslookup ListenerName
```
Перевірте, чи повертаються всі налаштовані IP-адреси.
У диспетчері кластерів відновлення відмов розгорніть Ролі і виберіть групу доступності.
Перевірте, чи ресурси IP-адреси доступні в Інтернеті.
Перевірте, чи ресурс мережевого імені доступний в Інтернеті.

4.8.3 Тестування підключення слухача

Перевірте, чи клієнтські програми можуть підключатися через слухач.

З клієнтської машини відкрийте SQL Server Студія управління.
Підключіться, використовуючи ім'я слухача замість імені сервера.
Виконайте запит для перевірки підключення до поточної основної репліки:
```
SELECT @@SERVERNAME;
```
Перевірте маршрутизацію намірів читання, додавши ApplicationIntent=ReadOnly до рядка підключення.
Перевірте перенаправлення з'єднання на читабельну вторинну репліку.
Перевірте відновлення після відмови, вручну переключивши групу доступності на резервне копіювання та перевіривши повторне підключення.

4.9 Методи синхронізації даних

Виберіть метод синхронізації даних для ініціалізації вторинних реплік копіями бази даних.

4.9.1 Автоматичний висів

Автоматичне заповнення передає дані бази даних по мережі без необхідності ручного резервного копіювання та відновлення.

Під час створення групи доступності виберіть Автоматичний посів як метод синхронізації.
Забезпечте мережеве з’єднання та достатню пропускну здатність між репліками.
Первинна репліка автоматично передає дані бази даних на вторинні репліки.
Відстежуйте перебіг заповнення за допомогою панелі інструментів групи доступності або DMV.
Автоматичний посів вимагає SQL Server 2016 або пізнішої версії.
Для великих баз даних враховуйте вплив мережі та плануйте виконання на періоди низького використання.

4.9.2 Ручне заповнення (резервне копіювання та відновлення)

Ручне заповнення включає створення резервних копій на первинному сервері та їх відновлення на вторинних репліках.

На первинній репліці зробіть повну резервну копію:
```
BACKUP DATABASE DatabaseName TO DISK = '\\SharePath\DatabaseName.bak';
```
Зробіть резервну копію журналу транзакцій:
```
BACKUP LOG DatabaseName TO DISK = '\\SharePath\DatabaseName.trn';
```
На кожній вторинній репліці відновіть повну резервну копію:
```
RESTORE DATABASE DatabaseName FROM DISK = '\\SharePath\DatabaseName.bak' WITH NORECOVERY;
```

Відновлення резервної копії журналу:

RESTORE LOG DatabaseName FROM DISK = '\\SharePath\DatabaseName.trn' WITH NORECOVERY;

Приєднайте базу даних до групи доступності:
```
ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;
```
Перевірте, чи розпочалася синхронізація, і чи база даних досягла стану SYNCHRONIZED (СИНХРОНІЗОВАНО).

4.9.3 Файли знімків бази даних

Використовуйте файли знімків бази даних для ініціалізації вторинних реплік з існуючих файлів бази даних.

Від’єднайте або створіть резервну копію бази даних на первинній репліці.
Скопіюйте файли бази даних до кожної вторинної репліки, використовуючи ті самі шляхи до файлів.
На вторинних репліках підключіть базу даних або відновіть її без відновлення.
Переконайтеся, що база даних перебуває у стані ВІДНОВЛЕННЯ.
Приєднайте базу даних до групи доступності.
Цей метод корисний для дуже великих баз даних, де передача даних по мережі була б недоцільною.

5 FAQ

5.1 Загальні запитання

З: Яка різниця між Always On FCI та Always On AG?

A: Екземпляри кластера Always On Failover забезпечують високу доступність на рівні екземпляра, використовуючи спільне сховище, тоді як групи доступності Always On забезпечують високу доступність на рівні бази даних без спільного сховища. Група доступності Always On пропонує зручні для читання вторинні кластери та гнучкіший географічний розподіл.

З: Чи можу я використовувати групи доступності Always On з SQL Server Стандартне видання?

A: Так, SQL Server Стандартна версія 2016 року та пізніші версії підтримують базові групи доступності з обмеженнями, зокрема однією базою даних на групу доступності, максимум двома репліками та відсутністю підтримки вторинних ресурсів для читання.

З: Чи потрібне мені спільне сховище для груп доступності Always On?

В: Ні, групи доступності не потребують спільного сховища. Кожна репліка зберігає незалежні копії баз даних у локальному сховищі, синхронізовані через доставку журналу транзакцій.

З: Яка максимальна кількість реплік у групі доступності?

A: SQL Server Enterprise Edition підтримує до дев'яти реплік (одну основну та вісім додаткових). Розподілені групи доступності можуть підтримувати до 18 реплік у двох групах доступності.

5.2 Питання щодо конфігурації

З: Як вибрати між синхронним та асинхронним режимами фіксації змін?

A: Використовуйте синхронне фіксування для нульової втрати даних в межах одного центру обробки даних або мереж з низькою затримкою. Використовуйте асинхронне фіксування для віддалених реплік аварійного відновлення, де синхронне фіксування може вплинути на продуктивність.

З: Чи можна поєднувати синхронні та асинхронні репліки в одній групі доступності?

В: Так, групи доступності підтримують змішані конфігурації як із синхронними, так і з асинхронними репліками. Це забезпечує локальну високу доступність із синхронними репліками та віддалене аварійне відновлення з асинхронними репліками.

З: Що відбувається з моїми підключеннями під час резервного перемикання?

A: Існуючі з’єднання розриваються під час відновлення після відмови. Програми з логікою повторної спроби підключення автоматично повторно підключаються до нового основного сервера через слухач. Процес відновлення після відмови зазвичай завершується протягом кількох секунд або хвилин.

З: Чи потрібно синхронізувати логіни та завдання між репліками?

В: В SQL Server 2019 та раніше, так – логіни, завдання агента SQL та підключені сервери необхідно синхронізувати вручну. SQL Server У версії 2022 запроваджено групи обмеженої доступності, які автоматично включають ці об’єкти.

5.3 Управлінські питання

З: Чи можна створювати резервні копії на вторинних репліках?

В: Так, вторинні репліки підтримують повні, диференціальні резервні копії та резервні копії журналу транзакцій. Налаштуйте параметри резервного копіювання, щоб розвантажити резервні копії з первинної репліки та зменшити використання нею ресурсів.

З: Як мені встановити патч? SQL Server з мінімальним простоєм?

A: Використовуйте поступові оновлення, спочатку виправляючи вторинні репліки, потім виконуючи ручне перемикання на виправлену вторинну репліку, і нарешті виправляючи колишню основну репліку. Це мінімізує час простою під час перемикання на резервну репліку.

З: Чи можна додати бази даних до існуючої групи доступності?

В: Так, бази даних можна додавати до запущених груп доступності. База даних має бути в моделі повного відновлення з повною резервною копією, а вторинні репліки мають бути заповнені за допомогою автоматичного заповнення або ручного резервного копіювання та відновлення.

З: Що таке автоматичний посів і чи варто його використовувати?

A: Автоматичне заповнення передає дані бази даних через мережу для ініціалізації вторинних реплік без ручного резервного копіювання. Використовуйте його для менших баз даних або коли пропускна здатність мережі достатня. Для дуже великих баз даних ручне заповнення може бути швидшим.

З: Де слід запускати DBCC CHECKDB у групі доступності?

A: Вам слід виконати команду DBCC CHECKDB на вторинних репліках, щоб зменшити навантаження на первинну репліку. Перевірки узгодженості бази даних можуть виконуватися на вторинних базах даних, не впливаючи на продуктивність первинної репліки.

Щоб отримати докладнішу інформацію про DBCC CHECKDB, див. нашу вичерпний посібник.

5.4 Запитання щодо усунення несправностей

З: Чому моя база даних перебуває у стані НЕ СИНХРОНІЗУЄТЬСЯ?

A: Поширені причини включають проблеми з підключенням до мережі, призупинення переміщення даних, недостатнє місце на диску на вторинних репліках або проблеми з кінцевими точками. Перевірте опис стану синхронізації та SQL Server журнали помилок для отримання детальної інформації. Якщо вторинна база даних увійшла в стан відновлення або шоу відновлення очікується, див. пов’язані посібники для цільових виправлень.

З: Як примусово переключитися на резервний сервер, коли основний сервер недоступний?

A: Підключіться до вторинної репліки та виконайте команду ALTER AVAILABILITY GROUP AG_Name FORCE_FAILOVER_ALLOW_DATA_LOSS. Це підтверджує потенційну втрату даних і негайно переводить вторинну репліку в первинну.

З: Чому клієнти не можуть підключитися до мого слухача?

A: Переконайтеся, що прослуховувач підключений до мережі в диспетчері відмовостійкого кластера, реєстрація DNS успішна, усі IP-адреси прослуховувачів доступні для клієнтів, а правила брандмауера дозволяють трафік до порту прослуховувача.

З: Що означає велика черга повторення?

A: Велика черга повторення вказує на те, що вторинна репліка не може застосовувати записи журналу так швидко, як вони надходять. Це може свідчити про вузькі місця вводу-виводу диска, обмеження процесора або блокування запитів лише для читання на вторинній репліці.

З: Що робити, якщо катастрофа вплинула на всі репліки, а мої резервні копії також пошкоджені?

В: Цей найгірший сценарій, хоча й трапляється надзвичайно рідко, може статися через атаки програм-вимагачів, поширені збої сховищ або каскадні катастрофи. Вашим основним захистом є запобігання: підтримуйте географічно розподілені репліки, зберігайте резервні копії в окремих місцях і
регулярно тестуйте свої процедури аварійного відновлення. Якщо всі стандартні варіанти відновлення не спрацьовують, спеціалізований Інструмент для відновлення даних SQL може спробувати витягти дані з пошкоджених MDF-файлів як крайній захід.

5.5 Питання щодо ліцензування та вартості

З: Як ліцензуються групи доступності Always On?

A: SQL Server Ліцензування залежить від видання та моделі розгортання. Групи доступності Enterprise Edition вимагають ліцензій Enterprise на всіх репліках. Пасивні вторинні репліки можуть претендувати на безкоштовне ліцензування за певних умов.

З: Чи можу я використовувати SQL Server Версія для розробників для груп доступності?

В: Так, версія для розробників містить усі функції версії для підприємств, зокрема повну підтримку груп доступності. Однак вона ліцензована лише для розробки та тестування, а не для виробничого використання.

З: Чи потрібні додаткові ліцензії для читання вторинних файлів?

В: Ліцензування залежить від сценарію. Пасивні вторинні сервери для аварійного відновлення зазвичай не потребують ліцензій. Активні вторинні сервери, що обслуговують робочі навантаження лише для читання, зазвичай потребують ліцензій, хоча конкретні умови різняться.

З: Чи існує безкоштовний спосіб отримати високу доступність за допомогою SQL Server?

A: SQL Server Експрес-версія не підтримує групи доступності. SQL Server Стандартна версія підтримує базові групи доступності, починаючи з SQL Server 2016, забезпечуючи базову високу доступність за вартістю ліцензування Standard Edition.

З: Що таке розподілені групи доступності?

A: Розподілені групи доступності – це особливий тип групи доступності, яка охоплює дві окремі групи доступності, що дозволяє реалізувати сценарії, що перевищують можливості традиційних груп доступності. Представлено в SQL Server У 2016 році розподілені групи доступності враховують вимоги масштабування та географічного розподілу.

6. Висновок

6.1 Резюме ключових положень

SQL Server Групи доступності Always On Availability Groups – це провідне рішення Microsoft для забезпечення високої доступності та аварійного відновлення критично важливих баз даних. Вони забезпечують резервне перемикання на рівні бази даних без вимог до спільного сховища, доступні для читання вторинні репліки для розвантаження робочих навантажень та гнучкий географічний розподіл для комплексного захисту даних. Для організацій, які досі використовують такі рішення, як доставка колод or копіювання, групи доступності пропонують надійніший та простіший з точки зору експлуатації шлях оновлення.

6.2 Коли використовувати групи доступності Always On

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

6.3 Початок впровадження

Розпочніть планування групи доступності з оцінки бізнес-вимог, включаючи RTO, RPO та бюджетні обмеження. Задокументуйте поточну інфраструктуру бази даних, залежності програм та прогалини у високій доступності. Розробіть архітектуру групи доступності, яка враховує вимоги, залишаючись при цьому в межах обмежень ресурсів.

Посилання

Офіційний документ Microsoft: Що таке група доступності «Завжди ввімкнено»?
Офіційний документ Microsoft: Початок роботи з групами доступності Always On
Офіційний документ Microsoft: Розподілені групи доступності

Про автора

Юань Шен є старшим адміністратором баз даних (DBA) з понад 10-річним досвідом роботи в SQL Server середовища та управління корпоративними базами даних. Він успішно вирішив сотні сценаріїв відновлення баз даних у фінансових службах, охороні здоров'я та виробничих організаціях.

Юань спеціалізується на SQL Server відновлення баз даних, рішення для забезпечення високої доступності та оптимізація продуктивності. Його великий практичний досвід включає управління багатотерабайтними базами даних, впровадження груп доступності Always On та розробку автоматизованих стратегій резервного копіювання та відновлення для критично важливих бізнес-систем.

Завдяки своїй технічній експертизі та практичному підходу, Юань зосереджується на створенні комплексних посібників, які допомагають адміністраторам баз даних та ІТ-фахівцям вирішувати складні SQL Server ефективно вирішує проблеми. Він слідкує за останніми новинками SQL Server випуски та технології баз даних Microsoft, що розвиваються, регулярно тестуючи сценарії відновлення, щоб переконатися, що його рекомендації відображають найкращі практики реального світу.

Є запитання щодо SQL Server відновлення чи потрібні додаткові інструкції з усунення несправностей бази даних? Юань вітає відгуки та пропозиції для покращення цих технічних ресурсів.

SQL Server Групи доступності Always On: повний посібник [2026]

1. Розуміння груп доступності Always On

1.1 Що це таке і як це працює