Автоматизирано тестване на процеса на надстройка за PXC/MariaDB Galera Cluster

Надстройването на вашата база данни за базирани на Galera клъстери като Percona XtraDB Cluster (PXC) или MariaDB Galera Cluster може да бъде предизвикателство, особено за среда, базирана на продукция. Не можете да си позволите да загубите състоянието на вашата висока наличност и да го изложите на риск.

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

При всички притеснения автоматизацията помага за постигане на по-ефективен процес на надстройка и помага за избягване на човешка грешка и подобрява RTO.

Как да управлявате PXC/MariaDB процеса на надстройка на клъстера на Galera 

Надграждането на вашия PXC/MariaDB Galera Cluster изисква подходяща документация и процес на поток, който изброява нещата, които трябва да се направят и какво да направите, в случай че нещата тръгнат на юг. Това означава, че трябва да бъде изготвен план за непрекъснатост на бизнеса, който ще обхваща и вашия план за възстановяване след бедствие. Не можете да си позволите да загубите бизнеса си в случай на проблеми.

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

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

Има два типа надстройка за PCX или MariaDB Galera Cluster, за които трябва да сте наясно. Това са основната надстройка на версията и незначителната надстройка на версията или често наричана надстройка на място. Надстройката на място е мястото, където можете да надстроите версията на вашата база данни до нейната най-нова второстепенна версия, като използвате същите двоични данни на вашата база данни. Няма да има физически промени в самите данни, а само в тяхната двоична база данни или в основните софтуерни пакети.

Надграждане на PCX или MariaDB Galera Cluster до основна версия

Надстройването до основна версия може да бъде предизвикателство, особено за производствена среда. Той включва сложен тип конфигурация на база данни и специални вградени функции на PXC или MariaDB Galera Cluster. Пространствено-времеви данни, маркирани във времето, машинни данни или всякакви многостранни данни са много консервативни и чувствителни към надстройки. Не можете да приложите надстройка на място за този процес, защото биха били направени много големи промени. Освен ако нямате много малки данни или данни, състоящи се от идемпотенти или данни, които могат да се генерират лесно, може да бъде безопасно да се направи, стига да знаете, че въздействието няма да засегне данните ви.

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

Надстройване на PCX или MariaDB Galera Cluster до второстепенна версия

Незначителното надграждане на версията, наричано вградено надстройка, обикновено е по-безопасен подход за извършване на процес на надстройка. Това е така, защото най-често срещаните промени за тази версия са корекции или подобрения за сигурност и експлоатиране, грешки (обикновено сериозни) или проблеми със съвместимостта, които изискват корекции, особено ако текущият хардуер или ОС са имали приложени промени, които могат да причинят също така и базата данни да не функционират правилно. Въпреки че въздействието обикновено може да бъде възстановимо с минимален ефект, все пак е задължително да погледнете и прочетете регистъра на промените, който е бил прехвърлен към конкретната незначителна надстройка на версията.

Разгръщането на заданието за извършване на процеса на надстройка е идеален пример за автоматизация. Обичайният поток е много повтарящ се и най-вече не причинява вреда на вашия съществуващ PXC или MariaDB Galera Cluster. Най-важното е, че след надстройката ще продължи автоматичното тестване, за да се определи, че настройката, конфигурацията, ефективността и функционалността не са нарушени.

Избягвайте фиаско! Бъдете готови, автоматизирайте го!

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

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

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

Автоматизиране след процеса на надстройка

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

Изпълнете mysql_upgrade

Много е важно и изключително препоръчително да изпълните mysql_upgrade, след като процесът на надстройка приключи. mysql_upgrade търси несъвместимости с надстроения MySQL сървър, като прави следните неща:

• Той надгражда системните таблици в mysql схемата, така че да можете да се възползвате от новите привилегии или възможности, които може са добавени.

• Той надгражда схемата за производителност и системната схема.

• Проучва потребителски схеми.

Mysql_upgrade определя дали дадена таблица има проблеми като несъвместимост поради промени в най-новата версия след надстройката и се опитва да го разреши чрез поправяне на таблицата. В противен случай, ако не успее, вашият тест за автоматизация ще трябва да се провали и не трябва да продължава към нещо друго. Първо трябва да се проучи и да се направи ръчен ремонт.

Проверете регистрационните файлове за грешки

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

Извършете единичен тест

TDD (Test Driven Development) среда на база данни е подход за разработка на софтуер, при който има поредица от тестови случаи, които трябва да бъдат валидирани и да се определи дали валидирането е вярно (успешно) или невярно (неуспешно). Нещо като това, което имаме на екранната снимка по-долу:

Изображението с любезното съдействие на guru99.com

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

Ако попитате, наистина ли е необходимо да се извърши единичен тест след надстройката? Разбира се, че е! Не е задължително да изпълнявате това в производствената среда. По време на фазите на тестване, т.е. първо надграждане на вашите QA, среда за разработка/постановка, тя трябва да се приложи в тази област. Данните трябва да бъдат точно копие, поне или почти същото като тяхната производствена среда. Вашата цел тук е да избегнете нежелани резултати и определено грешни логически резултати. Разбира се, трябва да се грижите добре за данните си и да определите дали резултатите издържат теста за валидиране.

Ако възнамерявате да стартирате с вашата продукция, тогава го направете. Въпреки това, не бъдете толкова строги, колкото вашата фаза на тестване, приложена в средата за качество, разработка или етапна среда. Това е така, защото трябва да планирате времето си въз основа на наличния прозорец за поддръжка и да избягвате закъснения и по-дълги RTO.

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

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

Проверете идентичността на заявките

Най-често срещаният инструмент, който можете да използвате, е pt-upgrade на Percona. Той проверява дали резултатите от заявката са идентични на различни сървъри. Той изпълнява заявки въз основа на дадените регистрационни файлове и предоставената връзка (или наречена DSN), след което сравнява резултатите и отчита всички значителни разлики. Той предлага повече от това като опции за събиране или анализиране на заявките, като например чрез tcpdump.

Използването на pt-upgrade е лесно. Например, можете да стартирате със следната команда:

## Comparing via slow log for the given hosts
pt-upgrade h=host1 h=host2 slow.log

## or use fingerprints, useful for debugging purposes
pt-upgrade --fingerprints --run-time=1h mysqld-slow.log h=127.0.0.1,P=5091 h=127.0.0.1,P=5517

## or with tcpdump,
tcpdump -i eth0 port 3306 -s 65535  -x -n -q -tttt     \
  | pt-query-digest --type tcpdump --no-report --print \
  | pt-upgrade h=host1 h=host2

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

Как да автоматизираме процеса на тестване?

В предишните ни блогове сме представили различни начини за автоматизиране на вашите бази данни. Най-често срещаните инструменти, които са на мода, са тези софтуерни инструменти за внедряване на IaC (Инфраструктура като код). Можете да използвате Puppet, Chef, SaltStack или Ansible, за да свършите работата.

Моите предпочитания винаги са били Ansible за извършване на автоматизирано тестване, което ми позволява да създавам книги с игри според ролята му. Разбира се, не мога да създам един цял автомат, който да прави всички неща, защото ситуацията и средата варират. Въз основа на дадените типове надстройка по-рано (основно срещу второстепенно надстройка), трябва да разграничите неговия процес. Дори ако това е просто надстройка на място, все пак трябва да се уверите, че вашите учебници ще изпълняват правилната работа.

ClusterControl е вашият приятел за автоматизация на база данни!

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

ClusterControl предлага незначителни надстройки на версията, което осигурява удобство на DBA при извършване на надстройки. Той също така прави mysql_upgrade в движение. Така че не е необходимо да го изпълнявате ръчно. ClusterControl също така открива нови версии, които трябва да бъдат надградени, и препоръчва следващите стъпки, които трябва да направите. В случай на неизправност, надстройката няма да продължи.

Ето пример за второстепенната задача за надстройка:

Ако погледнете внимателно, mysql_upgrade работи успешно. Въпреки че не препоръчва и прави автоматично надграждане на главния, това е защото не е правилният подход за продължаване. В такъв случай трябва да повишите новия подчинен, след което да понижите главната като подчинен, за да извършите надграждането.

Заключение

Страхотното нещо с ClusterControl е, че можете да включите проверка на регистрационни файлове за грешки, да извършите единичен тест, да проверите идентичността на заявките чрез създаване на съветници. Не е трудно да го направите. Можете да се обърнете към предишния ни блог Използване на ClusterControl Advisor за създаване на проверки за SELinux и Meltdown/Spectre:Част първа. Това илюстрира как можете да се възползвате и да задействате следващата работа, след като надстройката бъде изпълнена. ClusterControl има вградени сигнали или аларми, които могат да се интегрират към любимите ви системи за предупреждение на трети страни, за да ви уведомят за текущото състояние на вашето автоматизирано тестване.