Балансиране на натоварването на MariaDB MaxScale на Docker:Управление:Част втора

Тази публикация в блога е продължение на MariaDB MaxScale Load Balancing  на Docker:Разгръщане - Част 1. В тази част ще се съсредоточим повече върху операциите по управление с разширени случаи на използване като контрол на услугите, управление на конфигурацията, обработка на заявки, сигурност и съгласуване на клъстери. Примерните стъпки и инструкции, показани в тази публикация, са базирани на работните среди, които сме настроили в първата част от тази поредица от блогове.

Управление на услугите

За MaxScale стартирането и спирането на контейнера е единственият начин да контролирате услугата. При условие, че контейнерът е създаден, можем да използваме следната команда за управление на услугата:

$ docker start maxscale
$ docker stop maxscale
$ docker restart maxscale

Изпълнява се без Root права

Контейнерите на Docker по подразбиране се изпълняват с root привилегия, както и приложението, което се изпълнява вътре в контейнера. Това е друг основен проблем от гледна точка на сигурността, тъй като хакерите могат да получат root достъп до хоста на Docker, като хакнат приложението, което се изпълнява вътре в контейнера.

За да стартирате Docker като не-root потребител, трябва да добавите своя потребител към групата на docker. Първо, създайте докер група, ако няма такава:

$ sudo groupadd docker

След това добавете своя потребител към групата на docker. В този пример нашият потребител е "скитник":

$ sudo usermod -aG docker vagrant

Излезте и влезте отново, за да бъде преоценено членството ви в групата (или рестартирайте, ако не работи). В този момент можете да стартирате контейнера MaxScale със стандартната команда за изпълнение (не се изисква sudo) като потребител "скитник":

$ docker run -d \
--name maxscale-unprivileged \
-p 4006:4006 \
-p 4008:4008 \
-p 8989:8989 \
-v $PWD/maxscale.cnf:/etc/maxscale.cnf \
mariadb/maxscale

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

Управление на конфигурацията

За самостоятелен контейнер MaxScale, управлението на конфигурацията изисква модификация на картографирания конфигурационен файл, последвано от рестартиране на контейнера MaxScale. Въпреки това, ако работите като услуга на Docker Swarm, новата конфигурация трябва да бъде заредена в Swarm Configs като нова версия, например:

$ cat maxscale.cnf | docker config create maxscale_config_v2 -

След това актуализирайте услугата, като премахнете старите конфигурации (maxscale_config) и добавете новата (maxscale_config_v2) към същата цел:

$ docker service update \
--config-rm maxscale_config \
--config-add source=maxscale_config_v2,target=/etc/maxscale.cnf \
maxscale-cluster

След това Docker Swarm ще насрочи премахването на контейнера и ще замени процедурите един контейнер в даден момент, докато изискването за реплики бъде удовлетворено.

Надстройване и понижаване

Едно от предимствата на стартирането на вашите приложения в Docker е тривиалната процедура за надграждане и понижаване. Всеки работещ контейнер е базиран на изображение и това изображение може лесно да се превключва с етикета за изображение. За да получите списъка с наличните изображения за MaxScale, вижте секцията Етикети в Docker Hub. Следните примери показват процеса за понижаване на MaxScale 2.3 до една второстепенна версия по-рано, 2.2:

$ docker run -d \
--name maxscale \
-p 4006:4006 \
-p 4008:4008 \
-v $PWD/maxscale.cnf:/etc/maxscale.cnf \
mariadb/maxscale:2.3
$ docker rm -f maxscale
$ docker run -d \
--name maxscale \
-p 4006:4006 \
-p 4008:4008 \
-v $PWD/maxscale.cnf:/etc/maxscale.cnf \
mariadb/maxscale:2.2

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

2019-06-19 05:29:04.301   error  : (check_config_objects): Unexpected parameter 'master_reconnection' for object 'rw-service' of type 'service', or 'true' is an invalid value for parameter 'master_reconnection'.
2019-06-19 05:29:04.301   error  : (check_config_objects): Unexpected parameter 'delayed_retry' for object 'rw-service' of type 'service', or 'true' is an invalid value for parameter 'delayed_retry'.
2019-06-19 05:29:04.301   error  : (check_config_objects): Unexpected parameter 'transaction_replay_max_size' for object 'rw-service' of type 'service', or '1Mi' is an invalid value for parameter 'transaction_replay_max_size'.
2019-06-19 05:29:04.302   error  : (check_config_objects): Unexpected parameter 'transaction_replay' for object 'rw-service' of type 'service', or 'true' is an invalid value for parameter 'transaction_replay'.
2019-06-19 05:29:04.302   error  : (check_config_objects): Unexpected parameter 'causal_reads_timeout' for object 'rw-service' of type 'service', or '10' is an invalid value for parameter 'causal_reads_timeout'.
2019-06-19 05:29:04.302   error  : (check_config_objects): Unexpected parameter 'causal_reads' for object 'rw-service' of type 'service', or 'true' is an invalid value for parameter 'causal_reads'.

Това, което трябва да направим, е да премахнем неподдържаните опции за конфигурация, както е показано по-горе в конфигурационния файл, преди да понижим изображението на контейнера:

• master_reconnection
• отложен_повторен опит
• transaction_replay
• causal_reads_timeout
• causal_reads

Накрая стартирайте контейнера отново и трябва да сте добре. Надстройката на версията за MaxScale работи по подобен начин. Просто сменете маркера, който искате да използвате, и тръгвайте.

Филтри за MaxScale

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

За да активирате филтър, трябва да дефинирате раздел и да включите името на дефиницията в съответната дефиниция на услугата, както е показано в примерите по-долу.

Записване на всички заявки (QLA)

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

Първо, дефинирайте компонента с type=filter и module=qlafilter:

## Query Log All (QLA) filter
## Filter module for MaxScale to log all query content on a per client session basis
[qla-sbtest-no-pk]
type		= filter
module		= qlafilter
filebase	= /tmp/sbtest
match		= select.*from.*
exclude		= where.*id.*
user		= sbtest

След това добавете филтърния компонент в нашите услуги:

[rw-service]
...
filters        = qla-sbtest-no-pk
[rr-service]
...
filters        = qla-sbtest-no-pk

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

$ mkdir qla
$ chmod 777 qla

Тъй като трябва да свържем горната директория към контейнера, трябва да спрем и премахнем работещия контейнер и да го стартираме отново със следната команда:

$ docker stop maxscale
$ docker run -d \
--name maxscale \
--restart always \
-p 4006:4006 \
-p 4008:4008 \
-p 8989:8989 \
-v $PWD/maxscale.cnf:/etc/maxscale.cnf \
-v $PWD/qla:/tmp \
mariadb/maxscale

След това можете да извлечете съдържанието на регистрираните заявки в директорията qla:

$ cat qla/*
Date,[email protected],Query
2019-06-18 08:25:13,[email protected]::ffff:192.168.0.19,select * from sbtest.sbtest1

Пренаписване на заявка

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

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

Следният филтър ще съответства на редица SHOW команди, които не искаме да излагаме на клиентите само за четене:

## Rewrite query based on regex match and replace
[block-show-commands]
type            = filter
module          = regexfilter
options         = ignorecase
match           = ^show (variables|global variables|global status|status|processlist|full processlist).*
replace         = SELECT 'Not allowed'

След това можем да добавим филтъра към услугата, която искаме да приложим. Например, всички връзки само за четене трябва да бъдат филтрирани за горното:

[rr-service]
...
filters        = qla-sbtest-no-pk | block-show-commands

Имайте предвид, че множество филтри могат да бъдат дефинирани с помощта на синтаксис, подобен на Linux shell pipe "|" синтаксис. Рестартирайте контейнера, за да приложите промените в конфигурацията:

$ docker restart maxscale

След това можем да проверим със следната заявка:

$ mysql -usbtest -p -h192.168.0.200 -P4006 -e 'SHOW VARIABLES LIKE "max_connections"'
+-------------+
| Not allowed |
+-------------+
| Not allowed |
+-------------+

Ще получите резултата според очакванията.

Възстановяване на клъстер

MaxScale 2.2.2 и по-нови поддържат автоматично или ръчно MariaDB репликация или възстановяване на клъстер за следните събития:

• отказ
• превключване
• присъединете се отново
• нулиране-репликация

Отказът за клъстера главен-подчинен може и често трябва да бъде настроен да се активира автоматично. Превключването трябва да се активира ръчно чрез MaxAdmin, MaxCtrl или REST интерфейса. Повторното присъединяване може да бъде настроено на автоматично или да се активира ръчно. Тези функции са внедрени в модула "mariadbmon".

Следните събития за автоматично преодоляване на срив се случиха, ако нарочно изключим активния главен файл, 192.168.0.91:

$ docker logs -f maxscale
...
2019-06-19 03:53:02.348   error  : (mon_log_connect_error): Monitor was unable to connect to server mariadb1[192.168.0.91:3306] : 'Can't connect to MySQL server on '192.168.0.91' (115)'
2019-06-19 03:53:02.351   notice : (mon_log_state_change): Server changed state: mariadb1[192.168.0.91:3306]: master_down. [Master, Running] -> [Down]
2019-06-19 03:53:02.351   warning: (handle_auto_failover): Master has failed. If master status does not change in 4 monitor passes, failover begins.
2019-06-19 03:53:16.710   notice : (select_promotion_target): Selecting a server to promote and replace 'mariadb1'. Candidates are: 'mariadb2', 'mariadb3'.
2019-06-19 03:53:16.710   warning: (warn_replication_settings): Slave 'mariadb2' has gtid_strict_mode disabled. Enabling this setting is recommended. For more information, see https://mariadb.com/kb/en/library/gtid/#gtid_strict_mode
2019-06-19 03:53:16.711   warning: (warn_replication_settings): Slave 'mariadb3' has gtid_strict_mode disabled. Enabling this setting is recommended. For more information, see https://mariadb.com/kb/en/library/gtid/#gtid_strict_mode
2019-06-19 03:53:16.711   notice : (select_promotion_target): Selected 'mariadb2'.
2019-06-19 03:53:16.711   notice : (handle_auto_failover): Performing automatic failover to replace failed master 'mariadb1'.
2019-06-19 03:53:16.723   notice : (redirect_slaves_ex): Redirecting 'mariadb3' to replicate from 'mariadb2' instead of 'mariadb1'.
2019-06-19 03:53:16.742   notice : (redirect_slaves_ex): All redirects successful.
2019-06-19 03:53:17.249   notice : (wait_cluster_stabilization): All redirected slaves successfully started replication from 'mariadb2'.
2019-06-19 03:53:17.249   notice : (handle_auto_failover): Failover 'mariadb1' -> 'mariadb2' performed.
2019-06-19 03:53:20.363   notice : (mon_log_state_change): Server changed state: mariadb2[192.168.0.92:3306]: new_master. [Slave, Running] -> [Master, Running]

След приключване на отказоустойчивостта нашата топология вече изглежда така:

За операцията по превключване е необходима човешка намеса и един начин за това чрез конзолата MaxCtrl. Да приемем, че старият главен е отново в действие и е готов да бъде повишен като главен, можем да извършим операцията по превключване, като изпратим следната команда:

$ docker exec -it maxscale maxctrl
maxctrl: call command mariadbmon switchover monitor mariadb1 mariadb2
OK

Където, форматирането е:

$ call command <monitoring module> <operation> <monitoring section name> <new master> <current master>

След това проверете новата топология, като изброите сървърите:

 maxctrl: list servers
┌──────────┬──────────────┬──────┬─────────────┬─────────────────┬──────────────┐
│ Server   │ Address      │ Port │ Connections │ State           │ GTID         │
├──────────┼──────────────┼──────┼─────────────┼─────────────────┼──────────────┤
│ mariadb1 │ 192.168.0.91 │ 3306 │ 0           │ Master, Running │ 0-5001-12144 │
├──────────┼──────────────┼──────┼─────────────┼─────────────────┼──────────────┤
│ mariadb2 │ 192.168.0.92 │ 3306 │ 0           │ Slave, Running  │ 0-5001-12144 │
├──────────┼──────────────┼──────┼─────────────┼─────────────────┼──────────────┤
│ mariadb3 │ 192.168.0.93 │ 3306 │ 0           │ Slave, Running  │ 0-5001-12144 │
└──────────┴──────────────┴──────┴─────────────┴─────────────────┴──────────────┘

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

Последни мисли

Изпълнението на MariaDB MaxScale на Docker носи допълнителни предимства като MaxScale клъстериране, лесен за надграждане и понижаване, както и разширени функции за прокси за MySQL и MariaDB клъстери.