В тази статия ще разгледаме стъпка по стъпка инсталирането и конфигурирането на групи за наличност. Винаги на в SQL Server в Windows Server 2019, помислете за сценарии за отказ и редица други свързани проблеми.
"Винаги в групи за наличност"Или"Винаги в групи за наличност“Технологията за висока наличност в SQL Server. Always On се появи в Microsoft SQL Server 2012.
Съдържание:
- Характеристики на групите винаги на разположение в SQL Server
- Конфигурирайте Windows Server Failover Cluster за Always On
- Конфигуриране на винаги включено в MS SQL Server
- Винаги включен: проверка на ефективността, автоматично отказване
Характеристики на групите винаги на разположение в SQL Server
За какво могат да се използват групи за наличност на SQL Server?
- Висока наличност на MS SQL и автоматично отказване;
- Заредете балансиране на избрани заявки между възлите (вторичните реплики могат да бъдат четими);
- Архивиране от вторични реплики;
- Излишък на данни. Всяка реплика съхранява копия от бази данни за групи за наличност.
Винаги работи на платформата Отказоустойчив клъстер на Windows Server (WSFC). WSFC следи възлите, участващи в групата за наличност и може автоматично да се провали чрез гласуване между възли. Започвайки от MS SQL Server 2017, възможността да използвате Always On без WSFC, включително на Linux системи. Когато създавате Linux клъстер, можете да използвате Pacemaker като алтернатива на WSFC.
Винаги е включен на стандарт издание, но с някои ограничения:
- Ограничете се върху 2 реплики (първична и вторична);
- Вторичната реплика не може да се използва за достъп до четене;
- Вторичната реплика не може да се използва за архивиране на MS SQL;
- Поддържайте само 1 база данни за група за наличност.
В редакторите Предприятие няма ограничения.
Функции за лицензиране на MS SQL Server.Ще разберем терминологията:
- Винаги Включена група за наличност - Това е колекция от реплики и бази данни.
- реплика - Това е екземпляр на SQL Server в група за наличност. Репликата може да е основната (първичен) и вторични (вторичен). Всяка реплика може да съдържа една или повече бази данни.
Always On се базира на WSFC. Всеки възел от група за наличност трябва да бъде член на клъстера за отказ на Windows. Всеки екземпляр на SQL Server може да има множество групи за наличност. Всяка група за наличност може да има до 8 вторични реплики.
Ако репликата не успее, клъстерът ще гласува за новата първична реплика и Always On ще прехвърли една от вторичните реплики към първичната. Тъй като, когато работите с Always On, потребителите се свързват със слушателя на клъстера (или слушателя, тоест специалния IP адрес на клъстера и съответното DNS име), възможността за писане на заявки ще бъде напълно възстановена. Слушателят е отговорен и за балансиране на избрани заявки между вторични реплики..
Конфигурирайте Windows Server Failover Cluster за Always On
На първо място, трябва да конфигурираме клъстер за отказ на всички възли, които ще участват в Always On.
Моята конфигурация:
- 2 виртуални машини на Hyper-V с Windows Server 2019;
- 2 екземпляра на SQL Server 2019 издание на Enterprise;
- Името на хоста на възлите е testnode1 и testnode2. Име на екземплярите node1 и node2.
В Server Manager добавете роля Клъстеризиране при отказ, или инсталирайте компонента с помощта на PowerShell:
Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools
Инсталирането е автоматично, все още не е необходимо да конфигурирате нищо. След като инсталацията приключи, стартирайте щракването. Отказоустойчив клъстер мениджър (FailoverClusters.SnapInHelper.msc).
Създайте нов клъстер.
Добавете имената на сървърите, които ще участват в клъстера.
Тогава съветникът предлага да премине тестовете. Не отказвайте, изберете първия елемент.
Посочете името на клъстера, изберете мрежата и IP адреса на клъстера. Името на клъстера автоматично ще се появи в DNS, не е необходимо да го регистрирате конкретно. В моя случай името на клъстера - ClusterAG.
Изваждаме чебоците “Добавете всички допустими хранилища към клъстера”, Както можем да добавим дискове по-късно.
В клъстера има само 2 възли, така че трябва да конфигурирате Кворум на клъстера. Кворумът на клъстера е „решаващ глас“. Например, ако един от клъстерните възли стане недостъпен, клъстерът трябва да определи кои възли действително са налични и могат да се виждат. Необходим е кворум за последователност на клъстера (Клъстер -> Още действия -> Конфигуриране на настройките на кворума на клъстера).
Изберете типа кворум.
След това изберете типа свидетел - папка на мрежата (файл споделяне свидетел).
Укажете пътя на UNC до папката на мрежата. Трябва да създадете тази директория сами и тя трябва да бъде на сървър, който не е включен в клъстера..
Когато настройвате клъстер, може да получите грешка:
Възникна грешка при конфигурирането на свидетеля за споделяне на файлове. Промените в свойството не могат да бъдат запазени за File Share Witness. Системата не може да намери посочения файл.
Най-вероятно това означава, че потребителят, от който работи клъстерът, няма права върху тази мрежова папка. По подразбиране клъстерът работи като локален потребител. Можете да дадете права на тази папка на всички компютри в клъстера или да промените акаунта за услугата на клъстера и да дадете права върху него.
Това завършва основната конфигурация на клъстера. Уверете се, че DNS на клъстера е регистриран и дава правилния IP адрес
Конфигуриране на винаги включено в MS SQL Server
След стандартна инсталация на екземпляр от SQL Server, можете да активирате и конфигурирате Always On Availability Groups. Те трябва да бъдат включени в SQL Server Configuration Manager например свойства. Както можете да видите на екрана, SQL Server вече е определил, че е член на клъстера WSFC. Поставете отметката „Активирайте винаги в групи за наличност”И рестартирайте услугата за екземпляри MSSQL. Следвайте същите стъпки на втората инстанция.
В студио за управление на SQL Server щракнете върху „Винаги при висока наличност”И стартирайте съветника за конфигуриране на групата за наличност (Нов съветник за наличност).
Посочете името на групата Always On Availability и изберете „Разкриване на ниво здраве на базата данни". С тази опция Always On ще може да определи кога базата данни е в нездравословно състояние..
Изберете базите данни на SQL Server, които ще участват в групата Always On Availability..
Щракнете върху „Добавяне на реплика ...“ и се свържете с втория SQL сървър. По този начин можете да добавите до 8 сървъра.
- Първоначална роля - Ролята на репликата по времето, когато групата е създадена. Може да бъде първичен и вторичен;
- Автоматично отказване - ако базата данни стане недостъпна, Always On прехвърля основната роля в друга реплика. Маркирайте квадратчето за отметка;
- Режим на достъпност - може би изберете Синхронен ангажимент или Асинхронен ангажимент. Когато изберете синхронен режим, транзакциите, пристигащи в основната реплика, ще бъдат изпратени до всички други вторични реплики със синхронен режим. Основната реплика завършва транзакцията само след като репликите напишат транзакцията на диск. Това елиминира възможността за загуба на данни, ако основната реплика не успее. В асинхронен режим основната реплика веднага записва промените, без да чака отговор от вторичните реплики;
- Четене вторично - параметър, определящ способността за извършване на избрани заявки към вторични реплики. Ако да, клиентите дори и с връзка без ApplicationIntent = readonly могат да получат достъп само за четене;
- Задължителни синхронизирани вторични устройства за извършване - Броят на синхронизираните вторични реплики за завършване на транзакцията. Необходимо е да настроите в зависимост от броя на репликите, ще сложа 1. Имайте предвид, че ако вторичните синхронизирани реплики станат по-малко от определения брой (например по време на злополука), базите данни на групата за наличност ще станат недостъпни дори за четене.
Крайните точки не се докосват.
етикет Предпочитания за архивиране Можете да изберете къде ще се правят резервни копия. Оставяме всичко по подразбиране - Предпочита второстепенно.
Посочете името на слушателя на групата за достъп, порт и IP адрес.
етикет Маршрут само за четене оставете непроменена.
Избираме как ще бъдат синхронизирани репликите. Оставям първата точка - автоматична синхронизация (Автоматично засяване).
След това вашите настройки трябва да бъдат потвърдени. Ако няма грешки, щракнете върху Готово, за да приложите промените..
В моя случай всички тестове бяха успешни, но след инсталирането в стъпката Резултати, съветникът съобщи за грешка при създаването на слушателя на групата за наличност. Дневниците на клъстера имаха тази грешка:
Ресурсът на името на клъстерната мрежа не успя да създаде асоциирания си компютърен обект в домейн.
Това означава, че клъстерът няма достатъчно права, за да създаде слушател. В документацията се казва, че е достатъчно да се даде разрешение за създаване на обекти от тип „компютър“ на обекта на вашия клъстер. Най-лесният начин да направите това е чрез делегиране на правомощия на AD (или бърз, но лош вариант е временно добавяне на обекта CLUSTERAG $ към групата на администратори на домейни).
Когато диагностицирате проблеми с Always ON и ниска производителност на SQL в групата за достъпност, в допълнение към стандартните инструменти за диагностика на SQL Server, трябва внимателно да разгледате дневниците на клъстер на Windows.Тъй като групата за достъпност, която създадох, но слушателят не е, добавих я ръчно. Извикваме контекстното меню на групата за наличност и кликваме Добавете слушател...
Посочете IP адреса, порта и DNS име на слушателя.
Проверете дали слушателят се появява в секцията „Налични слушатели“ на групата Винаги вкл.
С това завършва основната настройка на групата Always On Availability..
Винаги включен: проверка на ефективността, автоматично отказване
Обърнете внимание на таблото за управление на таблото.
Всичко е наред, групата за наличност е създадена и работи..
Нека се опитаме да прехвърлим основната роля на node2 инстанцията в ръчен режим. Щракнете с десния бутон върху група за наличност и изберете Failover.
Струва си да обърнете внимание на елемента Готовност за отказ. стойност Няма загуба на данни означава, че загубата на данни по време на прехода е изключена.
Свързване с node2.
Кликнете върху Готово.
Проверете дали node2 се е превърнал в основната реплика в групата за наличност (първичен случай).
Уверете се, че слушателят работи както трябва. В SSMS посочете DNS името на слушателя и порта, разделени със запетаи: AG1-слушател-1,1445
Нека направим просто вмъкване, избор и актуализиране на заявки към нашата база данни на SQL Server.
Сега нека проверим автоматичния отказ на основната реплика. Просто прекратете процеса sqlservr.exe на TESTNODE2.
Проверка на състоянието на групата за наличност на оставащия възел - TESTNODE1 \ NODE1.
Клъстерът автоматично прехвърли състоянието на репликата на testnode1 \ node1 в първичен, тъй като testnode2 \ node2 стана недостъпен.
Ще проверим състоянието на слушателя, защото клиентските връзки ще отидат към него.
В моя случай успешно се свързах със слушателя, но възникна грешка при достъп до базата данни
Не може да се осъществи достъп до базата данни „TestDatabase“, тъй като липсва кворум от възли за висока наличност. Опитайте отново операцията по-късно.
Тази грешка възникна поради „Задължителни синхронизирани вторични устройства за извършване". Тъй като при настройването задаваме тази стойност на 1, Винаги включен ни пречи да се свържем с базата данни, защото имаме само една основна реплика.
Задайте тази стойност на 0 и опитайте отново.
Включете testnode2 и проверете състоянието на групата.
Състоянието на първичната реплика остава с testnode1, а testnode2 става вторичната реплика. Данните, които променихме на testnode1, когато testnode2 беше изключен, успешно се синхронизират след включване на машината.
Това е краят на тестването. Ние се уверихме, че всичко работи правилно и в случай на критична повреда данните ще останат достъпни за достъп за четене / запис.
В допълнение към Always On, SQL Server има няколко други технологии за висока достъпност..Групите за винаги на разположение са лесно лесни за конфигуриране. Ако сте изправени пред задачата да изградите отказоустойчиво решение, базирано на SQL Server, групите за наличност ще се справят перфектно с тази задача.
С пускането на SQL Server 2017 и SQL Server 2019, SQL Server Management Studio 18.x въведе настройките за винаги включени, които преди бяха достъпни само чрез T-SQL, така че се препоръчва да използвате последната версия на SSMS.
