sql >> Database teknologi >  >> RDS >> MariaDB

MariaDB MaxScale Load Balancing på Docker:Management:Anden del

Dette blogindlæg er en fortsættelse af MariaDB MaxScale Load Balancing  på Docker:Deployment - Part1. I denne del vil vi fokusere mere på administrationsoperationer med avancerede use cases som servicekontrol, konfigurationsstyring, forespørgselsbehandling, sikkerhed og klyngeafstemning. Eksempeltrinene og instruktionerne vist i dette indlæg er baseret på de løbemiljøer, som vi har sat op i den første del af denne blogserie.

Servicekontrol

For MaxScale er start og stop af containeren den eneste måde at kontrollere tjenesten på. Forudsat at containeren er blevet oprettet, kan vi bruge følgende kommando til at administrere tjenesten:

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

Kører uden root-privilegier

Docker-beholderne kører som standard med root-privilegiet, og det samme gør applikationen, der kører inde i beholderen. Dette er en anden stor bekymring fra et sikkerhedsperspektiv, fordi hackere kan få root-adgang til Docker-værten ved at hacke applikationen, der kører inde i containeren.

For at køre Docker som en ikke-root-bruger, skal du tilføje din bruger til docker-gruppen. For det første skal du oprette en docker-gruppe, hvis der ikke er en:

$ sudo groupadd docker

Tilføj derefter din bruger til docker-gruppen. I dette eksempel er vores bruger "vagrant":

$ sudo usermod -aG docker vagrant

Log ud og log ind igen, så dit gruppemedlemskab bliver revurderet (eller genstart, hvis det ikke virker). På dette tidspunkt kan du køre MaxScale-beholderen med standard run-kommandoen (ingen sudo påkrævet) som bruger "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ører af brugeren "maxscale" og kræver ingen særlige privilegier op til rodniveauet. Kørsel af containeren i ikke-privilegeret tilstand er derfor altid den bedste måde, hvis du er bekymret for sikkerheden.

Konfigurationsstyring

For selvstændige MaxScale-beholdere kræver konfigurationsstyring ændring af den tilknyttede konfigurationsfil efterfulgt af genstart af MaxScale-beholderen. Men hvis du kører som en Docker Swarm-tjeneste, skal den nye konfiguration indlæses i Swarm Configs som en ny version, for eksempel:

$ cat maxscale.cnf | docker config create maxscale_config_v2 -

Opdater derefter tjenesten ved at fjerne de gamle konfigurationer (maxscale_config) og tilføj den nye (maxscale_config_v2) til det samme mål:

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

Docker Swarm planlægger derefter containerfjernelse og udskifter procedurer én container ad gangen, indtil replikakravet er opfyldt.

Opgrader og nedgrader

En af fordelene ved at køre dine applikationer i Docker er triviel opgraderings- og nedgraderingsprocedure. Hver kørende container er baseret på et billede, og dette billede kan nemt skiftes med billedmærket. For at få listen over tilgængelige billeder til MaxScale, tjek sektionen Tags i Docker Hub. Følgende eksempler viser processen til at nedgradere en MaxScale 2.3 til en mindre version tidligere, 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

Sørg for, at konfigurationsmulighederne er kompatible med den version, du vil køre. For eksempel ville ovenstående nedgradering mislykkes ved første kørsel på grund af følgende fejl:

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

Det, vi skal gøre, er at fjerne de ikke-understøttede konfigurationsmuligheder som vist ovenfor i konfigurationsfilen, før vi nedgraderer containerbilledet:

  • master_reconnection
  • forsinket_forsøg igen
  • transaction_replay
  • causal_reads_timeout
  • causal_reads

Start endelig beholderen igen, og du skal være god. Versionsopgradering til MaxScale fungerer på samme måde. Skift bare det tag, du vil bruge, og så er du afsted.

MaxScale-filtre

MaxScale bruger en komponent kaldet filter til at manipulere eller behandle anmodningerne, når de passerer gennem den. Der er en masse filtre, du kan bruge, som angivet på denne side, MaxScale 2.3-filtre. For eksempel kan en specifik forespørgsel logges ind i en fil, hvis den matcher et kriterium, eller du kan omskrive den indgående forespørgsel, før den når backend-serverne.

For at aktivere et filter skal du definere en sektion og inkludere definitionsnavnet i den tilsvarende tjenestedefinition, som vist i eksemplerne længere nede.

Forespørgselslogning af alle (QLA)

Som navnet forklarer, logfører QLA-filteret alle forespørgsler, der matcher regelsættet pr. klientsession. Alle forespørgsler vil blive logget efter filbaseformatet.

Først skal du definere komponenten med type=filter og modul=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

Tilføj derefter filterkomponenten til vores tjenester:

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

Det er også en god idé at kortlægge /tmp af containeren med den faktiske mappe på Docker-værten, så vi ikke behøver at få adgang til containeren for at hente de genererede logfiler. Først skal du oprette en mappe og give global skrivbar tilladelse:

$ mkdir qla
$ chmod 777 qla

Da vi skal binde ovenstående mappe til containeren, er vi nødt til at stoppe og fjerne den kørende container og køre den igen med følgende 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 derefter hente indholdet af de loggede forespørgsler inde i qla-mappen:

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

Omskrivning af forespørgsler

Forespørgselsomskrivning er en funktion, der, afhængigt af de forespørgsler, der kører mod databaseserveren, hurtigt gør det muligt at isolere og rette problematiske forespørgsler og forbedre ydeevnen.

Omskrivning af forespørgsler kan udføres via regexfilter. Dette filter kan matche eller udelukke indgående udsagn ved hjælp af regulære udtryk og erstatte dem med et andet udsagn. Hver regel er defineret i sin egen sektion og inkluderer sektionsnavnet i den tilsvarende tjeneste for at aktivere den.

Følgende filter vil matche et antal SHOW-kommandoer, som vi ikke ønsker at eksponere for skrivebeskyttede 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'

Så kan vi tilføje filteret til den service, vi ønsker at anvende. For eksempel skal alle skrivebeskyttede forbindelser filtreres for ovenstående:

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

Husk, at flere filtre kan defineres ved hjælp af en syntaks svarende til Linux shell pipe "|" syntaks. Genstart containeren for at anvende konfigurationsændringerne:

$ docker restart maxscale

Vi kan derefter bekræfte med følgende forespørgsel:

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

Du får resultatet som forventet.

Klyngendannelse

MaxScale 2.2.2 og nyere understøtter automatisk eller manuel MariaDB-replikering eller klyngendannelse til følgende hændelser:

  • failover
  • skift
  • tilslut igen
  • nulstil-replikering

Failover for master-slave-klyngen kan og bør ofte indstilles til at aktiveres automatisk. Skift skal aktiveres manuelt via MaxAdmin, MaxCtrl eller REST-grænsefladen. Gentilslut kan indstilles til automatisk eller aktiveres manuelt. Disse funktioner er implementeret i "mariadbmon"-modulet.

Følgende automatiske failover-hændelser skete, hvis vi med vilje lukkede den aktive master, 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 failover er fuldført, ser vores topologi nu sådan ud:

Til overgangsoperation kræver det menneskelig indgriben og én måde at gøre det på via MaxCtrl-konsollen. Lad os sige, at den gamle master er tilbage i drift og er klar til at blive forfremmet som master, vi kan udføre omskiftningsoperationen ved at sende følgende kommando:

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

Hvor er formateringen:

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

Bekræft derefter den nye topologi ved at angive serverne:

 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 lige forfremmet vores gamle mester tilbage til dets oprindelige sted. Sjovt faktum, ClusterControls automatiske gendannelsesfunktion gør nøjagtig det samme, hvis den er aktiveret.

Sidste tanker

At køre MariaDB MaxScale på Docker giver yderligere fordele som MaxScale-klynger, nem at opgradere og nedgradere og også avancerede proxyfunktioner til MySQL- og MariaDB-klynger.


  1. Den hellige gral med at rense input og output i php?

  2. Repræsentation af datoer, tidspunkter og intervaller i PostgreSQL

  3. ACOS() Eksempler i SQL Server

  4. Implementering af Django til Heroku (Psycopg2-fejl)