MariaDB MaxScale Load Balancing na Docker:Management:Část druhá

Tento blogový příspěvek je pokračováním MariaDB MaxScale Load Balancing  na Docker:Deployment – ​​Part1. V této části se zaměříme více na operace správy s pokročilými případy použití, jako je řízení služeb, správa konfigurace, zpracování dotazů, zabezpečení a odsouhlasení clusteru. Vzorové kroky a pokyny uvedené v tomto příspěvku jsou založeny na běžících prostředích, která jsme nastavili v první části této blogové série.

Řízení služeb

Pro MaxScale je spuštění a zastavení kontejneru jediným způsobem, jak ovládat službu. Pokud byl kontejner vytvořen, můžeme ke správě služby použít následující příkaz:

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

Spuštění bez oprávnění root

Kontejnery Dockeru ve výchozím nastavení běží s oprávněním root a stejně tak i aplikace, která běží uvnitř kontejneru. To je další velký problém z hlediska zabezpečení, protože hackeři mohou získat root přístup k hostiteli Dockeru hacknutím aplikace běžící uvnitř kontejneru.

Chcete-li Docker spustit jako uživatel bez oprávnění root, musíte svého uživatele přidat do skupiny dockerů. Nejprve vytvořte skupinu dokovacích stanic, pokud žádná neexistuje:

$ sudo groupadd docker

Poté přidejte svého uživatele do skupiny dockerů. V tomto příkladu je náš uživatel "tulák":

$ sudo usermod -aG docker vagrant

Odhlaste se a přihlaste se znovu, aby se vaše členství ve skupině znovu vyhodnotilo (nebo restartujte, pokud to nefunguje). V tomto okamžiku můžete spustit kontejner MaxScale pomocí standardního příkazu run (není vyžadováno sudo) jako uživatel "vagrant":

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

Proces MaxScale běží uživatelem "maxscale" a nevyžaduje žádná zvláštní oprávnění až do úrovně root. Spuštění kontejneru v neprivilegovaném režimu je tedy vždy nejlepším způsobem, pokud máte obavy o zabezpečení.

Správa konfigurace

U samostatného kontejneru MaxScale vyžaduje správa konfigurace úpravu namapovaného konfiguračního souboru a následné restartování kontejneru MaxScale. Pokud však používáte službu Docker Swarm, nová konfigurace se musí načíst do Swarm Configs jako nová verze, například:

$ cat maxscale.cnf | docker config create maxscale_config_v2 -

Poté aktualizujte službu odstraněním starých konfigurací (maxscale_config) a přidáním nové (maxscale_config_v2) do stejného cíle:

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

Docker Swarm pak naplánuje odstranění kontejneru a výměnu procedur jeden kontejner po druhém, dokud nebude splněn požadavek na repliky.

Upgrade a downgrade

Jednou z výhod spouštění aplikací v Dockeru je triviální postup upgradu a downgradu. Každý spuštěný kontejner je založen na obrázku a tento obrázek lze snadno přepínat pomocí značky obrázku. Chcete-li získat seznam dostupných obrázků pro MaxScale, podívejte se do sekce Tagy v Docker Hub. Následující příklady ukazují proces downgradu MaxScale 2.3 na nižší nižší verzi, 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

Ujistěte se, že možnosti konfigurace jsou kompatibilní s verzí, kterou chcete spustit. Například výše uvedený downgrade by selhal při prvním spuštění kvůli následujícím chybám:

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'.

Co musíme udělat, je odstranit nepodporované možnosti konfigurace, jak je uvedeno výše v konfiguračním souboru, před downgradem obrázku kontejneru:

• master_reconnection
• delayed_retry
• přehrání_transakce
• causal_reads_timeout
• causal_reads

Nakonec nádobu znovu spusťte a měli byste být dobří. Upgrade verze pro MaxScale funguje podobně. Stačí změnit štítek, který chcete použít, a můžete začít.

Filtry MaxScale

MaxScale používá komponentu zvanou filtr k manipulaci nebo zpracování požadavků, které procházejí. Existuje spousta filtrů, které můžete použít, jak je uvedeno na této stránce, MaxScale 2.3 Filters. Konkrétní dotaz lze například přihlásit do souboru, pokud odpovídá kritériím, nebo můžete příchozí dotaz přepsat dříve, než se dostane na servery typu back-end.

Chcete-li aktivovat filtr, musíte definovat sekci a zahrnout název definice do odpovídající definice služby, jak je znázorněno v příkladech níže.

Query Logging All (QLA)

Jak jeho název vysvětluje, filtr QLA zaznamenává všechny dotazy, které odpovídají sadě pravidel na relaci klienta. Všechny dotazy budou protokolovány ve formátu filebase.

Nejprve definujte komponentu pomocí type=filter a 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

Poté přidejte komponentu filtru do našich služeb:

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

Je také dobré namapovat /tmp kontejneru se skutečným adresářem na hostiteli Docker, abychom nemuseli přistupovat ke kontejneru, abychom mohli načíst vygenerované soubory protokolu. Nejprve vytvořte adresář a udělte globální oprávnění pro zápis:

$ mkdir qla
$ chmod 777 qla

Protože potřebujeme svázat výše uvedený adresář do kontejneru, musíme zastavit a odstranit běžící kontejner a znovu jej spustit pomocí následujícího příkazu:

$ 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

Poté můžete načíst obsah protokolovaných dotazů v adresáři qla:

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

Přepisování dotazu

Query rewrite je funkce, která v závislosti na dotazech běžících na databázovém serveru umožňuje rychle izolovat a opravit problematické dotazy a zlepšit výkon.

Přepis dotazu lze provést pomocí regexfiltru. Tento filtr dokáže porovnat nebo vyloučit příchozí příkazy pomocí regulárních výrazů a nahradit je jiným příkazem. Každé pravidlo je definováno ve své vlastní sekci a zahrnutím názvu sekce do příslušné služby je aktivujete.

Následující filtr bude odpovídat řadě příkazů SHOW, které nechceme zpřístupňovat klientům pouze pro čtení:

## 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'

Poté můžeme přidat filtr ke službě, kterou chceme použít. Například všechna připojení pouze pro čtení musí být filtrována pro výše uvedené:

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

Mějte na paměti, že pomocí syntaxe podobné linuxovému shellu "|" lze definovat více filtrů syntax. Chcete-li použít změny konfigurace, restartujte kontejner:

$ docker restart maxscale

Poté můžeme ověřit pomocí následujícího dotazu:

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

Dostanete výsledek podle očekávání.

Obnova clusteru

MaxScale 2.2.2 a novější podporuje automatickou nebo manuální replikaci MariaDB nebo obnovu clusteru pro následující události:

• přepnutí při selhání
• přepnutí
• znovu se připojit
• reset-replication

Přepnutí při selhání pro cluster master-slave může a často by mělo být nastaveno tak, aby se aktivovalo automaticky. Přepnutí musí být aktivováno ručně pomocí MaxAdmin, MaxCtrl nebo rozhraní REST. Opětovné připojení lze nastavit na automatické nebo aktivovat ručně. Tyto funkce jsou implementovány v modulu "mariadbmon".

Pokud úmyslně vypneme aktivní hlavní server, 192.168.0.91, došlo k následujícím událostem automatického převzetí služeb při selhání:

$ 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]

Po dokončení převzetí služeb při selhání nyní naše topologie vypadá takto:

Operace přepínání vyžaduje lidský zásah a jeden způsob, jak to provést prostřednictvím konzoly MaxCtrl. Řekněme, že starý master je opět funkční a je připraven být povýšen jako master, můžeme provést operaci přepnutí odesláním následujícího příkazu:

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

Kde, formátování je:

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

Poté ověřte novou topologii uvedením serverů:

 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 │
└──────────┴──────────────┴──────┴─────────────┴─────────────────┴──────────────┘

Právě jsme povýšili našeho starého mistra zpět na jeho původní místo. Zajímavostí je, že funkce automatického obnovení ClusterControl dělá přesně to samé, pokud je povolena.

Poslední myšlenky

Spuštění MariaDB MaxScale na Dockeru přináší další výhody, jako je clustering MaxScale, snadný upgrade a downgrade a také pokročilé funkce proxy pro clustery MySQL a MariaDB.