O que há de novo no MariaDB MaxScale 2.4

O MaxScale 2.4 foi lançado em 21 de dezembro de 2019 e o ClusterControl 1.7.6 oferece suporte ao monitoramento e gerenciamento até esta versão. No entanto, para implantação, o ClusterControl suporta apenas até a versão 2.3. É preciso atualizar a instância manualmente e, felizmente, as etapas de atualização são muito diretas. Basta baixar a versão mais recente da página de download do MariaDB MaxScale e executar o comando de instalação do pacote.

Os comandos a seguir mostram como atualizar de um MaxScale 2.3 existente para o MaxScale 2.4 em uma caixa CentOS 7:

$ wget https://dlm.mariadb.com/1067184/MaxScale/2.4.10/centos/7/x86_64/maxscale-2.4.10-1.centos.7.x86_64.rpm
$ systemctl stop maxscale
$ yum localinstall -y maxscale-2.4.10-1.centos.7.x86_64.rpm
$ systemctl start maxscale
$ maxscale --version
MaxScale 2.4.10

Nesta postagem do blog, vamos destacar algumas das melhorias notáveis ​​e novos recursos desta versão e como ela fica em ação. Para uma lista completa de mudanças no MariaDB MaxScale 2.4, confira seu changelog.

Histórico de comandos do modo interativo

Esta é basicamente uma pequena melhoria com um grande impacto na administração do MaxScale e na eficiência das tarefas de monitoramento. O modo interativo para MaxCtrl agora tem seu histórico de comandos. O histórico de comandos permite que você repita facilmente o comando executado pressionando a tecla de seta para cima ou para baixo. No entanto, a funcionalidade Ctrl+R (lembre-se do último comando que corresponde aos caracteres que você fornece) ainda não está lá.

Nas versões anteriores, era necessário usar o modo shell padrão para garantir que os comandos fossem capturados pelo arquivo .bash_history.

Monitoramento GTID para galeramon

Este é um bom aprimoramento para quem está executando no Galera Cluster com redundância geográfica por meio de replicação assíncrona, também conhecida como replicação cluster a cluster ou replicação MariaDB Galera Cluster sobre MariaDB Replication.

No MaxScale 2.3 e anterior, é assim que você habilita a replicação mestre-escravo entre os clusters MariaDB:

Para MaxScale 2.4, agora está assim (preste atenção ao Galera1's fileira):

Agora é mais fácil ver o estado de replicação de todos os nós do MaxScale, sem a necessidade de verificar os nós individuais repetidamente.

Roteador Inteligente

UPDATE `money_in` SET `accountholdername` = ? , `modifiedon` = ? , `status` = ? , `modifiedby` = ? WHERE `id` = ? 

Este é um recurso muito útil se você estiver executando o MariaDB em uma replicação geográfica de vários sites ou uma combinação de mecanismos de armazenamento MariaDB em uma cadeia de replicação, por exemplo, um escravo dedicado para lidar com cargas de trabalho de transação (OLTP ) com o mecanismo de armazenamento InnoDB e outro escravo dedicado para lidar com cargas de trabalho de análise (OLAP) com o mecanismo de armazenamento Columnstore.

Suponha que tenhamos dois locais - Sydney e Cingapura, conforme ilustrado no diagrama a seguir:

O site principal está localizado em Cingapura e tem um MariaDB master e um slave , enquanto outro escravo somente leitura está localizado em Sydney. O aplicativo se conecta à instância MaxScale localizada em seu respectivo país com as seguintes configurações de porta:

• Divisão de leitura-gravação:3306
• Round robin:3307
• Roteador inteligente:3308

[SmartQuery]
type=service
router=smartrouter
servers=DB_1,DB_2,DB_5
master=DB_1
user=maxscale
password=******

[SmartQuery-Listener]
type = listener
service = SmartQuery
protocol = mariadbclient
port = 3308

Reinicie o MaxScale e comece a enviar uma consulta somente leitura para ambos os nós MaxScale localizados em Cingapura e Sydney. Se a consulta for processada pelo roteador round-robin (porta 3307), veremos que a consulta está sendo roteada com base no algoritmo round-robin:

(app)$ mysql -usbtest -p -h maxscale_sydney -P3307 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+--------------------+
| count(id) | @@hostname         |
+-----------+--------------------+
|   1000000 | mariadb_singapore2 |
+-----------+--------------------+

A partir do exposto, podemos dizer que o MaxScale de Sydney encaminhou a consulta acima para o escravo de Cingapura, que não é a melhor opção de roteamento em si.

Com o SmartRouter escutando na porta 3308, veríamos que a consulta está sendo roteada para o escravo mais próximo em Sydney:

(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+-----------------+
| count(id) | @@hostname      |
+-----------+-----------------+
|   1000000 | mariadb_sydney1 |
+-----------+-----------------+

E se a mesma consulta for executada em nosso site de Cingapura, ela será roteada para o escravo MariaDB localizado em Cingapura:

(app)$ mysql -usbtest -p -h maxscale_singapore -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+--------------------+
| count(id) | @@hostname         |
+-----------+--------------------+
|   1000000 | mariadb_singapore2 |
+-----------+--------------------+

Mas há um problema. Quando o SmartRouter vê uma consulta de leitura cujo canônico não foi visto antes, ele enviará a consulta para todos os clusters. A primeira resposta de um cluster designará esse cluster como o melhor para esse canônico. Além disso, quando a primeira resposta é recebida, as outras consultas são canceladas. A resposta é enviada ao cliente assim que todos os clusters tiverem respondido à consulta ou ao cancelamento.

Isso significa que, para acompanhar a consulta canônica (consulta normalizada) e medir seu desempenho, você provavelmente verá a primeira consulta falhar em sua primeira execução, por exemplo:

(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
ERROR 2013 (HY000) at line 1: Lost connection to MySQL server during query

A partir do log geral no MariaDB Sydney, podemos dizer que a primeira consulta (ID 74) foi executada com sucesso (conectar, consultar e sair), apesar do erro "Conexão perdida" do MaxScale:

  74 Connect  [email protected] as anonymous on 
  74 Query    SELECT COUNT(id),@@hostname FROM sbtest.sbtest1
  74 Quit

Enquanto a consulta subsequente idêntica foi processada corretamente e retornada com a resposta correta:

(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+------------------------+
| count(id) | @@hostname             |
+-----------+------------------------+
|   1000000 | mariadb_sydney.cluster |
+-----------+------------------------+

Olhando novamente para o log geral no MariaDB Sydney (ID 75), os mesmos eventos de processamento aconteceram exatamente como na primeira consulta:

  75 Connect  [email protected] as anonymous on 
  75 Query    SELECT COUNT(id),@@hostname FROM sbtest.sbtest1
  75 Quit

A partir dessa observação, podemos concluir que, ocasionalmente, o MaxScale precisa falhar na primeira consulta para medir o desempenho e se tornar mais inteligente para as consultas idênticas subsequentes. Seu aplicativo deve ser capaz de lidar com esse "primeiro erro" corretamente antes de retornar ao cliente ou tentar novamente a transação.

Soquete UNIX para Servidor

Existem várias maneiras de se conectar a um servidor MySQL ou MariaDB em execução. Você pode usar o TCP/IP de rede padrão com endereço IP e porta do host (conexão remota), pipes nomeados/memória compartilhada no Windows ou arquivos de soquete Unix em sistemas baseados em Unix. O arquivo socket UNIX é um tipo especial de arquivo que facilita a comunicação entre diferentes processos, que neste caso é o cliente MySQL e o servidor. O arquivo de soquete é uma comunicação baseada em arquivo e você não pode acessar o soquete de outra máquina. Ele fornece uma conexão mais rápida que o TCP/IP (sem sobrecarga de rede) e uma abordagem de conexão mais segura, pois pode ser usado apenas ao se conectar a um serviço ou processo no mesmo computador.

Supondo que o servidor MaxScale também esteja instalado no próprio MariaDB Server, podemos usar o arquivo socket UNIX socket. Na seção Servidor, remova ou comente a linha "endereço" e adicione o parâmetro socket com a localização do arquivo socket:

[DB_2]
type=server
protocol=mariadbbackend
#address=54.255.133.39
socket=/var/lib/mysql/mysql.sock

Antes de aplicar as alterações acima, temos que criar um usuário MaxScale axscale de localhost. No servidor mestre:

MariaDB> CREATE USER 'maxscale'@'localhost' IDENTIFIED BY 'maxscalep4ss';
MariaDB> GRANT SELECT ON mysql.user TO 'maxscale'@'localhost';
MariaDB> GRANT SELECT ON mysql.db TO 'maxscale'@'localhost';
MariaDB> GRANT SELECT ON mysql.tables_priv TO 'maxscale'@'localhost';
MariaDB> GRANT SHOW DATABASES ON *.* TO 'maxscale'@'localhost';

Após uma reinicialização, MaxScale mostrará o caminho do soquete UNIX em vez do endereço real, e a lista de servidores será mostrada assim:

Como você pode ver, as informações de estado e GTID são recuperadas corretamente por meio de uma conexão de soquete. Observe que este DB_2 ainda está atendendo a porta 3306 para conexões remotas. Apenas mostra que o MaxScale usa um soquete para se conectar a este servidor para monitoramento.

Usar socket é sempre melhor, pois só permite conexões locais e é mais seguro. Você também pode fechar seu servidor MariaDB da rede (por exemplo, --skip-networking) e deixar MaxScale lidar com as conexões "externas" e encaminhá-las para o servidor MariaDB via arquivo de soquete UNIX.

Drenagem do servidor

No MaxScale 2.4, os servidores backend podem ser drenados, o que significa que as conexões existentes podem continuar a ser usadas, mas nenhuma nova conexão será criada com o servidor. Com o recurso de drenagem, podemos realizar uma atividade de manutenção normal sem afetar a experiência do usuário do lado do aplicativo. Observe que a drenagem de um servidor pode levar mais tempo, dependendo das consultas em execução que precisam ser fechadas normalmente.

Para drenar um servidor, use o seguinte comando:

O efeito posterior pode ser um dos seguintes estados:

• Drenando - O servidor está sendo drenado.
• Drenado - O servidor foi drenado. O servidor estava sendo drenado e agora o número de conexões com o servidor caiu para 0.
• Manutenção - O servidor está em manutenção.

Conclusão