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

MariaDB MaxScale Load Balancing su Docker:Gestione:seconda parte

Questo post del blog è una continuazione di MariaDB MaxScale Load Balancing  su Docker:Deployment - Part1. In questa parte, ci concentreremo maggiormente sulle operazioni di gestione con casi d'uso avanzati come il controllo dei servizi, la gestione della configurazione, l'elaborazione delle query, la sicurezza e la riconciliazione dei cluster. I passaggi e le istruzioni di esempio mostrati in questo post si basano sugli ambienti in esecuzione che abbiamo impostato nella prima parte di questa serie di blog.

Controllo del servizio

Per MaxScale, l'avvio e l'arresto del contenitore è l'unico modo per controllare il servizio. A condizione che il contenitore sia stato creato, possiamo utilizzare il seguente comando per gestire il servizio:

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

Esecuzione senza privilegi di root

Per impostazione predefinita, i contenitori Docker vengono eseguiti con il privilegio di root, così come l'applicazione che viene eseguita all'interno del contenitore. Questa è un'altra preoccupazione importante dal punto di vista della sicurezza, perché gli hacker possono ottenere l'accesso come root all'host Docker hackerando l'applicazione in esecuzione all'interno del contenitore.

Per eseguire Docker come utente non root, devi aggiungere il tuo utente al gruppo Docker. Innanzitutto, crea un gruppo Docker se non ce n'è uno:

$ sudo groupadd docker

Quindi, aggiungi il tuo utente al gruppo Docker. In questo esempio il nostro utente è "vagabondo":

$ sudo usermod -aG docker vagrant

Esci e accedi nuovamente in modo che l'appartenenza al tuo gruppo venga rivalutata (o riavvia se non funziona). A questo punto, puoi eseguire il contenitore MaxScale con il comando di esecuzione standard (non è richiesto sudo) come utente "vagabondo":

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

Il processo MaxScale viene eseguito dall'utente "maxscale" e non richiede privilegi speciali fino al livello root. Pertanto, eseguire il contenitore in modalità non privilegiata è sempre il modo migliore se sei preoccupato per la sicurezza.

Gestione della configurazione

Per il contenitore MaxScale autonomo, la gestione della configurazione richiede la modifica del file di configurazione mappato seguita dal riavvio del contenitore MaxScale. Tuttavia, se stai utilizzando un servizio Docker Swarm, la nuova configurazione deve essere caricata in Swarm Configs come una nuova versione, ad esempio:

$ cat maxscale.cnf | docker config create maxscale_config_v2 -

Quindi, aggiorna il servizio rimuovendo le vecchie configurazioni (maxscale_config) e aggiungi quella nuova (maxscale_config_v2) alla stessa destinazione:

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

Docker Swarm pianificherà quindi la rimozione dei container e sostituirà le procedure un container alla volta fino a quando il requisito delle repliche non sarà soddisfatto.

Aggiornamento e downgrade

Uno dei vantaggi dell'esecuzione delle applicazioni in Docker è la banale procedura di aggiornamento e downgrade. Ogni contenitore in esecuzione è basato su un'immagine e questa immagine può essere cambiata facilmente con il tag immagine. Per ottenere l'elenco delle immagini disponibili per MaxScale, controlla la sezione Tag nel Docker Hub. Gli esempi seguenti mostrano il processo per eseguire il downgrade di MaxScale 2.3 a una versione secondaria precedente, 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

Assicurati che le opzioni di configurazione siano compatibili con la versione che desideri eseguire. Ad esempio, il downgrade di cui sopra non sarebbe riuscito alla prima esecuzione a causa dei seguenti errori:

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

Quello che dobbiamo fare è rimuovere le opzioni di configurazione non supportate come mostrato sopra nel file di configurazione prima di eseguire il downgrade dell'immagine del contenitore:

  • riconnessione_master
  • Riprova_ritardata
  • transazione_replay
  • timeout_lettura_causale
  • lettura_causale

Infine, riavvia il contenitore e dovresti essere a posto. L'aggiornamento della versione per MaxScale funziona in modo simile. Basta cambiare il tag che vuoi usare e il gioco è fatto.

Filtri MaxScale

MaxScale utilizza un componente chiamato filter per manipolare o elaborare le richieste mentre le attraversano. Ci sono un sacco di filtri che puoi usare, come elencato in questa pagina, MaxScale 2.3 Filters. Ad esempio, una query specifica può essere registrata in un file se corrisponde a un criterio oppure puoi riscrivere la query in entrata prima che raggiunga i server back-end.

Per attivare un filtro, devi definire una sezione e includere il nome della definizione nella definizione del servizio corrispondente, come mostrato negli esempi più in basso.

Registrazione query a tutti (QLA)

Come spiega il nome, il filtro QLA registra tutte le query che corrispondono all'insieme di regole per sessione client. Tutte le query verranno registrate seguendo il formato filebase.

Innanzitutto, definisci il componente con type=filter e 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

Quindi aggiungi il componente filtro nei nostri servizi:

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

È anche una buona idea mappare /tmp del contenitore con la directory effettiva sull'host Docker, quindi non è necessario accedere al contenitore per recuperare i file di registro generati. Innanzitutto, crea una directory e dai il permesso di scrittura globale:

$ mkdir qla
$ chmod 777 qla

Dal momento che abbiamo bisogno di associare la directory sopra nel contenitore, dobbiamo interrompere e rimuovere il contenitore in esecuzione ed eseguirlo nuovamente con il seguente comando:

$ 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

È quindi possibile recuperare il contenuto delle query registrate all'interno della directory qla:

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

Riscrittura query

La riscrittura delle query è una funzionalità che, a seconda delle query in esecuzione sul server del database, consente di isolare e correggere rapidamente le query problematiche e di migliorare le prestazioni.

La riscrittura delle query può essere eseguita tramite regexfilter. Questo filtro può abbinare o escludere istruzioni in entrata utilizzando espressioni regolari e sostituirle con un'altra istruzione. Ogni regola è definita nella sua sezione e include il nome della sezione nel servizio corrispondente per attivarla.

Il seguente filtro corrisponderà a un numero di comandi SHOW che non vogliamo esporre ai client di sola lettura:

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

Quindi possiamo aggiungere il filtro al servizio che vogliamo applicare. Ad esempio, tutte le connessioni di sola lettura devono essere filtrate per quanto sopra:

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

Tieni presente che più filtri possono essere definiti utilizzando una sintassi simile alla shell pipe di Linux "|" sintassi. Riavvia il contenitore per applicare le modifiche alla configurazione:

$ docker restart maxscale

Possiamo quindi verificare con la seguente query:

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

Otterrai il risultato come previsto.

Recupero del cluster

MaxScale 2.2.2 e versioni successive supportano la replica MariaDB automatica o manuale o il ripristino del cluster per i seguenti eventi:

  • Failover
  • passaggio
  • entrare
  • reset-replica

Il failover per il cluster master-slave può e spesso deve essere impostato per l'attivazione automatica. La commutazione deve essere attivata manualmente tramite MaxAdmin, MaxCtrl o l'interfaccia REST. Rejoin può essere impostato su automatico o attivato manualmente. Queste funzionalità sono implementate nel modulo "mariadbmon".

Se si arresta di proposito il master attivo, 192.168.0.91, si sono verificati i seguenti eventi di failover automatico:

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

Dopo il completamento del failover, la nostra topologia è ora simile a questa:

Per l'operazione di passaggio, è necessario l'intervento umano e un modo per farlo tramite la console MaxCtrl. Diciamo che il vecchio master è tornato operativo ed è pronto per essere promosso a master, possiamo eseguire l'operazione di passaggio inviando il seguente comando:

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

Dove, la formattazione è:

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

Quindi, verifica la nuova topologia elencando i 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 │
└──────────┴──────────────┴──────┴─────────────┴─────────────────┴──────────────┘

Abbiamo appena riportato il nostro vecchio maestro al suo posto originale. Curiosità, la funzionalità di ripristino automatico di ClusterControl fa esattamente la stessa cosa se è abilitata.

Pensieri finali

L'esecuzione di MariaDB MaxScale su Docker offre vantaggi aggiuntivi come il clustering MaxScale, la facilità di aggiornamento e downgrade e anche funzionalità avanzate di proxy per i cluster MySQL e MariaDB.