SQL Server Групи за винаги налични услуги [Ръководство за 2026 г.]

Групи за винаги налична достъпност (AG) са SQL Server Enterprise висока наличност и решение за възстановяване след бедствия, което работи на ниво база данни. Група за достъпност групира една или повече потребителски бази данни в една резервна единица и ги репликира до до осем вторични реплики чрез непрекъснато изпращане на регистрационни файлове на транзакции. Когато основната реплика се повреди, определена синхронна вторична реплика автоматично поема контрола, възстановявайки достъпа за секунди без споделено хранилище или ръчна намеса.

1.2 Групи за винаги включена достъпност спрямо екземпляри на клъстери за отказоустойчивост

SQL Server Always On включва две отделни технологии: Availability Groups (AG) и Failover Cluster Instances (FCI):

	Винаги включени групи за наличност	Винаги включени екземпляри на клъстери за отказоустойчивост
Обхват на превключване при срив	Ниво на база данни	Ниво на инстанция (всички бази данни се прехвърлят при срив едновременно)
Репликация на данни	Репликация, базирана на лог файлове, към всяка вторична	Няма — всички възли споделят едно и също хранилище
Споделено хранилище	Не се изисква	Задължително (Мрежа за съхранение на данни (SAN), iSCSI, S2D или SMB)
Четливи вторични елементи	Да	Не
Възстановяване след бедствие	Вградени (асинхронни реплики между сайтове)	Не е вграден без сдвояване с AG

Кога да използвате всеки от тях: Използвайте FCI, когато се нуждаете от резервно копие на ниво инстанция и вече имате споделена инфраструктура за съхранение. Използвайте AG, когато се нуждаете от гранулираност на ниво база данни, четими вторични сървъри или възстановяване след бедствие. За най-пълна защита комбинирайте и двете: стартирайте всяка реплика като FCI възел и ги свържете в AG.

1.3 Предимства и ограничения

Ползи:

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

Ограничения:

Изисква клъстеринг при отказ на Windows Server на всички реплики;
Enterprise Edition за пълен набор от функции (Standard Edition поддържа Basic AG със значителни ограничения);
Режимът на синхронно записване добавя латентност към операциите по запис, пропорционална на времето за двупосочно предаване в мрежата;
влизанията, заданията на SQL агента и свързаните сървъри не се синхронизират автоматично в SQL Server 2019 г. и по-рано (решено в SQL Server 2022 съдържаше групи за наличност).

2. Архитектура на групите за достъпност „Винаги включени“

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. Основната реплика завършва обработката на текущите транзакции, изпраща всички останали записи в журнала към целевата вторична реплика и изчаква потвърждение, преди да прехвърли основната роля.

Ръчно превключване при срив може да се случи и при асинхронни реплики с commit, но това изисква принудително превключване при срив с потенциална загуба на данни. Администраторите трябва да използват принудително ръчно превключване при срив само по време на реални сценарии на бедствие, когато основната реплика не е налична и загубата на данни е приемлива в сравнение с удължения престой.

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 Failover Clustering (WSFC) осигурява основата за Always On Availability Groups, като управлява членството в клъстера, наблюдението на състоянието и оркестрацията при отказ. За разлика от Failover Cluster Emptys, групите за достъпност използват WSFC само за координация на клъстера, а не за управление на споделено хранилище.

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

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

Кворумът на клъстера определя кои възли могат да работят, когато възникнат проблеми с мрежовата свързаност, предотвратявайки сценарии с разделен мозък, при които множество възли независимо твърдят, че са първични. Конфигурацията на кворума дефинира какво представлява мнозинството от гласовете за решения на клъстера.

За групите за достъпност са налични няколко режима на кворум:

Мнозинството от възлите използва само гласове от възлите на клъстера и работи добре за клъстери с нечетен брой възли.
Мнозинството от възли и споделени файлове добавя свидетелски вот за споделени файлове, подходящ за клъстери от възли с четен брой.
Node and Disk Majority използва дисков свидетел, но е по-рядко срещан за групи за достъпност, тъй като не се изисква споделено хранилище.

3.1.3 Клъстериране на множество подмрежи

Клъстерирането в множество подмрежи позволява на репликите на групите за достъпност да обхващат различни мрежови подмрежи, поддържайки географски разпределени внедрявания в центрове за данни. Тази възможност е от съществено значение за конфигурации за възстановяване след бедствия, където репликите съществуват на отделни места.

3.2 SQL Server Изисквания за изданието

3.2.1 Функции на Enterprise Edition

SQL Server Enterprise Edition предоставя пълна функционалност на групите за достъпност без ограничения. Enterprise Edition поддържа до осем вторични реплики, четими вторични реплики, автоматично засяване, разпределени групи за достъпност и всички разширени функции.

3.2.2 Функции на стандартното издание (основни групи за достъпност)

SQL Server Стандартното издание 2016 и по-новите версии поддържат основни групи за достъпност със значителни ограничения. Основните групи за достъпност предоставят основна функционалност за висока достъпност на по-ниска цена, подходяща за организации с по-прости изисквания.

4. Конфигуриране на групи за винаги включена наличност

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

Клъстеризацията за отказоустойчивост на Windows Server трябва да бъде инсталирана и конфигурирана на всички възли, преди да се активират групите за достъпност Always On.

4.2.1 Инсталиране на функцията за клъстериране при срив

Инсталирайте функцията Failover Clustering на всеки сървър, който ще участва в групата за достъпност.

Отворете Server Manager на първия клъстерен възел.
Кликнете Управление -> Добавете роли и функции.
Кликнете Следваща през въвеждащите екрани.
Изберете Инсталиране, базирано на роли или функции и кликнете Следваща.
Изберете локалния сървър и щракнете Следваща.
Пропуснете екрана „Роли“ и щракнете върху Следваща.
На екрана с функции изберете Клъстериране при отказоустойчивост.
Кликнете Добавяне на функции когато бъдете подканени да включите инструменти за управление.
Кликнете Следваща и след това Инсталирайте.
Изчакайте инсталацията да завърши и щракнете Затвори.
Повторете на всички сървъри, които ще участват в клъстера.

4.2.2 Създаване на клъстер за отказоустойчивост

След като инсталирате функцията за клъстериране при срив на всички възли, създайте клъстера от един възел.

Отворете Мениджър на клъстери за отказоустойчивост от Server Manager -> Инструменти.
Кликнете Създайте клъстер в панела „Действия“.
Кликнете Следваща на страницата „Преди да започнете“.
Кликнете паса и добавете всички сървъри, които ще бъдат клъстерни възли.
Кликнете Следваща след добавяне на всички възли.
Оставям Изпълнете всички тестове (препоръчително) избрани и щракнете Следваща.
Прегледайте резултатите от валидационния тест и отстранете всички грешки или предупреждения.
Кликнете завършеност след успешно завършване на валидирането.
Въведете име за клъстера и IP адрес.
Махнете отметката от Добавете цялото допустимо хранилище към клъстера тъй като не се изисква споделено хранилище.
Кликнете Следваща и прегледайте потвърждението.
Кликнете завършеност за да се създаде клъстерът.

4.2.3 Проверка на конфигурацията на клъстера

Проверете конфигурацията на клъстера, за да се уверите, че всички възли могат да комуникират правилно и клъстерът работи правилно.

In Мениджър на клъстери за отказоустойчивост, щракнете с десния бутон върху името на клъстера.
Изберете Валидиране на клъстер от менюто.
Кликнете Следваща на страницата „Преди да започнете“.
Изберете Изпълнете всички тестове (препоръчително) и кликнете Следваща.
Кликнете Следваща за да започнат валидационни тестове.
Прегледайте отчета за валидиране, когато тестовете приключат.
Отстранете всички повреди или предупреждения, посочени в доклада.
Кликнете завършеност за да затворите съветника.

НИКОГА не инсталирайте SQL Server за групи за достъпност

Инсталирайте SQL Server на всеки възел, който ще участва в групата за достъпност, използвайки опцията за самостоятелна инсталация.

Стартирайте SQL Server инсталационен носител на първия възел.
Изберете НОВ SQL Server самостоятелна инсталация.
Въведете продуктовия ключ или изберете пробното издание.
Приемете лицензионните условия и щракнете Следваща.
Извършете предварителните проверки и отстранете всички проблеми.
На страницата за избор на функции изберете Услуги за двигатели на бази данни.
Конфигурирайте име на екземпляр (използвайте едно и също име на екземпляр на всички възли).
На страницата „Конфигурация на сървъра“ посочете идентификационните данни за акаунта на услугата.
Конфигурирайте типовете стартиране на услуги като автоматичен.
На страницата „Конфигурация на двигателя на базата данни“ изберете режим на удостоверяване.
Добавете администраторски акаунти.
Конфигурирайте директории с данни, като използвате последователни пътища във всички възли.
Завършете инсталацията и проверете успеха.
Повторете инсталацията на всички останали възли на клъстера с идентични настройки.

4.4 Активиране на функцията „Групи за достъпност винаги включени“

След инсталиране SQL Server На всички възли активирайте функцията „Групи за достъпност винаги включени“ на всеки екземпляр.

4.4.1 Активиране чрез SQL Server Конфигурационен мениджър

Използвайте SQL Server Configuration Manager за активиране на групи за винаги включена наличност чрез графичния интерфейс.

Отворете SQL Server Конфигурационен мениджър на първия възел.
Разширете SQL Server Услуги в левия панел.
Щракнете с десния бутон върху SQL Server екземпляр и изберете Имоти.
Кликнете върху менюто Висока наличност AlwaysOn таб.
Проверка Активиране на групи за достъпност AlwaysOn.
Проверете дали името на клъстера за превключване при срив на Windows е правилно.
Кликнете OK за да запазите промените.
Кликнете OK на предупреждението, че услугата трябва да бъде рестартирана.
Щракнете с десния бутон върху SQL Server услуга и изберете Restart.
Изчакайте услугата да се рестартира успешно.
Повторете на всички възли на клъстера.

4.4.2 Активиране чрез PowerShell

PowerShell предоставя скриптиран метод за активиране на групи за достъпност Always On в множество възли.

Отворете PowerShell като администратор на първия възел.
Импортирайте SQL Server PowerShell модул:
```
Import-Module SQLPS -DisableNameChecking
```
Активиране на групи за винаги включена наличност:
```
Enable-SqlAlwaysOn -ServerInstance "ServerName\InstanceName" -Force
```
Услугата ще се рестартира автоматично, когато използвате параметъра Force.

Проверете дали функцията е активирана:

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

Повторете за всеки клъстерен възел, като заместите съответните имена на сървъра и екземпляра.

4.4.3 Проверка дали функцията е активирана

Проверете дали „Групи за достъпност винаги включени“ е активирано във всички екземпляри, преди да продължите с конфигурирането.

Свържете се с всеки SQL Server използвайки инстанция SQL Server Студио за управление.
Отворете нов прозорец за заявка и изпълнете:
```
SELECT SERVERPROPERTY('IsHadrEnabled')
```
Проверете дали резултатът е 1 (активирано).
Проверете дали SQL Server екземплярът се появява в Failover Cluster Manager под клъстерни роли.
Проверете съществуването на крайната точка на групата за достъпност, като изпълните:
```
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 в Object Explorer.
Щракнете с десния бутон Групи за наличност и изберете Съветник за нова група за достъпност.
Кликнете Следваща на страницата „Въведение“.
Въведете име за групата за наличност и щракнете върху Следваща.
На страницата „Избор на бази данни“ изберете базите данни, които да включите.
Проверете дали базите данни отговарят на всички предварителни изисквания и щракнете Следваща.
На страницата „Задаване на реплики“ щракнете върху Добавяне на реплика.
Свържете се с всеки вторичен екземпляр на реплика.
Конфигурирайте свойствата на репликата за всеки екземпляр (режим на наличност, режим на превключване при срив).
Кликнете върху менюто Крайни точки раздела и прегледайте конфигурацията на крайната точка.
Кликнете върху менюто Предпочитания за архивиране раздел и конфигурирайте приоритетите за архивиране.
Кликнете върху менюто слушател раздел и по избор създайте слушател.
Кликнете Следваща и изберете метода за синхронизиране на данни.
Прегледайте резултатите от валидирането и отстранете евентуални проблеми.
Кликнете Следваща и прегледайте резюмето.
Кликнете завършеност за да създадете групата за достъпност.
Следете напредъка и проверявайте успешното създаване.

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) за локални реплики с висока достъпност.
Използвайте асинхронно commit за географски отдалечени реплики за възстановяване след бедствие.
Кликнете OK за да запазите конфигурацията.

4.7.3 Задаване на режими на превключване при срив

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

Щракнете с десния бутон върху групата за наличност и изберете Имоти.
В Общи страница, отидете на Реплики за наличност раздел.
За синхронни реплики на комити изберете автоматичен or наръчник режим на превключване при срив.
Автоматичното превключване на резервни операции изисква синхронен режим на потвърждаване и позволява автоматично превключване на резервни операции.
За асинхронни реплики на commit е налично само ръчно превключване при срив.
Конфигурирайте до три реплики за автоматично превключване при срив (една основна и две вторични).
Кликнете OK за да приложите настройките.

4.7.4 Конфигуриране на предпочитанията за архивиране

Задайте предпочитания за архивиране, за да контролирате къде трябва да се извършват операциите по архивиране.

Щракнете с десния бутон върху групата за наличност и изберете Имоти.
Изберете Предпочитания за архивиране в левия панел.
Изберете едно от предпочитанията за архивиране:
- Предпочитам вторичноРезервни копия на вторичния, ако има такъв, в противен случай на основния
- Само второстепенниАрхивиране само на вторични реплики
- ПървиченАрхивиране само на основна реплика
- Всяка репликаРезервни копия на всяка налична реплика
Задайте стойности за приоритет на архивирането за всяка реплика (0-100).
По-високите стойности на приоритет показват предпочитани цели за архивиране.
Кликнете OK за да запазите предпочитанията.

4.8 Конфигуриране на слушателя на група за достъпност

Създайте слушател, който да осигури единична точка на свързване, която автоматично пренасочва към текущата основна реплика.

4.8.1 Създаване на слушателя

Добавете слушател към групата за достъпност за управление на клиентските връзки.

In SQL Server Management Studio, разгънете групата за наличност.
Щракнете с десния бутон Слушатели на групи за достъпност и изберете Добавяне на слушател.
Въведете DNS име за слушателя (например AG_Listener).
Въведете номера на порта (по подразбиране е 1433).
Изберете Static IP за мрежовия режим.
Кликнете върху ДОБАВЯНЕ, за да добавите IP адрес за всяка подмрежа.
Въведете IP адреса и изберете подмрежата.
Кликнете OK за да се създаде слушателят.
Проверете дали слушателят се показва в Object Explorer и е онлайн.

4.8.2 Конфигуриране на DNS и IP настройки

Проверете DNS регистрацията и мрежовата конфигурация за слушателя.

Отворете DNS Manager на домейн контролера.
Проверете дали името на слушателя е регистрирано с всички IP адреси.
Тестване на DNS преобразуването от клиентски машини:
```
nslookup ListenerName
```
Проверете дали всички конфигурирани IP адреси са върнати.
В диспечера на клъстери за отказоустойчивост разгънете роли и изберете групата за наличност.
Проверете дали ресурсите за IP адреси са онлайн.
Проверете дали ресурсът за мрежово име е онлайн.

4.8.3 Тестване на свързаността на слушателя

Проверете дали клиентските приложения могат да се свързват чрез слушателя.

От клиентска машина отворете SQL Server Студио за управление.
Свържете се, използвайки името на слушателя, вместо името на сървъра.
Изпълнете заявка, за да проверите връзката с текущата първична реплика:
```
SELECT @@SERVERNAME;
```
Тествайте маршрутизирането с намерение за четене, като добавите ApplicationIntent=ReadOnly към низа за свързване.
Проверете пренасочванията на връзката към четлива вторична реплика.
Тествайте превключването при срив, като ръчно превключите групата за достъпност и проверите повторното свързване.

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

Изберете метод за синхронизиране на данни, за да инициализирате вторични реплики с копия на базата данни.

4.9.1 Автоматично засяване

Автоматичното засяване прехвърля данни от базата данни по мрежата, без да е необходимо ръчно архивиране и възстановяване.

По време на създаването на група за достъпност изберете Автоматично засяване като метод за синхронизация.
Осигурете мрежова свързаност и достатъчна честотна лента между репликите.
Първичната реплика автоматично прехвърля данни от базата данни към вторични реплики.
Следете напредъка на засяването, като използвате таблото за управление на групата за наличност или DMVs.
Автоматичното засяване изисква 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. ЧЗВ

5.1 Общи въпроси

В: Каква е разликата между Always On FCI и Always On AG?

A: Инстанциите на клъстера с постоянно превключване при срив (Always On Failover Cluster) осигуряват висока достъпност на ниво инстанция, използвайки споделено хранилище, докато групите за постоянно превключване при срив (Always On Availability Groups) осигуряват висока достъпност на ниво база данни без споделено хранилище. AG предлага четливи вторични сървъри и по-гъвкаво географско разпределение.

В: Мога ли да използвам групи за винаги включена наличност с SQL Server Стандартно издание?

О: Да, SQL Server Стандартно издание 2016 и по-нови версии поддържат основни групи за достъпност с ограничения, включително една база данни на група за достъпност, максимум две реплики и липса на поддръжка за четливи вторични групи.

В: Необходимо ли ми е споделено хранилище за групите за достъпност „Винаги включено“?

A: Не, групите за достъпност не изискват споделено хранилище. Всяка реплика поддържа независими копия на бази данни в локално хранилище, синхронизирани чрез доставка на регистрационни файлове на транзакции.

В: Какъв е максималният брой реплики в група за достъпност?

A: SQL Server Enterprise Edition поддържа до девет реплики (една основна и осем вторични). Разпределените групи за достъпност могат да поддържат до 18 общо реплики в две групи за достъпност.

5.2 Въпроси относно конфигурацията

В: Как да избера между синхронен и асинхронен режим на commit?

A: Използвайте синхронно потвърждаване (commit) за изисквания за нулева загуба на данни в рамките на един и същ център за данни или мрежи с ниска латентност. Използвайте асинхронно потвърждаване (commit) за отдалечени реплики за възстановяване след бедствие, където синхронното потвърждаване би повлияло на производителността.

В: Мога ли да смесвам синхронни и асинхронни реплики в една и съща група за достъпност?

A: Да, групите за достъпност поддържат смесени конфигурации както със синхронни, така и с асинхронни реплики. Това позволява локална висока достъпност със синхронни реплики и отдалечено възстановяване след бедствие с асинхронни реплики.

В: Какво се случва с връзките ми по време на превключване на резервни устройства?

A: Съществуващите връзки се прекъсват при превключване на връзката. Приложенията с логика за повторен опит за връзка автоматично се свързват отново с новия основен сървър чрез слушателя. Процесът на превключване на връзката обикновено завършва в рамките на секунди до минути.

В: Трябва ли да синхронизирам влизания и задачи в различните реплики?

О: В SQL Server 2019 и по-ранни версии, да – влизанията, заданията на SQL агента и свързаните сървъри трябва да се синхронизират ръчно. SQL Server 2022 въвежда групи за ограничена достъпност, които автоматично включват тези обекти.

5.3 Въпроси за управление

В: Мога ли да стартирам резервни копия на вторични реплики?

A: Да, вторичните реплики поддържат пълни, диференциални и резервни копия на регистрационни файлове на транзакции. Конфигурирайте предпочитанията за архивиране, за да разтоварите резервните копия от първичната реплика и да намалите използването на нейните ресурси.

В: Как да направя пач SQL Server с минимално време за престой?

A: Използвайте поетапни надстройки, като първо закърпите вторичните реплики, след това извършите ръчно превключване към закърпен вторичен сървър и накрая закърпите предишния първичен сървър. Това минимизира времето на престой до продължителността на превключването.

В: Мога ли да добавя бази данни към съществуваща група за достъпност?

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: Проверете дали слушателят е онлайн в Failover Cluster Manager, регистрацията на DNS е успешна, всички IP адреси на слушателя са достъпни от клиентите и правилата на защитната стена позволяват трафик към порта на слушателя.

В: Какво означава голяма опашка за повторно изпълнение?

A: Голяма опашка за повторно изпълнение показва, че вторичната реплика не може да прилага записи от лога толкова бързо, колкото пристигат. Това може да показва затруднения с дисковия вход/изход, ограничения на процесора или блокиране от заявки само за четене на вторичната реплика.

В: Какво трябва да направя, ако бедствие засегне всички реплики и резервните ми копия също са повредени?

A: Този най-лош сценарий, макар и изключително рядък, може да възникне поради атаки с ransomware, широко разпространени повреди в хранилището или каскадни бедствия. Вашата основна защита е превенцията: поддържайте географски разпределени реплики, съхранявайте резервни копия на отделни места и
редовно тествайте процедурите си за възстановяване след бедствия. Ако всички стандартни опции за възстановяване се провалят, специализиран Инструмент за възстановяване на SQL данни може да се опита да извлече данни от повредени MDF файлове като спешна мярка.

5.5 Въпроси относно лицензирането и цените

В: Как се лицензират групите за наличност „Always On“?

A: SQL Server Лицензирането зависи от изданието и модела на внедряване. Групите за наличност на Enterprise Edition изискват Enterprise лицензи за всички реплики. Пасивните вторични реплики могат да отговарят на условията за безплатно лицензиране при определени условия.

В: Мога ли да използвам SQL Server Издание за разработчици за групи за достъпност?

A: Да, Developer Edition включва всички функции на Enterprise Edition, включително пълната поддръжка на групи за достъпност. Лицензиран е обаче само за разработка и тестване, а не за производствена употреба.

В: Изискват ли се допълнителни лицензи за четливи вторични файлове?

A: Лицензирането зависи от сценария. Пасивните вторични сървъри за възстановяване след бедствие обикновено не изискват лицензи. Активните вторични сървъри, обслужващи работни натоварвания само за четене, обикновено изискват лицензи, въпреки че специфичните условия варират.

В: Има ли безплатен начин да се постигне висока наличност с SQL Server?

A: SQL Server Express Edition не поддържа групи за наличност. SQL Server Стандартното издание поддържа основни групи за достъпност, започващи с SQL Server 2016 г., осигурявайки основна висока достъпност на цени за лицензиране на Standard Edition.

В: Какво представляват разпределените групи за достъпност?

A: Разпределените групи за достъпност са специален тип група за достъпност, която обхваща две отделни групи за достъпност, което позволява сценарии, надхвърлящи възможностите на традиционните групи за достъпност. Въведено в SQL Server През 2016 г. разпределените групи за достъпност отговарят на изискванията за мащабиране и географско разпределение.

6. заключение

6.1 Обобщение на ключовите точки

SQL Server Групите за достъпност Always On представляват водещото решение на Microsoft за висока достъпност и възстановяване след бедствия за критично важни бази данни. Те осигуряват превключване на базата данни без изисквания за споделено съхранение, четими вторични реплики за разтоварване на работните натоварвания и гъвкаво географско разпределение за цялостна защита на данните. За организации, които все още използват решения като доставка на дървени трупи or копиране, групите за достъпност предлагат по-стабилен и оперативно по-лесен път за надграждане.

6.2 Кога да използвате групи за достъпност „Винаги включени“

Изберете групи за достъпност, когато се нуждаете от висока достъпност на ниво база данни с възможности за автоматично превключване при срив. Организациите, които се нуждаят от защита от нулева загуба на данни за критични бази данни, се възползват от синхронни реплики на commit с автоматично превключване при срив. Приложенията, изискващи възможности за мащабиране на четене, използват четими вторични реплики, за да разпределят натоварването на заявките.

6.3 Първи стъпки с вашето внедряване

Започнете планирането на групата за достъпност, като оцените бизнес изискванията, включително RTO, RPO и бюджетни ограничения. Документирайте текущата инфраструктура на базата данни, зависимостите на приложенията и пропуските във високата достъпност. Проектирайте архитектура на групата за достъпност, която отговаря на изискванията, като същевременно остава в рамките на ограниченията на ресурсите.

Източници

Официален документ на Microsoft: Какво представлява групата за наличност „Винаги включено“?
Официален документ на Microsoft: Първи стъпки с групите за наличност „Винаги включени“
Официален документ на Microsoft: Разпределени групи за достъпност

За автора

Юан Шенг е старши администратор на бази данни (DBA) с над 10 години опит в SQL Server среди и управление на корпоративни бази данни. Той е разрешил успешно стотици сценарии за възстановяване на бази данни във финансови услуги, здравеопазване и производствени организации.

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

Чрез техническата си експертиза и практичен подход, Юан се фокусира върху създаването на изчерпателни ръководства, които помагат на администраторите на бази данни и ИТ специалистите да решават сложни задачи. SQL Server предизвикателствата ефикасно. Той е в крак с най-новото SQL Server издания и развиващите се технологии за бази данни на Microsoft, като редовно тества сценарии за възстановяване, за да гарантира, че препоръките му отразяват най-добрите практики в реалния свят.

Имате въпроси относно SQL Server възстановяване или имате нужда от допълнителни насоки за отстраняване на проблеми с базата данни? Юан приветства обратна връзка и предложения за подобряване на тези технически ресурси.

SQL Server Групи за постоянна наличност: Пълно ръководство [2026]

1. Разбиране на групите за достъпност „Винаги включени“

1.1 Какво представлява и как работи