Тестването е трудоемка задача, но е задължителна преди всеки процес на надграждане на която и да е технология. В зависимост от типа надстройка може да е по-трудно или по-лесно, но винаги е необходимо, ако искате да сте сигурни, че вашите данни ще бъдат в безопасност. Има различни подходи за надграждане, в зависимост от бизнеса и толеранса на престой. Например процесът може да тества вашето приложение в отделна среда с новата версия, така че ще трябва да създадете нов клъстер за това. Друга възможност е да клонирате текущата си производствена среда и да я надстроите, което може да бъде полезно, тъй като можете да емулирате целия процес на надстройка и да избегнете изненади в бъдеще.
Извършвайки целия този процес на тестване ръчно, има голяма вероятност от човешка грешка и процесът ще бъде бавен, което може да повлияе на целта за време за възстановяване (RTO). В този блог ще видим как да автоматизираме тестването за надграждане на вашите PostgreSQL бази данни с помощта на ClusterControl.
Тип надстройки на база данни
Има два типа надстройки:малки надстройки и големи надстройки.
Незначителни надстройки
Това е най-често срещаното и безопасно надграждане и в повечето случаи се извършва на място. Тъй като нищо не е 100% сигурно, винаги трябва да имате резервни копия и възли в режим на готовност, така че в случай, че нещо се обърка с надстройката, можете да популяризирате възел в режим на готовност в предишната версия и вашите системи ще могат да работят без прекъсване.
Можете да извършите този вид надстройка с помощта на ClusterControl. За това отидете на ClusterControl -> Изберете вашия PostgreSQL клъстер -> Управление -> Надстройки.
На всеки избран възел процедурата за надстройка ще:
-
Стоп възел
-
Възел за надграждане
-
Начален възел
Главният възел в топологията на PostgreSQL няма да бъде надстроен. За да надстроите Master, друг възел трябва да бъде повишен, за да стане първо нов Master.
Основни надстройки
За големи надстройки не се препоръчва надстройката на място, тъй като рискът нещо да се обърка е твърде висок за производствена среда. Вместо това има различни подходи за извършване на надстройки.
Можете да клонирате текущия си клъстер от база данни, да го надстроите и да тествате приложението си там и когато приключите, ако всичко е минало добре, можете да го създадете отново, за да повторите процеса, за да направите истинското надграждане , или можете също да създадете нов клъстер в новата версия, да тествате приложението си и да превключвате трафика, когато е готово, и има още опции... Използването на Load Balancers е полезно тук за подобряване на високата наличност. Най-добрият подход зависи от толеранса на престой и целта за време за възстановяване (RTO).
Не можете да извършвате големи надстройки с ClusterControl директно, защото, както споменахме, първо трябва да тествате всичко, за да сте сигурни, че надстройката е безопасна, но можете да използвате различни функции на ClusterControl, за да тази задача е по-лесна. Така че нека видим някои от тези функции.
Разгръщане на тестова среда
За това не е нужно да създавате всичко от нулата. Вместо това можете да използвате ClusterControl, за да направите това по ръчен или автоматизиран начин.
Възстановяване на резервно копие на самостоятелен хост
В секцията Архивиране изберете резервно копие и ще видите опцията „Възстановяване и проверка на самостоятелен хост“, за да възстановите резервно копие в отделен възел.
Тук можете да посочите дали искате ClusterControl да инсталира софтуера в новия възел и деактивирайте защитната стена или AppArmor/SELinux (в зависимост от операционната система). За това се нуждаете от специален хост (или VM), който не е част от клъстера.
Можете да поддържате възела работещ или ClusterControl може да изключи базата данни услуга до следващото възстановяване. Когато приключи, ще видите възстановеното/проверено архивно копие в списъка с архиви, отбелязан с отметка.
Ако не искате да изпълнявате тази задача ръчно, можете да планирате този процес с помощта на функцията за проверка на архивиране, за да повтаряте тази задача периодично в задание за архивиране. Ще видим как да направим това в следващия раздел.
Автоматична проверка на архивиране на ClusterControl
За да автоматизирате тази задача, отидете на ClusterControl -> Изберете вашия PostgreSQL клъстер -> Архивиране -> Създаване на архивиране и изберете опцията Планирано архивиране. Функцията за автоматично потвърждаване на архивиране е налична само за планирано архивиране.
Във втората стъпка се уверете, че сте активирали опцията Verify Backup, и попълнете необходимата информация.
Когато задачата приключи, можете да видите иконата за проверка в ClusterControl Резервен раздел, същият, който ще имате, като извършите проверката по ръчен начин, с тази разлика, че не е нужно да се притеснявате за задачата за възстановяване. ClusterControl ще възстановява архива всеки път автоматично и можете да тествате приложението си с най-новите данни.
Създаване на клъстер от архивиране
Друг начин за създаване на тестова среда е чрез създаване на нов клъстер от резервно копие на вашия първичен клъстер. За това отидете на ClusterControl -> Изберете вашия PostgreSQL клъстер -> Архивиране. Там изберете архива, който да се възстанови от списъка, и изберете Възстановяване -> Създаване на клъстер от архив.
Тази опция ще създаде нов PostgreSQL клъстер от избрания архив.
Трябва да добавите идентификационните данни за операционната система и базата данни и информацията, за да внедрите нов клъстер. Когато тази задача приключи, ще видите новия клъстер в потребителския интерфейс на ClusterControl.
Репликация от клъстер в клъстер
След ClusterControl 1.7.4 има функция, наречена репликация от клъстер към клъстер. Позволява ви да имате репликация, работеща между два автономни клъстера.
Създаване на репликация от клъстер към клъстер
Отидете на ClusterControl -> Изберете своя PostgreSQL клъстер -> Действия на клъстер -> Създайте подчинен клъстер.
Подчинения клъстер ще бъде създаден чрез поточно предаване на данни от текущия първичен клъстер.
Трябва да посочите SSH идентификационни данни и порт, име за вашия подчинен клъстер, и ако искате ClusterControl да инсталира съответния софтуер и конфигурации вместо вас.
След като настроите информацията за SSH достъп, трябва да дефинирате версията на базата данни, datadir, порт и идентификационни данни на администратора. Тъй като ще използва поточно репликация, уверете се, че използвате същата версия на базата данни и идентификационните данни трябва да са същите, използвани от първичния клъстер.
В тази стъпка трябва да добавите сървъра към новия подчинен клъстер . За тази задача можете да въведете както IP адрес, така и име на хост на възела на базата данни.
Можете да наблюдавате състоянието на заданието в монитора на активността на ClusterControl. След като задачата приключи, можете да видите клъстера в главния екран на ClusterControl.
Автоматично възстановяване и отказ
Имайки активирана функция за автоматично възстановяване, в случай на неуспех, ClusterControl ще повиши най-напредналия резервен възел до основен, както и ще ви уведоми за проблема. Освен това не успява да се репликира върху останалите възли в режим на готовност от новия първичен сървър.
Ако в топологията има средства за балансиране на натоварването, ClusterControl ще ги конфигурира повторно, за да приложи промените в топологията.
Можете също да изпълните Failover ръчно, ако е необходимо. Отидете на ClusterControl -> Изберете вашия PostgreSQL клъстер -> Възли -> Изберете възела, който да бъде повишен -> Действия на възел -> Повишаване на подчинен.
По този начин, ако нещо се обърка по време на надстройката, можете да използвате ClusterControl, за да го поправите възможно най-скоро.
Автоматизиране на нещата с ClusterControl CLI
ClusterControl CLI, известен също като s9s, е инструмент от командния ред, въведен във версия 1.4.1 на ClusterControl за взаимодействие, управление и управление на клъстери от база данни с помощта на системата ClusterControl. ClusterControl CLI отваря врата за клъстерна автоматизация, където можете лесно да го интегрирате със съществуващи инструменти за автоматизация на внедряване като Ansible, Puppet, Chef и т.н. Нека видим сега някои примери за този инструмент.
Надстройване
$ s9s cluster --cluster-id=9 \
--check-pkg-upgrades \
--log
$ s9s cluster --cluster-id=9 \
--available-upgrades \
--nodes=10.10.10.122 \
--log \
--print-json
$ s9s cluster --cluster-id=9 \
--upgrade-cluster \
--nodes=10.10.10.122 \
--logПроверка на архивите
$ s9s backup --verify \
--backup-id=2 \
--test-server=10.10.10.124 \
--cluster-id=9 \
--logРепликация от клъстер в клъстер
$ s9s cluster --create \
--cluster-name=PostgreSQL-c2c \
--cluster-type=postgresql \
--provider-version=13 \
--nodes=10.10.10.125 \
--os-user=root \
--os-key-file=/root/.ssh/id_rsa \
--db-admin=admin \
--db-admin-passwd=********* \
--vendor=postgres \
--remote-cluster-id=9 \
--logНасърчаване на подчинен възел
$ s9s cluster --promote-slave \
--cluster-id=9 \
--nodes='10.10.10.122' \
--logЗаключение
Надстройките са необходими, но отнемащи време задачи, тъй като трябва да тествате приложението си, за да избегнете проблеми по време на процеса. Внедряването на тестова среда всеки път, когато трябва да надстроите и поддържате тази актуална без инструмент за автоматизация, може да бъде трудно.
ClusterControl ви позволява да извършвате незначителни надстройки от потребителския интерфейс или CLI на ClusterControl или дори да разгръщате тестовата среда, за да направите задачата за надграждане по-лесна и по-безопасна. Можете също да го интегрирате с различни инструменти за автоматизация като Ansible, Puppet и др.
