Balanceamento de carga MariaDB MaxScale no Docker:gerenciamento:parte dois

Esta postagem do blog é uma continuação do MariaDB MaxScale Load Balancing on Docker:Deployment - Part1. Nesta parte, vamos nos concentrar mais em operações de gerenciamento com casos de uso avançados, como controle de serviço, gerenciamento de configuração, processamento de consultas, segurança e reconciliação de cluster. As etapas e instruções de exemplo mostradas nesta postagem são baseadas nos ambientes em execução que configuramos na primeira parte desta série de blogs.

Controle de Serviço

Para MaxScale, iniciar e parar o contêiner é a única maneira de controlar o serviço. Desde que o contêiner tenha sido criado, podemos usar o seguinte comando para gerenciar o serviço:

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

Executando sem privilégios de root

Os contêineres do Docker, por padrão, são executados com o privilégio de root, assim como o aplicativo que é executado dentro do contêiner. Essa é outra grande preocupação do ponto de vista da segurança, pois os hackers podem obter acesso root ao host do Docker invadindo o aplicativo em execução dentro do contêiner.

Para executar o Docker como um usuário não root, você precisa adicionar seu usuário ao grupo docker. Em primeiro lugar, crie um grupo docker se não houver um:

$ sudo groupadd docker

Em seguida, adicione seu usuário ao grupo docker. Neste exemplo nosso usuário é "vagrant":

$ sudo usermod -aG docker vagrant

Saia e faça login novamente para que sua associação ao grupo seja reavaliada (ou reinicie se não funcionar). Neste ponto, você pode executar o contêiner MaxScale com o comando run padrão (sem necessidade de sudo) como usuário "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

O processo MaxScale é executado pelo usuário "maxscale" e não requer privilégios especiais até o nível raiz. Assim, executar o container no modo não privilegiado é sempre o melhor caminho se você estiver preocupado com a segurança.

Gerenciamento de configuração

Para o contêiner MaxScale autônomo, o gerenciamento de configuração requer a modificação do arquivo de configuração mapeado seguida pela reinicialização do contêiner MaxScale. No entanto, se você estiver executando como um serviço Docker Swarm, a nova configuração deverá ser carregada nos Swarm Configs como uma nova versão, por exemplo:

$ cat maxscale.cnf | docker config create maxscale_config_v2 -

Em seguida, atualize o serviço removendo as configurações antigas (maxscale_config) e adicione a nova (maxscale_config_v2) ao mesmo destino:

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

O Docker Swarm agendará a remoção do contêiner e substituirá os procedimentos um contêiner por vez até que o requisito de réplicas seja atendido.

Atualização e downgrade

Uma das vantagens de executar seus aplicativos no Docker é o procedimento trivial de atualização e downgrade. Cada contêiner em execução é baseado em uma imagem, e essa imagem pode ser trocada facilmente com a tag de imagem. Para obter a lista de imagens disponíveis para MaxScale, confira a seção Tags no Docker Hub. Os exemplos a seguir mostram o processo de downgrade de um MaxScale 2.3 para uma versão secundária anterior, 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

Certifique-se de que as opções de configuração sejam compatíveis com a versão que você deseja executar. Por exemplo, o downgrade acima falharia na primeira execução devido aos seguintes erros:

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

O que precisamos fazer é remover as opções de configuração não suportadas, conforme mostrado acima no arquivo de configuração, antes de fazer o downgrade da imagem do contêiner:

master_reconnection
repetição_atrasada
transaction_replay
causal_reads_timeout
causal_reads

Finalmente, inicie o recipiente novamente e você deve estar bem. A atualização de versão para MaxScale funciona de forma semelhante. Basta alterar a tag que você deseja usar e pronto.

Filtros MaxScale

MaxScale usa um componente chamado filtro para manipular ou processar as solicitações à medida que passam por ele. Há vários filtros que você pode usar, conforme listado nesta página, Filtros MaxScale 2.3. Por exemplo, uma consulta específica pode ser registrada em um arquivo se corresponder a um critério ou você pode reescrever a consulta recebida antes que ela chegue aos servidores de back-end.

Para ativar um filtro, você deve definir uma seção e incluir o nome da definição na definição de serviço correspondente, conforme mostrado nos exemplos mais abaixo.

Registro de consultas todos (QLA)

Como o próprio nome explica, o filtro QLA registra todas as consultas que correspondem ao conjunto de regras por sessão do cliente. Todas as consultas serão registradas seguindo o formato da base de arquivos.

Primeiramente, defina o componente com 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

Em seguida, adicione o componente de filtro em nossos serviços:

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

Também é uma boa ideia mapear /tmp do contêiner com o diretório real no host do Docker, para que não precisemos acessar o contêiner para recuperar os arquivos de log gerados. Em primeiro lugar, crie um diretório e dê permissão global gravável:

$ mkdir qla
$ chmod 777 qla

Como precisamos vincular o diretório acima ao contêiner, precisamos parar e remover o contêiner em execução e executá-lo novamente com o seguinte 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

Você pode então recuperar o conteúdo das consultas registradas dentro do diretório qla:

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

Reescrita de consulta

A reescrita de consultas é um recurso que, dependendo das consultas executadas no servidor de banco de dados, permite isolar e corrigir rapidamente consultas problemáticas e melhorar o desempenho.

A reescrita da consulta pode ser feita via regexfilter. Esse filtro pode corresponder ou excluir instruções de entrada usando expressões regulares e substituí-las por outra instrução. Cada regra é definida em sua própria seção e inclui o nome da seção no serviço correspondente para ativá-la.

O filtro a seguir corresponderá a vários comandos SHOW que não queremos expor aos clientes somente leitura:

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

Em seguida, podemos anexar o filtro ao serviço que desejamos aplicar. Por exemplo, todas as conexões somente leitura devem ser filtradas para o acima:

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

Lembre-se de que vários filtros podem ser definidos usando uma sintaxe semelhante ao shell pipe do Linux "|" sintaxe. Reinicie o contêiner para aplicar as alterações de configuração:

$ docker restart maxscale

Podemos então verificar com a seguinte consulta:

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

Você obterá o resultado conforme o esperado.

Recuperação de cluster

O MaxScale 2.2.2 e posterior oferece suporte à replicação automática ou manual do MariaDB ou à recuperação de cluster para os seguintes eventos:

failover
troca
voltar
redefinir-replicação

O failover para o cluster mestre-escravo pode e geralmente deve ser definido para ser ativado automaticamente. A alternância deve ser ativada manualmente por meio do MaxAdmin, MaxCtrl ou da interface REST. A reintegração pode ser definida como automática ou ativada manualmente. Esses recursos são implementados no módulo "mariadbmon".

Os seguintes eventos de failover automático aconteceram se desligarmos propositalmente o mestre ativo, 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]

Após a conclusão do failover, nossa topologia ficará assim:

Para operação de alternância, requer intervenção humana e uma maneira de fazê-lo através do console MaxCtrl. Digamos que o antigo mestre esteja novamente operacional e pronto para ser promovido como mestre, podemos realizar a operação de switchover enviando o seguinte comando:

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

Onde, a formatação é:

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

Em seguida, verifique a nova topologia listando os servidores:

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

Acabamos de promover nosso antigo mestre de volta ao seu local original. Curiosidade, o recurso de recuperação automática do ClusterControl faz exatamente a mesma coisa se estiver ativado.

Considerações finais

A execução do MariaDB MaxScale no Docker traz benefícios adicionais, como clustering MaxScale, facilidade de upgrade e downgrade, e também funcionalidades avançadas de proxy para clusters MySQL e MariaDB.