Nos artigos anteriores desta série construímos nosso ambiente de laboratório passo a passo. Começamos pela instalação do Oracle VirtualBox, configuramos o Oracle Linux 10, instalamos o MySQL 8.4 LTS e criamos um cluster utilizando MySQL Group Replication.
Com isso, passamos a ter um ambiente capaz de manter os dados sincronizados entre as instâncias. Porém, ainda existia uma questão importante: como disponibilizar esse cluster para as aplicações de forma transparente?
A aplicação precisaria saber qual servidor é o Primary? Como distribuir consultas de leitura entre os demais membros do cluster? E como evitar alterações na string de conexão quando ocorrer uma troca de Primary?
Neste laboratório vamos adicionar mais uma peça à arquitetura: o ProxySQL.
Seu papel será centralizar as conexões da aplicação, identificar automaticamente os membros do cluster e aplicar regras de roteamento para operações de leitura e escrita.
Pré-requisitos
Este laboratório considera que todas as etapas anteriores já foram concluídas.
O ambiente já possui um cluster MySQL Group Replication instalado e funcional. Todo o processo de preparação, incluindo instalação do Oracle Linux, configuração do MySQL e criação do cluster, foi realizado nos laboratórios anteriores.
Ambiente utilizado
| Componente | Versão |
|---|---|
| Sistema Operacional | Oracle Linux 10 |
| Banco de Dados | MySQL 8.4 LTS |
| Memória | 4 GB |
| Cluster | MySQL Group Replication |
| Proxy | ProxySQL 3.x |
Para simplificar os estudos, todo o ambiente foi montado em um único servidor.
O laboratório é composto por:
- MySQL 3306
- MySQL 3307
- MySQL 3308
- MySQL 3309
- ProxySQL
- Aplicação PHP para validação dos testes
Embora todas as instâncias estejam executando no mesmo servidor, o objetivo é reproduzir conceitos encontrados em ambientes corporativos, como balanceamento de leitura, roteamento de consultas e abstração da topologia do cluster para as aplicações.
Instalando o repositório do ProxySQL
O primeiro passo consiste em adicionar o repositório oficial do ProxySQL.
|
1 2 3 4 5 6 7 |
cat <<EOF | tee /etc/yum.repos.d/proxysql.repo <span class="text-token-text-primary cursor-text rounded-sm" data-placeholder-token="true">[proxysql_repo]</span> name=ProxySQL repository baseurl=https://repo.proxysql.com/ProxySQL/proxysql-3.0.x/centos/\$releasever gpgcheck=1 gpgkey=https://repo.proxysql.com/ProxySQL/proxysql-3.0.x/repo_pub_key EOF |
Após criar o repositório, podemos instalar o ProxySQL utilizando o gerenciador de pacotes do sistema operacional.
Instalando o ProxySQL
Realize a instalação:
|
1 |
dnf install proxysql |
Em seguida, habilite e inicialize o serviço:
|
1 |
systemctl enable --now proxysql |
Após a instalação, o ProxySQL disponibilizará sua interface administrativa na porta 6032.
Primeiro acesso ao ProxySQL
A administração do ProxySQL é realizada através de uma interface compatível com o protocolo MySQL.
Conecte-se utilizando:
|
1 |
mysql -u admin -padmin -h127.0.0.1 -P6032 --prompt='ProxySQL_Admin:> ' |
A partir deste ponto todas as configurações serão realizadas diretamente na base administrativa do ProxySQL.
Registrando o primeiro servidor do cluster
O ProxySQL precisa conhecer pelo menos um membro do cluster para iniciar o monitoramento.
Como estamos utilizando MySQL Group Replication, basta registrar uma única instância. A partir dela, o ProxySQL identificará automaticamente os demais membros do grupo.
|
1 2 3 4 5 6 7 |
INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES ( 10, 'laboratorios', 3306 ); |
Neste laboratório utilizaremos a instância da porta 3306 como ponto inicial para descoberta dos demais servidores.
Definindo os HostGroups
O ProxySQL organiza os servidores em grupos chamados HostGroups.
Cada HostGroup possui uma responsabilidade específica dentro da arquitetura.
Neste laboratório utilizaremos:
| HostGroup | Função |
| 10 | Writer |
| 12 | Backup Writer |
| 20 | Readers |
| 30 | Offline |
A configuração é realizada através do comando abaixo:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
INSERT INTO mysql_group_replication_hostgroups ( writer_hostgroup, backup_writer_hostgroup, reader_hostgroup, offline_hostgroup, active, max_writers, writer_is_also_reader ) VALUES ( 10, 12, 20, 30, 1, 1, 0 ); |
Neste cenário:
- O HostGroup 10 receberá operações de escrita.
- O HostGroup 20 receberá operações de leitura.
- O HostGroup 12 armazenará possíveis candidatos a Writer.
- O HostGroup 30 será utilizado para servidores indisponíveis.
A opção writer_is_also_reader = 0 garante que o Writer permaneça dedicado às operações de gravação.
Criando os usuários de acesso
Neste laboratório serão utilizados dois usuários para demonstrar cenários distintos de utilização.
O usuário hrproxy será utilizado pela aplicação PHP.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
INSERT INTO mysql_users ( username, password, default_hostgroup, transaction_persistent, fast_forward ) VALUES ( 'hrproxy', 'hrproxy', 10, 0, 0 ); |
Também criaremos um usuário dedicado para ferramentas analíticas, como Power BI.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
INSERT INTO mysql_users ( username, password, default_hostgroup, transaction_persistent, fast_forward ) VALUES ( 'powerbi', 'powerbi', 20, 0, 0 ); |
Dessa forma conseguimos demonstrar como diferentes perfis de acesso podem ser direcionados para HostGroups distintos.
Criando regras de roteamento
Uma das funcionalidades mais interessantes do ProxySQL é a possibilidade de encaminhar consultas para servidores diferentes de acordo com o seu padrão.
Neste laboratório criaremos duas regras simples.
A primeira garante que consultas utilizando bloqueio sejam enviadas ao Writer.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
INSERT INTO mysql_query_rules ( rule_id, active, match_pattern, destination_hostgroup, apply ) VALUES ( 1, 1, '^SELECT.*FOR UPDATE', 10, 1 ); |
A segunda regra direciona os demais SELECTs para os Readers.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
INSERT INTO mysql_query_rules ( rule_id, active, match_pattern, destination_hostgroup, apply ) VALUES ( 2, 1, '^SELECT', 20, 1 ); |
Com essas duas regras passamos a ter um cenário simples de separação entre leitura e escrita.
Aplicando as configurações
Até este momento todas as alterações foram realizadas apenas na memória administrativa do ProxySQL.
Para que elas sejam aplicadas imediatamente e persistidas após reinicializações do serviço, é necessário carregá-las para o Runtime e gravá-las em disco.
|
1 2 3 4 5 6 7 8 |
LOAD MYSQL SERVERS TO RUNTIME; SAVE MYSQL SERVERS TO DISK; LOAD MYSQL USERS TO RUNTIME; SAVE MYSQL USERS TO DISK; LOAD MYSQL QUERY RULES TO RUNTIME; SAVE MYSQL QUERY RULES TO DISK; |
Validando a configuração
Para facilitar futuras administrações, podemos criar um alias para acesso rápido ao ProxySQL.
|
1 |
alias proxy='mysql -u admin -padmin -h127.0.0.1 -P6032 --prompt="ProxySQL_Admin:> "' |
Acesse o ProxySQL:
|
1 |
proxy |
Agora podemos verificar os servidores conhecidos pelo ProxySQL.
|
1 2 3 4 5 6 |
SELECT hostgroup_id, hostname, port, status FROM runtime_mysql_servers ORDER BY hostgroup_id, port; |
Também podemos consultar o histórico de monitoramento do Group Replication.
|
1 2 3 4 5 |
SELECT * FROM monitor.mysql_server_group_replication_log GROUP BY port, hostname ORDER BY time_start_us DESC LIMIT 10; |
Se tudo estiver correto, será possível visualizar as instâncias 3306, 3307, 3308 e 3309 classificadas em seus respectivos HostGroups, além das informações coletadas pelo monitor interno do ProxySQL.
Validando com uma aplicação PHP
Após concluir a configuração, realizei os testes utilizando uma aplicação PHP conectada exclusivamente ao ProxySQL.
A aplicação não possui conhecimento direto das instâncias MySQL. Todas as conexões são realizadas através da porta 6033 do ProxySQL.
Durante os testes foi possível observar que:
- operações de escrita permaneceram direcionadas ao Writer;
- consultas de leitura foram encaminhadas para os Readers;
- a aplicação continuou utilizando o mesmo ponto de conexão independentemente da topologia do cluster.
Essa abordagem simplifica significativamente o desenvolvimento das aplicações, já que a lógica de roteamento passa a ser responsabilidade do ProxySQL.
Conclusão
Com este laboratório demos mais um passo na evolução do ambiente construído ao longo desta série.
O objetivo não foi apenas instalar o ProxySQL, mas entender como ele pode atuar como uma camada intermediária entre aplicações e um cluster MySQL Group Replication.
Utilizando quatro instâncias MySQL executando nas portas 3306, 3307, 3308 e 3309, além de uma aplicação PHP conectada através do ProxySQL, foi possível validar na prática o roteamento de consultas, a separação entre leitura e escrita e o monitoramento automático dos membros do cluster.
Mesmo sendo um ambiente simples e executado em um único servidor Oracle Linux 10, os testes reproduziram conceitos amplamente utilizados em ambientes corporativos, permitindo compreender de forma prática como o ProxySQL pode simplificar o acesso a clusters MySQL.
Nos próximos laboratórios continuaremos evoluindo essa arquitetura, explorando novos recursos do ProxySQL e aprofundando os testes em cenários mais próximos de produção.
Hands on:
Links oficial:
https://proxysql.com/documentation
