Има няколко начина за разгръщане на база данни. Можете да го инсталирате на ръка, можете да разчитате на широко достъпните инструменти за оркестриране на инфраструктурата като Ansible, Chef, Puppet или Salt. Тези инструменти са много популярни и е доста лесно да се намерят скриптове, рецепти, учебници, които ще ви помогнат да автоматизирате инсталирането на клъстер от база данни. Има и по-специализирани платформи за автоматизация на бази данни, като ClusterControl, които също могат да се използват за автоматизирано внедряване. Какъв би бил най-добрият начин за разгръщане на вашия клъстер? Колко време всъщност ще ви е необходимо, за да го разгърнете?
Първо, нека изясним какво искаме да направим. Да предположим, че ще внедрим Percona XtraDB Cluster 5.7. Той ще се състои от три възела и за това ще използваме три виртуални машини Vagrant, работещи с Ubuntu 16.04 (изображение bento/ubuntu-16.04). Ще се опитаме да разположим клъстер ръчно, след това с помощта на Ansible и ClusterControl. Нека видим как ще изглеждат резултатите.
Ръчно внедряване
Настройка на хранилището - 1 минута, 45 секунди.
На първо място, трябва да конфигурираме хранилища на Percona на всички възли на Ubuntu. Бързото търсене в Google, ssh във виртуалните машини и изпълнението на необходимите команди отнема 1m45s
Намерихме следната страница с инструкции:
https://www.percona.com/doc/percona-repo-config/percona-release.html
и ние изпълнихме стъпки, описани в раздел „БАЗИРАНИ НА GNU/LINUX ДИСТРИБУЦИИ НА DEB“. Изпълнихме и apt update, за да обновим кеша на apt.
Инсталиране на PXC възли - 2 минути 45 секунди
Тази стъпка основно се състои от изпълнение на:
[email protected]:~# apt install percona-xtradb-cluster-5.7Останалото зависи най-вече от скоростта на вашата интернет връзка, тъй като пакетите се изтеглят. Вашето въвеждане също ще бъде необходимо (ще предавате парола за суперпотребителя), така че да не е инсталация без надзор. Когато всичко е направено, ще се окажете с три работещи възела на Percona XtraDB Cluster:
root 15488 0.0 0.2 4504 1788 ? S 10:12 0:00 /bin/sh /usr/bin/mysqld_safe
mysql 15847 0.3 28.3 1339576 215084 ? Sl 10:12 0:00 \_ /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=mysql --wsrep-provider=/usr/lib/galera3/libgalera_smm.so --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --wsrep_start_position=00000000-0000-0000-0000-000000000000:-1Конфигуриране на PXC възли - 3 минути, 25 секунди
Тук започва трудната част. Наистина е трудно да се изчисли опитът и колко време би трябвало на човек, за да разбере какво е необходимо да се направи. Какво е добре, търсенето в Google „как да инсталирам percona xtrabdb клъстер“ насочва към документацията на Percona, която описва как трябва да изглежда процесът. Все пак може да отнеме повече или по-малко време, в зависимост от това колко сте запознати с PXC и Galera като цяло. В най-лошия случай няма да сте наясно с каквито и да било допълнителни необходими действия и ще се свържете с вашия PXC и ще започнете да работите с него, без да осъзнавате, че всъщност имате три възела, всеки от които образува собствен клъстер.
Да предположим, че следваме препоръката от Percona и насрочваме само тези стъпки да бъдат изпълнени. Накратко, променихме конфигурационните файлове според инструкциите на уебсайта на Percona, също така се опитахме да стартираме първия възел:
[email protected]:~# /etc/init.d/mysql bootstrap-pxc
mysqld: [ERROR] Found option without preceding group in config file /etc/mysql/my.cnf at line 10!
mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
mysqld: [ERROR] Found option without preceding group in config file /etc/mysql/my.cnf at line 10!
mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
mysqld: [ERROR] Found option without preceding group in config file /etc/mysql/my.cnf at line 10!
mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
mysqld: [ERROR] Found option without preceding group in config file /etc/mysql/my.cnf at line 10!
mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
* Bootstrapping Percona XtraDB Cluster database server mysqld ^CТова не изглеждаше правилно. За съжаление инструкциите не бяха кристално ясни. Отново, ако не знаете какво се случва, ще отделите повече време, опитвайки се да разберете какво се е случило. За щастие stackoverflow.com е много полезен (въпреки че не е първият отговор в списъка, който получихме) и трябва да разберете, че пропускате заглавката на секцията [mysqld] във вашия /etc/mysql/my.cnf файл. Добавянето на това към всички възли и повтарянето на процеса на стартиране реши проблема. Общо прекарахме 3 минути и 25 секунди (без да търсим в Гугъл за грешката, тъй като веднага забелязахме какъв е проблемът).
Конфигуриране за SST, привеждане на други възли в клъстера – Започвайки от 8 минути до безкрайност
Инструкциите на уебсайта на Percona са доста ясни. След като имате един възел и работи, просто започнете останалите възли и ще се оправите. Опитахме това и не успяхме да видим повече възли, присъединяващи се към клъстера. Тук е практически невъзможно да се каже колко време ще отнеме за диагностициране на проблема. Отне ни 6-7 минути, но за да можете да го направите бързо, трябва да:
- Бъдете запознати с това как е структурирана PXC конфигурацията:
[email protected]:~# tree /etc/mysql/ /etc/mysql/ ├── conf.d │ ├── mysql.cnf │ └── mysqldump.cnf ├── my.cnf -> /etc/alternatives/my.cnf ├── my.cnf.fallback ├── my.cnf.old ├── percona-xtradb-cluster.cnf └── percona-xtradb-cluster.conf.d ├── client.cnf ├── mysqld.cnf ├── mysqld_safe.cnf └── wsrep.cnf - Разберете как работят директивите !include и !includedir в конфигурационните файлове на MySQL
- Разберете как MySQL обработва едни и същи променливи, включени в множество файлове
- Знайте какво да търсите и имайте предвид конфигурациите, които биха довели до самозареждане на възел, за да образува клъстер сам по себе си.
Проблемът беше свързан с факта, че инструкциите не споменават никакъв файл освен /etc/mysql/my.cnf, където всъщност трябваше да модифицираме /etc/mysql/percona-xtradb-cluster.conf.d/wsrep .cnf Този файл съдържа празна променлива:
wsrep_cluster_address=gcomm://и такава конфигурация принуждава възела да се зарежда, тъй като няма информация за други възли, към които да се присъедини. Зададохме тази променлива в /etc/mysql/my.cnf, но по-късно беше включен файл wsrep.cnf, презаписвайки нашата настройка.
Този проблем може да бъде сериозен блокиращ фактор за хора, които не са запознати наистина с това как работят MySQL и Galera, което води до часове, ако не и повече отстраняване на грешки.
Общо време за инсталиране - 16 минути (ако сте MySQL DBA като мен)
Успяхме да инсталираме Percona XtraDB Cluster за 16 минути. Трябва да имате предвид няколко неща - не сме настроили конфигурацията. Това е нещо, което ще изисква повече време и знания. PXC възелът идва с някаква проста конфигурация, свързана най-вече с двоично регистриране и репликация на набора за запис на Galera. Няма настройка на InnoDB. Ако не сте запознати с вътрешните елементи на MySQL, това са часове, ако не и дни за четене и запознаване с вътрешните механизми. Друго важно нещо е, че това е процес, който ще трябва да приложите повторно за всеки клъстер, който разгръщате. Накрая успяхме да идентифицираме проблема и да го разрешим много бързо поради нашия опит с Percona XtraDB Cluster и MySQL като цяло. Случайният потребител най-вероятно ще прекара значително повече време, опитвайки се да разбере какво се случва и защо.
Ansible Playbook
Сега, към автоматизацията с Ansible. Нека се опитаме да намерим и използваме ansible playbook, който бихме могли да използваме повторно за всички по-нататъшни внедрявания. Нека видим колко време ще отнеме да направим това.
Конфигуриране на SSH свързаност - 1 минута
Ansible изисква SSH свързаност между всички възли, за да ги свърже и конфигурира. Генерирахме SSH ключ и го разпределихме ръчно между възлите.
Намиране на Ansible Playbook - 2 минути 15 секунди
Основният проблем тук е, че има толкова много учебници, че е невъзможно да се реши кое е най-доброто. Като такива решихме да отидем с топ 3 резултата в Google и да се опитаме да изберем един. Решихме https://github.com/cdelgehier/ansible-role-XtraDB-Cluster, тъй като изглежда е по-конфигурируем от останалите.
Клониране на хранилище и инсталиране на Ansible - 30 секунди
Това става бързо, всичко, от което се нуждаехме, беше да
apt install ansible git
git clone https://github.com/cdelgehier/ansible-role-XtraDB-Cluster.gitПодготовка на инвентарен файл - 1 минута 10 секунди
Тази стъпка също беше много проста, създадохме инвентарен файл, използвайки пример от документацията. Просто заменихме IP адресите на възлите с това, което сме конфигурирали в нашата среда.
Подготовка на тетрадка – 1 минута 45 секунди
Решихме да използваме най-обширния пример от документацията, който включва и малко настройка на конфигурацията. Подготвихме правилна структура за Ansible (нямаше такава информация в документацията):
/root/pxcansible/
├── inventory
├── pxcplay.yml
└── roles
└── ansible-role-XtraDB-ClusterСлед това го стартирахме, но веднага получихме грешка:
[email protected]:~/pxcansible# ansible-playbook pxcplay.yml
[WARNING]: provided hosts list is empty, only localhost is available
ERROR! no action detected in task
The error appears to have been in '/root/pxcansible/roles/ansible-role-XtraDB-Cluster/tasks/main.yml': line 28, column 3, but may
be elsewhere in the file depending on the exact syntax problem.
The offending line appears to be:
- name: "Include {{ ansible_distribution }} tasks"
^ here
We could be wrong, but this one looks like it might be an issue with
missing quotes. Always quote template expression brackets when they
start a value. For instance:
with_items:
- {{ foo }}
Should be written as:
with_items:
- "{{ foo }}"Това отне 1 минута и 45 секунди.
Коригиране на проблема със синтаксиса на Playbook – 3 минути 25 секунди
Грешката беше подвеждаща, но общото правило е да опитате по-нова версия на Ansible, което направихме. Потърсихме в Google и намерихме добри инструкции на уебсайта на Ansible. Следващият опит за стартиране на книгата също беше неуспешен:
TASK [ansible-role-XtraDB-Cluster : Delete anonymous connections] *****************************************************************************************************************************************************************************************************************
fatal: [node2]: FAILED! => {"changed": false, "msg": "The PyMySQL (Python 2.7 and Python 3.X) or MySQL-python (Python 2.X) module is required."}
fatal: [node3]: FAILED! => {"changed": false, "msg": "The PyMySQL (Python 2.7 and Python 3.X) or MySQL-python (Python 2.X) module is required."}
fatal: [node1]: FAILED! => {"changed": false, "msg": "The PyMySQL (Python 2.7 and Python 3.X) or MySQL-python (Python 2.X) module is required."}Настройването на новата версия на Ansible и стартирането на книгата до тази грешка отне 3 минути и 25 секунди.
Коригиране на липсващия Python модул - 3 минути 20 секунди
Очевидно ролята, която използвахме, не се погрижи за своите предпоставки и липсваше модул на Python за свързване и защита на клъстера Galera. Първо се опитахме да инсталираме MySQL-python чрез pip, но стана ясно, че това ще отнеме повече време, тъй като изисква mysql_config:
[email protected]:~# pip install MySQL-python
Collecting MySQL-python
Downloading https://files.pythonhosted.org/packages/a5/e9/51b544da85a36a68debe7a7091f068d802fc515a3a202652828c73453cad/MySQL-python-1.2.5.zip (108kB)
100% |████████████████████████████████| 112kB 278kB/s
Complete output from command python setup.py egg_info:
sh: 1: mysql_config: not found
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/tmp/pip-build-zzwUtq/MySQL-python/setup.py", line 17, in <module>
metadata, options = get_config()
File "/tmp/pip-build-zzwUtq/MySQL-python/setup_posix.py", line 43, in get_config
libs = mysql_config("libs_r")
File "/tmp/pip-build-zzwUtq/MySQL-python/setup_posix.py", line 25, in mysql_config
raise EnvironmentError("%s not found" % (mysql_config.path,))
EnvironmentError: mysql_config not found
----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-zzwUtq/MySQL-python/Това се предоставя от библиотеките за разработка на MySQL, така че ще трябва да ги инсталираме ръчно, което беше почти безсмислено. Решихме да използваме PyMySQL, който не изисква други пакети за инсталиране. Това ни доведе до друг проблем:
TASK [ansible-role-XtraDB-Cluster : Delete anonymous connections] *****************************************************************************************************************************************************************************************************************
fatal: [node3]: FAILED! => {"changed": false, "msg": "unable to connect to database, check login_user and login_password are correct or /root/.my.cnf has the credentials. Exception message: (1698, u\"Access denied for user 'root'@'localhost'\")"}
fatal: [node2]: FAILED! => {"changed": false, "msg": "unable to connect to database, check login_user and login_password are correct or /root/.my.cnf has the credentials. Exception message: (1698, u\"Access denied for user 'root'@'localhost'\")"}
fatal: [node1]: FAILED! => {"changed": false, "msg": "unable to connect to database, check login_user and login_password are correct or /root/.my.cnf has the credentials. Exception message: (1698, u\"Access denied for user 'root'@'localhost'\")"}
to retry, use: --limit @/root/pxcansible/pxcplay.retryДо този момент прекарахме 3 минути и 20 секунди.
Коригиране на грешка „Отказан достъп“ – 18 минути 55 секунди
Според грешката се уверихме, че конфигурацията на MySQL е подготвена правилно и че включва правилен потребител и парола за свързване с базата данни. Това, за съжаление, не проработи според очакванията. Проучихме допълнително и установихме, че ролята не е създала правилно root потребител, въпреки че маркира стъпката като завършена. Направихме кратко разследване, но решихме да направим ръчната корекция, вместо да се опитваме да отстраним грешките в книгата, което ще отнеме много повече време от стъпките, които направихме. Току-що създадохме ръчно потребители [email protected] и [email protected] с правилни пароли. Това ни позволи да преминем тази стъпка към друга грешка:
TASK [ansible-role-XtraDB-Cluster : Start the master node] ************************************************************************************************************************************************************************************************************************
skipping: [node1]
skipping: [node2]
skipping: [node3]
TASK [ansible-role-XtraDB-Cluster : Start the master node] ************************************************************************************************************************************************************************************************************************
skipping: [node1]
skipping: [node2]
skipping: [node3]
TASK [ansible-role-XtraDB-Cluster : Create SST user] ******************************************************************************************************************************************************************************************************************************
skipping: [node1]
skipping: [node2]
skipping: [node3]
TASK [ansible-role-XtraDB-Cluster : Start the slave nodes] ************************************************************************************************************************************************************************************************************************
fatal: [node3]: FAILED! => {"changed": false, "msg": "Unable to start service mysql: Job for mysql.service failed because the control process exited with error code. See \"systemctl status mysql.service\" and \"journalctl -xe\" for details.\n"}
fatal: [node2]: FAILED! => {"changed": false, "msg": "Unable to start service mysql: Job for mysql.service failed because the control process exited with error code. See \"systemctl status mysql.service\" and \"journalctl -xe\" for details.\n"}
fatal: [node1]: FAILED! => {"changed": false, "msg": "Unable to start service mysql: Job for mysql.service failed because the control process exited with error code. See \"systemctl status mysql.service\" and \"journalctl -xe\" for details.\n"}
to retry, use: --limit @/root/pxcansible/pxcplay.retryЗа този раздел прекарахме 18 минути и 55 секунди.
Коригиране на проблем със „Стартиране на подчинените възли“ (част 1) - 7 минути 40 секунди
Опитахме няколко неща, за да решим този проблем. Опитахме се да посочим възел, използвайки неговото име, опитахме се да превключим имената на групи, нищо не реши проблема. Решихме да почистим околната среда с помощта на скрипта, предоставен в документацията, и да започнем от нулата. Не го почисти, а само влоши нещата. След 7 минути и 40 секунди решихме да изтрием виртуалните машини, да пресъздадем средата и да започнем от нулата с надеждата, че когато добавим зависимостите на Python, това ще реши проблема ни.
Коригиране на проблем със „Стартиране на подчинените възли“ (част 2) – 13 минути 15 секунди
За съжаление, настройката на предпоставките за Python изобщо не помогна. Решихме да завършим процеса ръчно, като стартираме първия възел и след това конфигурираме SST потребител и стартираме останалите подчинени устройства. Това завърши „автоматизираната“ настройка и ни отне 13 минути и 15 секунди, за да отстраним грешките и след това най-накрая да приемем, че няма да работи, както е очаквал дизайнерът на книгата.
Допълнително отстраняване на грешки - 10 минути 45 секунди
Не спряхме дотук и решихме, че ще опитаме още нещо. Вместо да разчитаме на Ansible променливи, ние просто поставяме IP на един от възлите като главен възел. Това реши тази част от проблема и в крайна сметка получихме:
TASK [ansible-role-XtraDB-Cluster : Create SST user] ******************************************************************************************************************************************************************************************************************************
skipping: [node2]
skipping: [node3]
fatal: [node1]: FAILED! => {"changed": false, "msg": "unable to connect to database, check login_user and login_password are correct or /root/.my.cnf has the credentials. Exception message: (1045, u\"Access denied for user 'root'@'::1' (using password: YES)\")"}Това беше краят на нашите опити – опитахме се да добавим този потребител, но той не работи правилно през ansible playbook, докато можехме да използваме IPv6 локален адрес за свързване, когато използваме MySQL клиент.
Общо време за инсталиране – неизвестно (Автоматична инсталация неуспешна)
Общо прекарахме 64 минути и все още не сме успели да вървим нещата автоматично. Останалите проблеми са създаването на root парола, която изглежда не работи и след това стартирането на Galera Cluster (проблем с потребителя на SST). Трудно е да се каже колко време ще отнеме по-нататъшното му отстраняване на грешки. Сигурно е възможно - просто е трудно да се определи количествено, защото наистина зависи от опита с Ansible и MySQL. Това определено не е нещо, което всеки може просто да изтегли, конфигурира и стартира. Е, може би друга книга-игра би работила по различен начин? Възможно е, но може да доведе и до различни проблеми. Добре, значи има крива на обучение за изкачване и отстраняване на грешки, но след това, когато сте готови, просто ще стартирате скрипт. Е, това е някак вярно. Докато промените, въведени от поддържащия, няма да нарушат нещо, от което зависите, или новата версия на Ansible ще наруши книгата или поддържащият просто ще забрави за проекта и ще спре да го разработва (за ролята, която използвахме, има доста полезна заявка за изтегляне, чакаща вече почти година, което може да успее да реши проблема със зависимостта на Python - не е обединен). Освен ако не приемете, че ще трябва да поддържате този код, не можете наистина да разчитате, че той е 100% точен и работи във вашата среда, особено като се има предвид, че първоначалният разработчик няма стимули да поддържа кода актуален. Освен това, какво ще кажете за другите версии? Не можете да използвате тази конкретна игра, за да инсталирате PXC 5.6 или която и да е версия на MariaDB. Разбира се, има и други учебници, които можете да намерите. Ще работят ли по-добре или може би ще прекарате още куп часове, опитвайки се да ги накарате да работят?
ClusterControlЕдинична конзола за цялата ви инфраструктура на базата данни Открийте какво още е новото в ClusterControlИнсталирайте ClusterControl БЕЗПЛАТНОClusterControl
И накрая, нека да разгледаме как ClusterControl може да се използва за разгръщане на Percona XtraDB Cluster.
Конфигуриране на SSH свързаност - 1 минута
ClusterControl изисква SSH свързаност между всички възли, за да ги свърже и конфигурира. Генерирахме SSH ключ и го разпределихме ръчно между възлите.
Настройка на ClusterControl - 3 минути 15 секунди
Бързо търсене „Инсталиране на ClusterControl“ ни насочи към съответната страница с документация на ClusterControl. Търсихме „по-прост начин за инсталиране на ClusterControl“, затова последвахме връзката и намерихме следните инструкции.
Изтеглянето на скрипта и изпълнението му отне 3 минути и 15 секунди, трябваше да предприемем някои действия, докато инсталацията продължи, така че да не е инсталация без надзор.
Влизане в потребителския интерфейс и начало на внедряването - 1 минута 10 секунди
Насочихме браузъра си към IP на възела ClusterControl.
Предадохме необходимата информация за контакт и ни беше представен екранът за добре дошли:
Следваща стъпка - избрахме опцията за внедряване.
Трябваше да предадем подробности за SSH свързаността.
Решихме също доставчика, версията, паролата и хостовете, които да използваме. Целият този процес отне 1 минута и 10 секунди.
Разгръщане на клъстер на Percona XtraDB – 12 минути 5 секунди
Единственото, което оставаше, беше да изчакаме ClusterControl да завърши внедряването. След 12 минути и 5 секунди клъстерът беше готов:
Общо време за инсталиране - 17 минути 30 секунди
Свързани ресурси ClusterControl за MySQL ClusterControl за MariaDB ClusterControl за Galera ClusterУспяхме да разгърнем ClusterControl и след това PXC клъстер, използвайки ClusterControl за 17 минути и 30 секунди. Самото внедряване на PXC отне 12 минути и 5 секунди . В крайна сметка имаме работещ клъстер, разгърнат според най-добрите практики. ClusterControl също така гарантира, че конфигурацията на клъстера има смисъл. Накратко, дори и да не знаете нищо за MySQL или Galera Cluster, можете да разполагате с готов за производство клъстер за няколко минути. ClusterControl не е просто инструмент за внедряване, той е и платформа за управление - прави нещата още по-лесни за хората, които не са имали опит с MySQL и Galera, да идентифицират проблеми с производителността (чрез съветници) и да извършват действия за управление (мащабиране на клъстера нагоре и надолу, стартиране на архивиране, създаване асинхронни роби на Галера). Важното е, че ClusterControl винаги ще се поддържа и може да се използва за разгръщане на всички варианти на MySQL (и не само MySQL/MariaDB, той също така поддържа TimeScaleDB, PostgreSQL и MongoDB). Също така работи извън кутията, нещо, което не може да се каже за други методи, които тествахме.
Ако искате да изпитате същото, можете да изтеглите ClusterControl безплатно. Кажете ни как ви хареса.
