MariaDB MaxScale Load Balancing på Docker:Hantering:Del två

Det här blogginlägget är en fortsättning på MariaDB MaxScale Load Balancing  on Docker:Deployment - Part1. I den här delen kommer vi att fokusera mer på hanteringsoperationer med avancerade användningsfall som tjänstekontroll, konfigurationshantering, frågebehandling, säkerhet och klusteravstämning. Exempelstegen och instruktionerna som visas i det här inlägget är baserade på de körmiljöer som vi har ställt in i den första delen av den här bloggserien.

Tjänstekontroll

För MaxScale är att starta och stoppa containern det enda sättet att kontrollera tjänsten. Förutsatt att behållaren har skapats kan vi använda följande kommando för att hantera tjänsten:

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

Kör utan root-privilegier

Docker-behållarna körs som standard med root-privilegiet och det gör även applikationen som körs inuti behållaren. Detta är ett annat stort problem ur säkerhetsperspektiv eftersom hackare kan få root-åtkomst till Docker-värden genom att hacka programmet som körs inuti behållaren.

För att köra Docker som en icke-rootanvändare måste du lägga till din användare i dockergruppen. Skapa först en dockargrupp om det inte finns någon:

$ sudo groupadd docker

Lägg sedan till din användare i dockargruppen. I det här exemplet är vår användare "vagrant":

$ sudo usermod -aG docker vagrant

Logga ut och logga in igen så att ditt gruppmedlemskap omvärderas (eller starta om om det inte fungerar). Vid det här laget kan du köra MaxScale-behållaren med standardkommandot kör (inget sudo krävs) som användaren "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

MaxScale-processen körs av användaren "maxscale" och kräver inga speciella privilegier upp till rotnivån. Att köra behållaren i icke-privilegierat läge är därför alltid det bästa sättet om du är orolig för säkerheten.

Konfigurationshantering

För fristående MaxScale-behållare kräver konfigurationshantering modifiering av den mappade konfigurationsfilen följt av omstart av MaxScale-behållaren. Men om du kör som en Docker Swarm-tjänst måste den nya konfigurationen laddas in i Swarm Configs som en ny version, till exempel:

$ cat maxscale.cnf | docker config create maxscale_config_v2 -

Uppdatera sedan tjänsten genom att ta bort de gamla konfigurationerna (maxscale_config) och lägg till den nya (maxscale_config_v2) till samma mål:

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

Docker Swarm kommer sedan att schemalägga borttagning av behållare och ersätta procedurer en behållare i taget tills replikkraven är uppfyllda.

Uppgradera och nedgradera

En av fördelarna med att köra dina applikationer i Docker är en trivial uppgradering och nedgradering. Varje pågående behållare är baserad på en bild, och denna bild kan enkelt bytas med bildtaggen. För att få listan över tillgängliga bilder för MaxScale, kolla in avsnittet Taggar i Docker Hub. Följande exempel visar processen för att nedgradera en MaxScale 2.3 till en mindre version tidigare, 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

Se till att konfigurationsalternativen är kompatibla med den version du vill köra. Till exempel skulle nedgraderingen ovan misslyckas vid första körningen på grund av följande fel:

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

Vad vi behöver göra är att ta bort de konfigurationsalternativ som inte stöds som visas ovan i konfigurationsfilen innan vi nedgraderar behållarbilden:

• master_reconnection
• fördröjt_försök igen
• transaction_replay
• causal_reads_timeout
• causal_reads

Starta slutligen behållaren igen och du borde vara bra. Versionsuppgradering för MaxScale fungerar på liknande sätt. Byt bara taggen som du vill använda och kör iväg.

MaxScale-filter

MaxScale använder en komponent som kallas filter för att manipulera eller bearbeta förfrågningarna när de passerar genom den. Det finns ett gäng filter du kan använda, enligt listan på den här sidan, MaxScale 2.3-filter. Till exempel kan en specifik fråga loggas in i en fil om den matchar ett kriterium eller så kan du skriva om den inkommande frågan innan den når backend-servrarna.

För att aktivera ett filter måste du definiera ett avsnitt och inkludera definitionsnamnet i motsvarande tjänstdefinition, som visas i exemplen längre ner.

Query Logging All (QLA)

Som namnet förklarar loggar QLA-filtret alla frågor som matchar regeluppsättningen per klientsession. Alla frågor kommer att loggas enligt filbasformatet.

Först definierar du komponenten med type=filter och 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

Lägg sedan till filterkomponenten i våra tjänster:

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

Det är också en bra idé att mappa /tmp av behållaren med den faktiska katalogen på Docker-värden, så att vi inte behöver komma åt behållaren för att hämta de genererade loggfilerna. Skapa först en katalog och ge global skrivbar behörighet:

$ mkdir qla
$ chmod 777 qla

Eftersom vi måste binda katalogen ovan till behållaren, måste vi stoppa och ta bort den pågående behållaren och köra den igen med följande kommando:

$ 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

Du kan sedan hämta innehållet i de loggade frågorna i qla-katalogen:

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

Frågeomskrivning

Omskrivning av frågor är en funktion som, beroende på de frågor som körs mot databasservern, snabbt gör det möjligt att isolera och korrigera problematiska frågor och förbättra prestandan.

Omskrivning av frågor kan göras via regexfilter. Det här filtret kan matcha eller utesluta inkommande satser med hjälp av reguljära uttryck och ersätta dem med ett annat sats. Varje regel definieras i sin egen sektion och inkluderar sektionsnamnet i motsvarande tjänst för att aktivera den.

Följande filter kommer att matcha ett antal SHOW-kommandon som vi inte vill exponera för skrivskyddade klienter:

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

Sedan kan vi lägga till filtret till den tjänst som vi vill tillämpa. Till exempel måste alla skrivskyddade anslutningar filtreras för ovanstående:

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

Tänk på att flera filter kan definieras med en syntax som liknar Linux-skalet "|" syntax. Starta om behållaren för att tillämpa konfigurationsändringarna:

$ docker restart maxscale

Vi kan sedan verifiera med följande fråga:

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

Du kommer att få resultatet som förväntat.

Klusteråterställning

MaxScale 2.2.2 och senare stöder automatisk eller manuell MariaDB-replikering eller klusteråterställning för följande händelser:

• failover
• växling
• gå med igen
• återställ-replikering

Failover för master-slav-klustret kan och bör ofta ställas in för att aktiveras automatiskt. Övergången måste aktiveras manuellt via MaxAdmin, MaxCtrl eller REST-gränssnittet. Återanslutning kan ställas in på automatisk eller aktiveras manuellt. Dessa funktioner är implementerade i modulen "mariadbmon".

Följande automatiska failover-händelser inträffade om vi avsiktligt stängde av den aktiva mastern, 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]

Efter att failover är klar ser vår topologi nu ut så här:

För övergångsoperation kräver det mänskligt ingripande och ett sätt att göra det via MaxCtrl-konsolen. Låt oss säga att den gamla mastern är tillbaka i drift och är redo att befordras som master, vi kan utföra övergångsoperationen genom att skicka följande kommando:

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

Där är formateringen:

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

Verifiera sedan den nya topologin genom att lista ut servrarna:

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

Vi har just befordrat vår gamla mästare tillbaka till sin ursprungliga plats. Kul faktum, ClusterControls automatiska återställningsfunktion gör exakt samma sak om den är aktiverad.

Sluta tankar

Att köra MariaDB MaxScale på Docker ger ytterligare fördelar som MaxScale-kluster, lätt att uppgradera och nedgradera, och även avancerade proxyfunktioner för MySQL- och MariaDB-kluster.