MariaDB
 sql >> база данни >  >> RDS >> MariaDB

Автоматизирано тестване на процеса на надстройка за MySQL/MariaDB/Percona сървър

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

Ако искате да направите всички тези неща ръчно, има голяма вероятност от човешка грешка и процесът ще бъде бавен. В този блог ще видим как да автоматизираме тестването за надграждане на вашите MySQL, MariaDB или Percona Server бази данни с помощта на ClusterControl.

Тип надстройки

Има два типа надстройки:малки надстройки и големи надстройки.

Незначителни надстройки

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

Можете да извършите този вид надстройка с помощта на ClusterControl. За това отидете на ClusterControl -> Изберете Cluster -> Manage -> Upgrades.

На всеки избран възел процедурата за надстройка ще:

  • Стоп възел

  • Възел за надграждане

  • Начален възел

Главният възел в топологията на репликация няма да бъде надстроен. За да надстроите Master, друг възел трябва да бъде повишен, за да стане първо нов Master.

Основни надстройки

За големи надстройки не се препоръчва надстройката на място, тъй като рискът нещо да се обърка е твърде висок за производствена среда. Вместо това можете да клонирате текущия си клъстер от база данни и да тествате приложението си там и когато приключите, можете да го създадете отново или дори да създадете нов клъстер в новата версия и да превключите трафика, когато е готов. Има различни подходи за тези надстройки. Можете да надстроите възлите един по един или да създадете различен клъстер, репликиращ трафика от текущия, можете също да използвате балансьори на натоварване за подобряване на високата наличност и повече опции. Най-добрият подход зависи от толеранса на престой и целта за време за възстановяване (RTO).

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

Резервни копия

Резервните копия са задължителни преди всяка надстройка. Една добра политика за архивиране може да избегне големи проблеми за бизнеса. И така, нека видим как ClusterControl може да автоматизира това.

Създаване на резервно копие

Отидете на ClusterControl -> Изберете клъстера -> Архивиране -> Създаване на архив.

Можете да създадете ново архивиране или да конфигурирате насрочено такова.

Можете да изберете различни методи за архивиране в зависимост от технологията на базата данни и в същия раздел можете да изберете сървъра, от който да вземете архива, къде искате да съхранявате архива и дали искате да качите резервното копие в облака (AWS, Azure или Google Cloud) в същото задание.

Можете също да компресирате и шифровате резервното си копие и да посочите периода на запазване, наред с други опции.

В секцията за архивиране можете да видите напредъка на архивирането и информация като метод, размер, местоположение и други.

Разгръщане на тестова среда

За това не е нужно да създавате всичко от нулата. Вместо това можете да използвате ClusterControl, за да направите това по ръчен или автоматизиран начин.

Възстановяване на резервно копие на самостоятелен хост

В секцията Архивиране можете да изберете опцията „Възстановяване и проверка на самостоятелен хост“, за да възстановите резервно копие в отделен възел.

Тук можете да посочите дали искате ClusterControl да инсталира софтуера в новия възел и да деактивирате защитната стена или AppArmor/SELinux (в зависимост от операционната система). За това се нуждаете от специален хост (или VM), който не е част от клъстера.

Можете да поддържате възела работещ или ClusterControl може да изключи услугата за база данни до следващото задание за възстановяване. Когато приключи, ще видите възстановения/проверения архив в списъка с архиви, отбелязан с отметка.

Ако не искате да изпълнявате тази задача ръчно, можете да планирате този процес с помощта на функцията за проверка на архивиране, за да повтаряте тази задача периодично в задание за архивиране. Ще видим как да направим това в следващия раздел.

Автоматична проверка на архивиране на ClusterControl

За да автоматизирате тази задача, отидете на ClusterControl -> Изберете вашия клъстер -> Архивиране -> Създаване на архивиране и изберете опцията Планирано архивиране.

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

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

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

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

Ако в топологията има средства за балансиране на натоварването, ClusterControl ще ги конфигурира повторно, за да приложи промените в топологията.

Можете също да изпълните Failover ръчно, ако е необходимо. Отидете на ClusterControl -> Изберете клъстера -> Възли -> Изберете възела, който да бъде повишен -> Действия на възел -> Повишаване на подчинен.

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

Автоматизиране на нещата с ClusterControl CLI

ClusterControl CLI, известен също като s9s, е инструмент от командния ред, въведен във версия 1.4.1 на ClusterControl за взаимодействие, управление и управление на клъстери от база данни с помощта на системата ClusterControl. ClusterControl CLI отваря врата за клъстерна автоматизация, където можете лесно да го интегрирате със съществуващи инструменти за автоматизация на внедряване като Ansible, Puppet, Chef и т.н. Нека видим сега някои примери за този инструмент.

Надстройване

$ s9s cluster --cluster-id=19 \
--check-pkg-upgrades \
--log
$ s9s cluster --cluster-id=19 \
--available-upgrades \
--nodes='10.10.10.146' \
--log \
--print-json
$ s9s cluster --cluster-id=19 \
--upgrade-cluster \
--nodes='10.10.10.146' \
--log

Създаване на резервно копие

$ s9s backup --create \
--backup-method=mysqldump \
--cluster-id=2 \
--nodes=10.10.10.146:3306 \
--on-controller \
--backup-directory=/storage/backups
--log

Възстановяване на архива

$ s9s backup --restore \
--cluster-id=19 \
--backup-id=3 \
--wait

Проверка на архивите

$ s9s backup --verify \
--backup-id=3 \
--test-server=10.10.10.151 \
--cluster-id=19 \
--log

Насърчаване на подчинен възел

$ s9s cluster --promote-slave \
--cluster-id=19 \
--nodes='10.10.10.146' \
--log

Заключение

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

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


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Представяне на мониторинг на база данни, базиран на агенти с ClusterControl 1.7

  2. Използване на MySQL Galera Cluster Replication за създаване на гео-разпределен клъстер:Част първа

  3. 2 начина да получите краткото име на месеца от дата в MariaDB

  4. Поправете грешка 1064 (42000) при използване на оператора MINUS в MariaDB

  5. Как да направите възстановяване по време на MySQL и MariaDB данни с помощта на ClusterControl