SQL Server Always ON Availability Group е решение, предназначено за постигане на висока наличност и възстановяване след бедствие за бази данни на SQL Server. Можем да конфигурираме тази функционалност между базирани на Windows инсталации на SQL Server, базирани на Linux инсталации на SQL Server и дори между Linux и базирани на Windows инсталации на SQL Server заедно.
Групите за наличност са тясно интегрирани с клъстерни технологии под формата на автоматично преминаване при отказ и защита на данните чрез репликиране на данни към съответните им вторични реплики. Въпреки това, не винаги е задължително да имате мениджър на клъстерни ресурси за конфигуриране на групи за наличност.
За да конфигурираме групите за наличност на SQL Server, ни трябва WSFC – Клъстер за отказване на Windows Server технология за Windows -базирани SQL Server инсталации и PACEMAKER за Linux -базирани SQL Server инсталации.
ПЕЙСМЕЙКЪР е мениджър на клъстерни ресурси с отворен код, който можем да използваме за управление на ресурси и осигуряване на наличност на системата, ако възникне някаква повреда в системите на Linux.
WSFC е продукт на Microsoft, разработен да поддържа изискванията за клъстер, базиран на Windows.
Когато погледнете конфигурираните групи за наличност в SQL Server и за двата типа ОС, изглежда подобно в SQL Server Management Studio.
Тази статия обаче обяснява групите за наличност между базирания на Ubuntu Linux SQL сървър инсталации с помощта на ПЕЙСМЕЙКЪР клъстерна технология, така че ще разгледам само тази конфигурация.
Конфигурация на тип клъстер
Както казах по-горе, имаме три варианта за конфигуриране на групи за наличност за SQL Server, в зависимост от операционната система:
- между базирани на Windows инсталации на SQL Server;
- между Linux-базирани SQL Server инсталации;
- между смесения тип Windows и Linux-базирани SQL Server инсталации.
Microsoft въведе Cluster_type конфигурационна настройка за идентифициране и конфигуриране на подходяща клъстерна технология за групи за наличност. Това е конфигурационен елемент, който определя кой тип клъстерна технология използваме за групите за наличност, без значение на коя ОС се базира екземплярът на SQL Server.
Можете да извлечете и потвърдите съществуващата конфигурация от типа Cluster, като използвате изглед за динамично управление на SQL Server (DMV) sys.availability_groups . Има две колони с име cluster_type и cluster_type_desc . Можем да прочетем тези колони, за да определим конфигурацията на клъстерния тип на настройката на групата за наличност.
Тази конфигурационна настройка има 3 стойности за изпълнение на изискванията за клъстерна технология за всеки вариант:
WSFC .Трябва да използвате опцията WSFC (клъстер за преодоляване на отказ на сървър на Windows), ако имате инсталации на SQL Server, базирани на Windows. Не се поддържа за базирани на Linux инсталации на SQL Server.
ВЪНШНА . Ако конфигурирате групи за наличност между базирани на Linux инсталации на SQL Server, трябва да използвате клъстерния мениджър PACEMAKER и да изберете ВЪНШЕН клъстер тип . Режимът на отказ също трябва да е ВЪНШЕН (в WSFC ще бъде Автоматичен).
НЯМА . Ако не искате да използвате технология за клъстериране за вашите групи за наличност, изберете НЯМА . Тази опция е приложима, ако искате да конфигурирате групи за наличност между базирани на Linux и Windows екземпляри на SQL Server. Дори ако сте конфигурирали клъстериране за вашата система, след като зададете стойността на типа клъстер на NONE, групите за наличност няма да използват клъстерната технология. Режимът за преодоляване на отказ за тип клъстер NONE винаги е Ръчен .
Нова настройка:Необходими синхронизирани вторични елементи за ангажимент
Започвайки със SQL Server 2017, Microsoft въведе нова настройка, наречена required_synchronized_secondaries_to_commit . Той активира опцията за автоматично преминаване при отказ, ако сте конфигурирали типа на клъстер като ВЪНШЕН за конфигурацията на клъстера PACEMAKER.
Стойността на тази настройка се задава по подразбиране, когато конфигурирате агента за ресурси на SQL Server mssql-server-ha и създайте конфигурацията на клъстера.
Освен това можете ръчно да промените стойността за вашите изисквания, като изпълните командата по-долу:
--Run below commands to change value for setting required_synchronized_secondaries_to_commit
--AGResourceName is the name of the resource configured for the Availability group
sudo pcs resource update <AGResourceName> required_synchronized_secondaries_to_commit=<Value>
Забележка:Можем да променим горната настройка само чрез Pacemaker на Linux. Невъзможно е да го модифицирате с помощта на оператора T-SQL за базирани на Linux разгръщания. Въпреки това, за внедряване, базирано на Windows, можем да променим тази настройка чрез израз на T-SQL.
По-долу са възможните стойности за required_synchronized_secondaries_to_commit
0 – Това означава, че вторичните реплики не трябва да бъдат синхронизирани със съответната първична реплика. По този начин той не поддържа автоматично преминаване при отказ. Трябва да инициирате ръчно преодоляването на отказ, ако основната реплика се повреди. Важно:има вероятност от загуба на данни, когато изберете тази стойност за конфигурация.
1 – Това означава, че поне една вторична реплика трябва да е в синхронизирано състояние, за да се постигне автоматично преминаване при отказ.
2 – Това означава, че и двете вторични реплики трябва да бъдат синхронизирани с първичната реплика. Поддържа се автоматично преминаване при отказ.
Реплика за участие в група за наличност
Броят на репликите, които могат да участват в група за наличност, зависи от инсталираното издание на SQL Server.
- Стандартният SQL сървър изданието поддържа само реплика с два възела за група за наличност заедно с допълнителната реплика само за конфигурация.
- SQL Server Enterprise изданието поддържа до девет реплики – една основна и осем вторични реплики.
Тъй като SQL Server Standard Edition поддържа само две реплики (една първична реплика и една вторична реплика), Microsoft въведе нова концепция, наречена реплика само за конфигурация в SQL Server 2017 CU1 за постигане на автоматично преминаване при отказ за SQL сървъри, работещи на системи Linux.
Има две възможни опции за дизайн:
- Три синхронни копия. Тази конфигурация може да бъде разгърната само с изданието SQL Server Enterprise. Ще има 3 копия на вашите бази данни за наличност. Тази архитектура позволява всички 3 функции за мащабиране на четене, висока наличност и защита на данните.
- Две синхронни реплики и реплика само за конфигурация. Можете да конфигурирате този дизайн и с помощта на стандартното издание на SQL Server, като изпълнявате две синхронни реплики в стандартното издание на SQL Server и 3 реплика на изданието SQL Server Express, което действа като реплика само за конфигурация. Това е рентабилен дизайн, който поддържа висока наличност с автоматично преминаване при отказ и защита на базата данни.
Реплика с два възела
Конфигурациите с реплика с два възела for Availability Groups е много популярна опция за внедряване за осигуряване на висока наличност на бази данни на SQL Server. Постигаме автоматичното преминаване при отказ с помощта на технологията Windows Server Failover Cluster и свидетел на споделяне на файлове в разгръщания на SQL Server, базирани на Windows.
Споделянето на файлове обикновено се използва на допълнителен възел в WSFC, за да осигури конфигурация на кворума за конфигурации на реплика с два възела. WSFC синхронизира всички конфигурационни метаданни както с реплики, така и с третия възел или свидетел на споделяне на файлове за плавно преминаване при отказ. Цялото арбитражно прехвърляне при отказ за базирана на Windows група за достъпност на SQL Server се случва на WSFC слой.
Ако искаме да постигнем автоматично преминаване при отказ за базирани на Linux SQL Server Availability Group внедрявания, горната конфигурация няма да работи. Това е така, защото WSFC може да се използва само за Windows-базирани SQL Server инсталации.
За да се справи с това ограничение и да даде възможност за автоматично преминаване при отказ за базирани на Linux разгръщания с две реплики, Microsoft въведе нова концепция.
Реплика само за конфигурация
Реплика само за конфигурация е опция, при която инсталираме допълнителен екземпляр на SQL Server на третия възел. Този възел ще работи като сървър-свидетел за конфигурацията на реплика с два възела, за да поддържа автоматично преминаване при отказ. Можем да създадем една реплика само за конфигурация за група за наличност .
За базирани на Linux екземпляри на SQL Server, където използваме типа на клъстер като EXTERNAL за PACEMAKER, арбитражът при отказ не работи на клъстерния слой като WSFC. Цялото арбитражно преодоляване на срив се случва на слоя на SQL Server, тъй като всички метаданни за конфигурацията на групата за наличност се съхраняват в главните бази данни на всяка реплика.
Microsoft въведе концепцията за реплика само за конфигурация за обработка на кворума за Linux-базирани SQL Server Availability Groups. Тази концепция не хоства никакви потребителски бази данни за участие в група за наличност. Той съхранява цялата информация за конфигурацията на Availability Group в главната база данни, за да гарантира, че всички арбитражи при отказ се извършват гладко.
Можете да използвате всяко издание на SQL Server за реплика само за конфигурация. Дори изданието на SQL Server Express ще е подходящо, за да спестите разходите ви за лиценз за третата реплика. Не забравяйте, че репликата само за конфигурация няма да хоства никаква база данни в групата за наличност. По този начин ще имате само две копия на бази данни в група за наличност.
По подразбиране required_synchronized_secondaries_to_commit е настроен на 0 когато използваме репликата само за конфигурация. Можем ръчно да променим тази стойност на 1, ако е необходимо.
Разгледайте диаграмата на дизайна на синхронната реплика с два възела и реплика само за конфигурация, за да постигнете автоматично преминаване при отказ и защита на данните.
Можем да видим, че има 3 виртуални машини с имена AOAGVM1, AOAGVM2 и AOAGVM3. Всички те се изпълняват от системата Ubuntu Linux, а SQL Server е конфигуриран и на трите Linux системи. Базите данни за наличност се хостват на AOAGVM1 и AOAGVM2.
AOAGVM1 действа като първична реплика, докато AOAGVM2 е вторична реплика. AOAGVM3 служи като реплика само за конфигурация, която е изданието на SQL Server Express. В тази трета реплика не се хостват потребителски бази данни.
Клъстерът на Pacemaker е конфигуриран между трите възела, за да поддържа клъстерната технология за конфигурация на група за достъпност, базирана на Linux.
За да конфигурираме или внедрим горния дизайн, трябва да изпълним следните стъпки:
- Инсталирайте SQL Server на три Ubuntu системи (изданието SQL Server Express ще е подходящо за реплика само за конфигуриране).
- Конфигуриране на групи за наличност между три възела.
- Конфигурирайте клъстера PACEMAKER между три възела.
- Добавете или интегрирайте група за наличност като ресурс в групата на клъстерите.
Разгледайте свързаната статия, за да завършите стъпка 1 (инсталиране на екземпляри на SQL Server на три възела).
Очаквайте следващата ми статия, където ще обясня стъпка по стъпка процеса за прилагане на горния дизайн. Нашата цел ще бъде да постигнем автоматично преминаване при отказ и защита на данните с помощта на синхронна реплика с 2 възела и реплика само за конфигурация.
Ще се радваме да чуем вашите мисли и практически съвети по този въпрос. Чувствайте се свободни да ги споделите в секцията за коментари.
