Nesta aula final do curso MySQL — Do Zero ao Avançado, você vai dominar uma das competências mais críticas para qualquer profissional de banco de dados: colocar o MySQL em produção de verdade. Não se trata apenas de subir uma instância e criar tabelas. Trata-se de projetar, implementar e validar uma arquitetura altamente disponível, tolerante a falhas e preparada para suportar cargas reais de aplicações corporativas. Ao longo desta aula, vamos trabalhar com duas ferramentas que, combinadas, formam a espinha dorsal de muitos ambientes críticos que nossos especialistas utilizam diariamente na JRT Technology Solutions: o ProxySQL como camada de roteamento, balanceamento de carga e failover transparente para a aplicação; e o MHA (MySQL High Availability) como orquestrador de failover para a camada de replicação. Você vai aprender exatamente como essas peças se encaixam, por que elas existem e como configurá-las passo a passo, sem atalhos, sem resumos vagos e sem “siga o processo padrão”.
A importância de dominar esses conceitos não pode ser subestimada. Em ambientes de produção, o banco de dados é o estado da aplicação. Cada minuto de indisponibilidade pode representar perda de receita, degradação de reputação e impacto direto na experiência do usuário. Por isso, a alta disponibilidade não é um luxo: é um requisito de negócio. O MySQL em produção exige que você saiba lidar com falhas de hardware, problemas de rede, corrupção de dados e manutenção programada sem interromper o serviço. O ProxySQL permite que a aplicação se conecte a um único ponto de entrada virtual, enquanto ele distribui as conexões entre os nós do cluster e detecta falhas automaticamente. O MHA, por sua vez, monitora a saúde do nó primário da replicação e, em caso de falha, promove um dos nós secundários a primário em segundos, garantindo a continuidade das escritas.
Antes de começar, você precisa ter concluído as aulas anteriores, especialmente aquelas dedicadas à replicação assíncrona e semissíncrona, pois esta aula assume que você já entende como funciona o binlog, o relay log, o GTID e as threads de replicação. Também é fundamental que você tenha três servidores Linux disponíveis — ou máquinas virtuais — com acesso root ou sudo, rede configurada e, idealmente, o MySQL Server 8.0 instalado em cada um. Não se preocupe se você ainda não tem experiência com ProxySQL ou MHA: esta aula foi desenhada para levar você do zero ao avançado na prática, com cada comando explicado linha por linha, cada arquivo de configuração mostrado na íntegra e cada saída esperada devidamente documentada.
Ao final desta aula, você terá um cluster funcional de MySQL em produção, composto por três nós: um primário, dois secundários, um ProxySQL na frente para roteamento de consultas e o MHA pronto para executar failover automático ou manual. Você saberá como testar o failover de forma controlada, como verificar a integridade do cluster, como diagnosticar os erros mais comuns e como aplicar as boas práticas que fazem a diferença entre um ambiente robusto e um ambiente frágil. Esta é a aula que amarra todos os conceitos do curso e transforma você em um profissional capaz de responder com confiança quando alguém perguntar: “Como você coloca MySQL em produção?”
O que você vai aprender nesta aula
- Compreender a arquitetura de alta disponibilidade com MySQL em produção, ProxySQL e MHA, identificando o papel de cada componente no fluxo de dados.
- Instalar e configurar o MHA Node e o MHA Manager em sistemas Ubuntu/Debian e CentOS/RHEL/Rocky Linux, incluindo todas as dependências de Perl e SSH.
- Configurar a replicação GTID entre três nós MySQL, estabelecendo o primário e os secundários de forma consistente e verificável.
- Instalar e configurar o ProxySQL como camada de roteamento, definindo usuários, monitoramento, grupos de servidores e regras de consulta para leitura e escrita.
- Criar todos os arquivos de configuração do MHA e do ProxySQL do zero, com comentários linha a linha, e entender cada parâmetro crítico.
- Executar procedimentos de verificação completos, incluindo testes de roteamento, failover manual e failover automático, com as saídas esperadas em cada etapa.
- Diagnosticar e corrigir os erros mais frequentes em ambientes de alta disponibilidade com MySQL em produção, como falhas de SSH, problemas de binlog e permissões de monitoramento.
- Aplicar boas práticas de segurança, tuning e operação contínua para manter o cluster saudável e preparado para o mundo real.
Pré-requisitos e Ambiente
Para acompanhar esta aula sem lacunas, você precisa de três servidores Linux com uma distribuição suportada. Vamos utilizar como referência três hosts: db1 (IP 192.168.1.101), db2 (IP 192.168.1.102) e db3 (IP 192.168.1.103). O db1 será inicialmente o primário da replicação. Você pode usar máquinas físicas, VMs em VMware ou VirtualBox, ou até instâncias em nuvem dentro de uma mesma VPC. O importante é que os três nós se enxerguem pela rede, que o SSH esteja habilitado e que você tenha permissões de root ou sudo em todos eles. Se você estiver usando CentOS/RHEL/Rocky Linux, desative o SELinux ou configure as políticas adequadas para os binários do MHA e do ProxySQL, pois o SELinux em modo enforcing pode bloquear conectividade e leitura de binlogs.
O MySQL Server 8.0 deve estar instalado e funcional nos três nós. Se você seguiu as aulas anteriores, já sabe como instalar com o mysql-apt-repository no Ubuntu ou com o repositório oficial no CentOS. Certifique-se de que o server_id seja único em cada nó, que o log_bin esteja ativado, que o gtid_mode=ON e que o enforce_gtid_consistency=ON estejam configurados. Essas são bases inegociáveis para a replicação baseada em GTID, que o MHA utiliza para localizar a posição exata dos eventos durante o failover. Se você ainda não configurou a replicação, faremos isso do zero nesta aula, passo a passo, mas ter o MySQL instalado e os parâmetros básicos definidos agiliza o processo.
Além disso, você vai precisar de um servidor extra ou de um dos próprios nós para executar o MHA Manager. Na prática, recomendamos que o Manager rode em um servidor separado, como uma máquina de gerenciamento dedicada, para que a falha de um nó de dados não afete o orquestrador. No entanto, para simplificar o aprendizado e reduzir custos de laboratório, vamos instalar o Manager no db3, um dos secundários. Em nossos projetos na JRT Technology Solutions, quando o cliente possui um orçamento de infraestrutura mais restrito, costumamos alocar o Manager em um dos secundários, mas sempre monitorando o consumo de recursos e a saúde do processo masterha_manager. Se você tiver um quarto servidor disponível, use-o para o Manager — a lógica de configuração é idêntica.
Por fim, mantenha anotados os IPs, os nomes de usuário e as senhas que você definirá nesta aula. A consistência entre os arquivos de configuração do MHA e do ProxySQL é essencial. Sugerimos criar um bloco de notas com os seguintes valores de exemplo, que usaremos em todo o laboratório: usuário de replicação repl_user com senha ReplPass@123, usuário de monitoramento monitor com senha MonitorPass@123 e usuário de aplicação app_user com senha AppPass@123. Substitua por suas próprias credenciais em produção, seguindo políticas de senha fortes da sua organização.
Fundamentos de Alta Disponibilidade com MySQL em produção
Antes de executar qualquer comando, precisamos alinhar o modelo mental. Um ambiente de MySQL em produção com alta disponibilidade é composto por três camadas lógicas: a camada de armazenamento, onde vivem os dados e a replicação; a camada de orquestração, responsável por monitorar e decidir quem é o primário; e a camada de acesso, que abstrai a topologia para a aplicação. O MHA atua na segunda camada. Ele monitora constantemente o nó primário, executando verificações de conectividade e de leitura de binlogs. Quando detecta uma falha, ele elege o candidato mais adequado entre os secundários, aplica os binlogs pendentes para minimizar a perda de dados e promove esse nó a primário, atualizando toda a topologia. O ProxySQL, por sua vez, atua na terceira camada. A aplicação se conecta a um único IP e porta, e o ProxySQL decide, a cada consulta, se ela deve ir para o primário (escritas) ou para um dos secundários (leituras). Em caso de failover, o ProxySQL é atualizado automaticamente — geralmente via scripts fornecidos pelo MHA — para redirecionar as escritas ao novo primário, sem que a aplicação precise saber o que aconteceu.
O MHA é composto por dois módulos: o MHA Node, que deve ser instalado em todos os servidores MySQL, e o MHA Manager, que é instalado no servidor de gerenciamento. O Node coleta informações dos binlogs, executa operações de recuperação e aplica eventos pendentes. O Manager orquestra o processo inteiro, tomando decisões baseadas em scripts de verificação e na saúde relatada pelos Nodes. Essa separação é importante porque o Manager não precisa estar no mesmo servidor dos dados, e os Nodes são leves o suficiente para não causar impacto perceptível na performance do MySQL. O MHA suporta replicação assíncrona e semissíncrona, trabalha com GTID ou com posições de binlog tradicionais, e é amplamente utilizado em produção há mais de uma década, inclusive em ambientes com milhares de transações por segundo.
O ProxySQL é um proxy de banco de dados de alta performance, escrito em C++, que entende o protocolo MySQL em nível de aplicação. Ele mantém pools de conexões persistentes com os backends, reduzindo drasticamente o overhead de abrir e fechar conexões a cada requisição da aplicação. Além disso, ele possui um mecanismo de regras de consulta extremamente flexível: você pode rotear SELECTs para os secundários, enviar escritas para o primário, bloquear consultas perigosas, reescrever queries, aplicar limites de conexão por usuário e muito mais. No contexto de MySQL em produção, o ProxySQL resolve o clássico problema de “a aplicação não sabe lidar com failover”. Em vez de configurar múltiplos endereços na aplicação, você configura um único endereço: o do ProxySQL. Ele sempre sabe quem é o primário e quem são os secundários, desde que você mantenha o monitoramento atualizado.
Um ponto que confunde muitos iniciantes é a diferença entre failover e switchover. O failover é o processo automático de promoção de um secundário a primário quando o primário atual falha de forma inesperada. O switchover é o processo manual e controlado, geralmente usado para manutenção programada, como troca de hardware ou atualização de versão. O MHA suporta ambos. Na prática, testaremos primeiro o switchover, que é mais seguro e nos permite validar a configuração sem derrubar servidores. Somente depois executaremos um failover real, simulando a queda do primário. Essa abordagem incremental é exatamente a que adotamos em nossos treinamentos na JRT Technology Solutions, porque minimiza o risco de o aluno ficar preso em um estado inconsistente sem saber como voltar atrás.
Passo a Passo — Instalação e Configuração do MHA
Agora vamos colocar a mão na massa. O primeiro passo é instalar o MHA Node em todos os três servidores MySQL. O MHA é escrito em Perl e possui dependências que precisam ser resolvidas antes da instalação. Em sistemas Ubuntu/Debian, as dependências são: libdbd-mysql-perl, libdbi-perl, libconfig-tiny-perl, liblog-dispatch-perl, libparallel-forkmanager-perl e libmodule-install-perl. Em sistemas CentOS/RHEL/Rocky Linux, os pacotes equivalentes são: perl-DBD-MySQL, perl-DBI, perl-Config-Tiny, perl-Log-Dispatch, perl-Parallel-ForkManager e perl-Module-Install. Além disso, todos os nós precisam de sshpass ou de chaves SSH configuradas para que o Manager consiga se conectar sem senha aos servidores de dados.
Nesta aula, usaremos os pacotes pré-compilados disponíveis no repositório oficial do MHA no GitHub. Para o Ubuntu/Debian, baixaremos os pacotes .deb; para o CentOS/RHEL/Rocky, os pacotes .rpm. A versão que utilizaremos é a 0.58-0, amplamente testada em produção. Execute os comandos abaixo em todos os três nós MySQL para configurar as dependências e instalar o MHA Node. Se preferir compilar a partir do código-fonte, o procedimento também é suportado, mas os pacotes prontos reduzem o tempo e as chances de erro de compilação.
# ============================================================
# Instalação do MHA Node — Ubuntu/Debian
# ============================================================
# Atualize a lista de pacotes
sudo apt update
# Instale as dependências Perl necessárias
sudo apt install -y libdbd-mysql-perl libdbi-perl libconfig-tiny-perl \
liblog-dispatch-perl libparallel-forkmanager-perl \
libmodule-install-perl
# Baixe o pacote .deb do MHA Node (versão 0.58-0)
wget https://github.com/yoshinorim/mha4mysql-node/releases/download/v0.58/mha4mysql-node_0.58-0_all.deb
# Instale o pacote .deb
sudo dpkg -i mha4mysql-node_0.58-0_all.deb
# Verifique se o binário principal foi instalado
which apply_diff_relay_logs
which save_binary_logs
# A saída esperada deve mostrar os caminhos:
# /usr/bin/apply_diff_relay_logs
# /usr/bin/save_binary_logs
Em sistemas CentOS/RHEL/Rocky Linux, o processo é semelhante, mas os comandos de gerenciamento de pacotes são diferentes. Execute as instruções abaixo em todos os nós:
# ============================================================
# Instalação do MHA Node — CentOS/RHEL/Rocky Linux
# ============================================================
# Instale o repositório EPEL, que contém algumas dependências
sudo yum install -y epel-release
# Instale as dependências Perl necessárias
sudo yum install -y perl-DBD-MySQL perl-DBI perl-Config-Tiny \
perl-Log-Dispatch perl-Parallel-ForkManager \
perl-Module-Install
# Baixe o pacote .rpm do MHA Node (versão 0.58-0)
wget https://github.com/yoshinorim/mha4mysql-node/releases/download/v0.58/mha4mysql-node-0.58-0.el7.noarch.rpm
# Instale o pacote .rpm
sudo rpm -ivh mha4mysql-node-0.58-0.el7.noarch.rpm
# Verifique a instalação
which apply_diff_relay_logs
which save_binary_logs
# A saída deve mostrar /usr/bin/apply_diff_relay_logs e /usr/bin/save_binary_logs
Depois de instalar o MHA Node nos três nós, precisamos configurar o MHA Manager. Como mencionamos, o Manager ficará no db3 (192.168.1.103) para este laboratório. A instalação do Manager requer as mesmas dependências Perl do Node, mais o pacote mha4mysql-manager. O Manager também precisa de perl-Log-Dispatch-FileRotate e perl-Parallel-ForkManager, que já instalamos. Execute os comandos abaixo apenas no nó que será o Manager. Para Ubuntu/Debian:
# ============================================================
# Instalação do MHA Manager — Ubuntu/Debian (no db3)
# ============================================================
# Se ainda não instalou as dependências, instale-as agora
sudo apt update
sudo apt install -y libdbd-mysql-perl libdbi-perl libconfig-tiny-perl \
liblog-dispatch-perl libparallel-forkmanager-perl \
libmodule-install-perl
# Baixe o pacote .deb do MHA Manager
wget https://github.com/yoshinorim/mha4mysql-manager/releases/download/v0.58/mha4mysql-manager_0.58-0_all.deb
# Instale o pacote
sudo dpkg -i mha4mysql-manager_0.58-0_all.deb
# Verifique os binários do Manager
which masterha_manager
which masterha_check_repl
which masterha_check_ssh
# Saída esperada: /usr/bin/masterha_manager, /usr/bin/masterha_check_repl, /usr/bin/masterha_check_ssh
Para CentOS/RHEL/Rocky, o Manager é instalado da seguinte forma no db3:
# ============================================================
# Instalação do MHA Manager — CentOS/RHEL/Rocky (no db3)
# ============================================================
sudo yum install -y epel-release
sudo yum install -y perl-DBD-MySQL perl-DBI perl-Config-Tiny \
perl-Log-Dispatch perl-Parallel-ForkManager \
perl-Module-Install perl-Log-Dispatch-FileRotate
# Baixe o pacote .rpm do MHA Manager
wget https://github.com/yoshinorim/mha4mysql-manager/releases/download/v0.58/mha4mysql-manager-0.58-0.el7.noarch.rpm
# Instale o pacote
sudo rpm -ivh mha4mysql-manager-0.58-0.el7.noarch.rpm
# Verifique os binários
which masterha_manager
which masterha_check_repl
which masterha_check_ssh
# Saída esperada: /usr/bin/masterha_manager, /usr/bin/masterha_check_repl, /usr/bin/masterha_check_ssh
Com o Node e o Manager instalados, o próximo passo crítico é configurar o SSH sem senha entre o Manager e todos os nós MySQL. O MHA Manager utiliza SSH para executar comandos remotos nos servidores de dados, como leitura de binlogs, aplicação de relay logs e promoção de nós. Sem SSH configurado corretamente, o MHA não funciona. A configuração envolve gerar um par de chaves no servidor do Manager e copiar a chave pública para os três nós. Também é necessário que o Manager consiga se conectar a si mesmo via SSH, pois o db3 é tanto Manager quanto nó de dados. Siga os passos abaixo:
# ============================================================
# Configurando SSH sem senha do Manager (db3) para todos os nós
# ============================================================
# No db3 (Manager), gere um par de chaves SSH sem passphrase
ssh-keygen -t rsa -b 4096 -N "" -f ~/.ssh/id_rsa
# Copie a chave pública para db1 (192.168.1.101)
ssh-copy-id root@192.168.1.101
# Copie para db2 (192.168.1.102)
ssh-copy-id root@192.168.1.102
# Copie para o próprio db3 (192.168.1.103)
ssh-copy-id root@192.168.1.103
# Teste a conectividade SSH para cada nó, um por vez
ssh root@192.168.1.101 "hostname; uptime"
ssh root@192.168.1.102 "hostname; uptime"
ssh root@192.168.1.103 "hostname; uptime"
# Saída esperada: cada comando deve retornar o hostname do servidor
# e o uptime, SEM pedir senha. Exemplo:
# db1
# 12:34:56 up 10 days, 2:15, 1 user, load average: 0.00, 0.01, 0.05
Ao final dessa etapa, você tem o MHA Node instalado nos três servidores MySQL, o MHA Manager instalado no db3 e a comunicação SSH sem senha funcionando em todas as direções necessárias. Esse é o alicerce sobre o qual construiremos a replicação e, posteriormente, o failover. Em nossos projetos na JRT Technology Solutions, nunca iniciamos a configuração da replicação sem antes validar o SSH, porque é uma causa muito comum de falhas silenciosas durante o failover: o Manager pode detectar a falha, mas não consegue acessar o nó secundário para promovê-lo, deixando o cluster em estado degradado.
Configurando a Replicação GTID entre os Três Nós
Antes de configurar o ProxySQL, precisamos de uma replicação saudável entre os três nós. Vamos configurar a replicação baseada em GTID (Global Transaction Identifier), que simplifica o failover do MHA porque elimina a necessidade de calcular posições exatas de binlog. Com GTID, cada transação recebe um identificador global único, composto pelo server_uuid do servidor que a originou e um número sequencial. Quando um secundário se conecta ao primário, ele informa quais GTIDs já executou e o primário envia apenas as transações faltantes. Isso torna a recuperação muito mais robusta, especialmente em cenários de failover onde múltiplos secundários podem ter conjuntos de dados ligeiramente diferentes.
Vamos começar pelo db1, que será o primário inicial. Precisamos garantir que os parâmetros de replicação estejam ativos no arquivo de configuração do MySQL. Abra o arquivo /etc/mysql/mysql.conf.d/mysqld.cnf no Ubuntu ou /etc/my.cnf no CentOS/RHEL/Rocky, e adicione ou ajuste as seguintes linhas:
# ============================================================
# Arquivo de configuração do MySQL — db1 (primário inicial)
# Localização: /etc/mysql/mysql.conf.d/mysqld.cnf (Ubuntu)
# /etc/my.cnf (CentOS/RHEL/Rocky)
# ============================================================
[mysqld]
# Identificação única do servidor na topologia
server_id = 101
# Ativa o log binário (obrigatório para replicação)
log_bin = /var/log/mysql/mysql-bin.log
# Nome do binlog no formato mysql-bin.NNNNNN
# (o caminho acima já define o prefixo)
# Ativa GTID
gtid_mode = ON
enforce_gtid_consistency = ON
# Desativa a escrita de binlog para o banco de sistema
binlog_ignore_db = mysql
# Define o formato de binlog como ROW (mais seguro para replicação)
binlog_format = ROW
# Loga as atualizações de tabelas que usam chave primária como eventos
# de linha completos, melhorando a consistência
binlog_row_image = FULL
# Habilita checksum nos eventos de binlog
binlog_checksum = CRC32
# Expira os binlogs após 7 dias (ajuste conforme sua política)
binlog_expire_logs_seconds = 604800
# Ativa o cache de binlog para melhor performance
binlog_cache_size = 1M
# Define o tamanho máximo de cada binlog antes da rotação
max_binlog_size = 100M
# Habilita o log de relay (para quando este nó for secundário)
relay_log = /var/log/mysql/relay-log
# Expira os relay logs após 7 dias
relay_log_expire_logs_seconds = 604800
# Evita que o relay log seja removido imediatamente, útil no failover
relay_log_purge = ON
# Define o modo de recuperação do relay log
relay_log_recovery = ON
# Ativa o log de atualizações do relay log (para o MHA)
log_slave_updates = ON
# Habilita leitura de binlogs sem exigir privilégios especiais
# (o MHA Manager usará um usuário com REPLICATION SLAVE)
Repita essa configuração nos nós db2 e db3, alterando apenas o server_id para 102 e 103, respectivamente. Reinicie o MySQL em cada nó após a alteração. No Ubuntu, use sudo systemctl restart mysql; no CentOS/RHEL/Rocky, sudo systemctl restart mysqld. Depois, crie o usuário de replicação em todos os nós, mas ative a replicação apenas nos secundários. Execute no db1, db2 e db3:
# ============================================================
# Criando o usuário de replicação em todos os nós
# ============================================================
sudo mysql -u root -p
# Digite a senha do root do MySQL
-- No prompt do MySQL, execute:
CREATE USER 'repl_user'@'%' IDENTIFIED BY 'ReplPass@123';
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'repl_user'@'%';
FLUSH PRIVILEGES;
EXIT;
# ============================================================
# Configurando a replicação nos secundários (db2 e db3)
# ============================================================
# No db2 (192.168.1.102) e no db3 (192.168.1.103), execute:
sudo mysql -u root -p
# Digite a senha do root
-- Pare a thread de replicação se existir (primeira configuração)
STOP REPLICA;
-- Configure a fonte de replicação usando GTID
CHANGE REPLICATION SOURCE TO
SOURCE_HOST = '192.168.1.101',
SOURCE_USER = 'repl_user',
SOURCE_PASSWORD = 'ReplPass@123',
SOURCE_AUTO_POSITION = 1;
-- Inicie a replicação
START REPLICA;
-- Verifique o status
SHOW REPLICA STATUS\G
-- Confira os campos:
-- Replica_IO_Running: Yes
-- Replica_SQL_Running: Yes
-- Retrieved_Gtid_Set: deve mostrar GTIDs recebidos do db1
-- Executed_Gtid_Set: deve mostrar GTIDs aplicados
EXIT;
Após iniciar a replicação nos dois secundários, verifique no primário se ambos estão conectados. Execute no db1 o comando SHOW REPLICAS; ou SHOW PROCESSLIST; para confirmar que existem duas conexões de replicação ativas, uma para cada secundário. Se você seguiu todos os passos, a topologia está funcionando. Esse é o ponto de partida para configurar o MHA e o ProxySQL. A saída esperada do SHOW REPLICA STATUS\G em um secundário saudável deve conter os seguintes trechos relevantes:
*************************** 1. row ***************************
Replica_IO_State: Waiting for source to send event
Source_Host: 192.168.1.101
Source_User: repl_user
Source_Port: 3306
Connect_Retry: 60
Source_Log_File: mysql-bin.000003
Read_Source_Log_Pos: 4567
Relay_Log_File: relay-log.000002
Relay_Log_Pos: 890
Relay_Source_Log_File: mysql-bin.000003
Replica_IO_Running: Yes
Replica_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Source_Log_Pos: 4567
Relay_Log_Space: 1200
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Source_SSL_Allowed: No
Source_SSL_CA_File:
Source_SSL_CA_Path:
Source_SSL_Cert:
Source_SSL_Cipher:
Source_SSL_Key:
Seconds_Behind_Source: 0
Source_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Source_Server_Id: 101
Source_UUID: a1b2c3d4-e5f6-7890-abcd-ef1234567890
Source_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Replica_SQL_Running_State: Replica has read all relay log; waiting for more updates
Source_Retry_Count: 86400
Source_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Source_SSL_Crl:
Source_SSL_Crlpath:
Retrieved_Gtid_Set: a1b2c3d4-e5f6-7890-abcd-ef1234567890:1-10
Executed_Gtid_Set: a1b2c3d4-e5f6-7890-abcd-ef1234567890:1-10
Auto_Position: 1
Configuração Detalhada — Arquivos do MHA
Agora que a replicação está ativa, vamos criar os arquivos de configuração do MHA. O MHA Manager utiliza um arquivo de configuração por “aplicação” ou por cluster. Neste laboratório, chamaremos nossa aplicação de app1. O arquivo ficará em /etc/mha/app1.cnf no servidor do Manager (db3). Dentro dele, definiremos os nós do cluster, as credenciais, os scripts de verificação e os parâmetros de failover. O conteúdo completo do arquivo é mostrado abaixo, com comentários explicando cada diretiva. Preste atenção especial aos campos hostname, que devem refletir exatamente os IPs ou nomes resolvíveis dos seus servidores, e ao campo candidate_master, que indica quais secundários podem ser promovidos.
# ============================================================
# Arquivo de configuração do MHA — /etc/mha/app1.cnf
# ============================================================
[server default]
# Usuário de replicação que o MHA usará para se conectar ao MySQL
user=repl_user
password=ReplPass@123
# Porta padrão do MySQL
port=3306
# Caminho para o binário mysql no servidor do Manager
mysql_binlog=/usr/bin/mysqlbinlog
# Usuário do SO para execução remota via SSH
ssh_user=root
# Diretório de trabalho do MHA no Manager
manager_workdir=/var/log/mha/app1
# Diretório remoto onde os binlogs são salvos temporariamente
remote_workdir=/var/log/mha/app1
# Scripta para verificação de conectividade secundária
secondary_check_script=/usr/bin/masterha_secondary_check -s 192.168.1.102 -s 192.168.1.103
# Script de notificação em caso de failover
master_ip_failover_script=
# Número de tentativas para detecção de falha
ping_interval=1
ping_type=SELECT
# Tolerância para latência de replicação
max_seconds_behind_master=30
# Habilita o modo GTID
use_gtid=1
# Define que o failover deve promover o nó mais atualizado
check_repl_delay=1
# Diretório de logs do Manager
log_level=info
[server1]
hostname=192.168.1.101
candidate_master=1
master_binlog_dir=/var/log/mysql
[server2]
hostname=192.168.1.102
candidate_master=1
master_binlog_dir=/var/log/mysql
[server3]
hostname=192.168.1.103
candidate_master=0
master_binlog_dir=/var/log/mysql
Vamos analisar as diretivas mais importantes. A seção [server default] define parâmetros que se aplicam a todos os servidores listados nas seções [serverN]. O campo user e password são as credenciais do usuário de replicação que o MHA usará para se conectar e executar comandos como SHOW REPLICA STATUS, STOP REPLICA e CHANGE REPLICATION SOURCE. O ssh_user é o usuário do sistema operacional usado para as conexões SSH — no nosso laboratório, root. Em produção, recomendamos criar um usuário dedicado com permissões de sudo apenas para os comandos necessários, seguindo o princípio do menor privilégio. O secondary_check_script é fundamental: ele instrui o Manager a verificar a saúde do primário a partir de múltiplos pontos de vista. O script masterha_secondary_check recebe dois IPs de secundários e, se ambos também não conseguirem se conectar ao primário, o Manager conclui que a falha é real e não apenas um problema de rede local do Manager. Sem isso, um simples particionamento de rede entre o Manager e o primário poderia desencadear um failover desnecessário, causando split-brain.
O campo ping_interval define a frequência, em segundos, com que o Manager verifica a conectividade com o primário. O ping_type=SELECT instrui o Manager a executar um SELECT simples para validar que o MySQL está respondendo, não apenas que o host está acessível. O max_seconds_behind_master define o limite de atraso de replicação aceitável para um secundário ser promovido. Se um secundário estiver mais de 30 segundos atrasado, ele não será considerado candidato. O use_gtid=1 ativa a integração com GTID, permitindo que o MHA utilize os GTIDs para aplicar apenas as transações pendentes durante o failover. Finalmente, o candidate_master em cada seção [serverN] controla se aquele nó pode ser promovido a primário. No nosso caso, db1 e db2 podem ser primários, mas db3 não, porque escolhemos db3 como Manager e, muitas vezes, preferimos que o Manager não assuma o papel de primário para evitar sobrecarregar a mesma máquina.
É importante criar os diretórios de trabalho referenciados no arquivo, tanto no Manager quanto nos nós remotos. Execute os seguintes comandos em todos os nós e no Manager:
# ============================================================
# Criando diretórios de trabalho do MHA
# ============================================================
# Em todos os nós MySQL e no Manager, execute:
sudo mkdir -p /var/log/mha/app1
sudo chown -R root:root /var/log/mha
# No Manager (db3), verifique se o arquivo de configuração está legível
sudo cat /etc/mha/app1.cnf
# Saída esperada: o conteúdo completo do arquivo, sem erros de sintaxe
Depois de criar o arquivo, o próximo passo é validar a configuração com os scripts de verificação do MHA. O comando masterha_check_ssh valida se o Manager consegue se conectar via SSH a todos os nós sem senha. O comando masterha_check_repl valida se a replicação está saudável, se as credenciais estão corretas e se o MHA consegue acessar os binlogs e relay logs. Execute ambos como root no Manager:
# ============================================================
# Validando a configuração do MHA — SSH e Replicação
# ============================================================
# Verificação de SSH
sudo masterha_check_ssh --conf=/etc/mha/app1.cnf
# Verificação de replicação
sudo masterha_check_repl --conf=/etc/mha/app1.cnf
A saída esperada de masterha_check_ssh deve indicar que todos os hosts foram acessados com sucesso. A saída de masterha_check_repl deve confirmar que a replicação está saudável e que o MHA pode ler os binlogs. Veja um exemplo real de saída bem-sucedida:
# Saída de masterha_check_ssh
Tue Sep 14 10:15:22 2026 - [info] Executing SSH checks for all hosts...
Tue Sep 14 10:15:22 2026 - [info] All SSH connection tests passed successfully.
# Saída de masterha_check_repl
Tue Sep 14 10:16:01 2026 - [info] Reading default configuration from /etc/mha/app1.cnf...
Tue Sep 14 10:16:01 2026 - [info] Checking replication health on 192.168.1.101...
Tue Sep 14 10:16:02 2026 - [info] Checking replication health on 192.168.1.102...
Tue Sep 14 10:16:03 2026 - [info] Checking replication health on 192.168.1.103...
Tue Sep 14 10:16:04 2026 - [info] Replication health check passed.
Tue Sep 14 10:16:04 2026 - [info] Checking if there is a primary server configured...
Tue Sep 14 10:16:04 2026 - [info] Checking secondary backup settings...
Tue Sep 14 10:16:05 2026 - [info] Checking binlog settings...
Tue Sep 14 10:16:05 2026 - [info] Binlog settings check passed.
Tue Sep 14 10:16:05 2026 - [info] MySQL Replication Health is OK.
Se os dois checks passarem sem erros, sua configuração do MHA está correta e você pode prosseguir para a instalação do ProxySQL. Caso encontre erros, não avance: anote a mensagem exata e consulte a seção de erros comuns desta aula, onde abordaremos as causas mais frequentes e suas soluções.
Passo a Passo — Instalação e Configuração do ProxySQL
Com o MHA validado, chegamos à camada de acesso. O ProxySQL será instalado em um servidor dedicado ou em um dos nós, dependendo da sua preferência. Para este laboratório, instalaremos o ProxySQL no db3, junto com o Manager, para simplificar a quantidade de máquinas. Em produção, na JRT Technology Solutions, recomendamos fortemente um servidor dedicado para o ProxySQL, especialmente se a aplicação tiver alto volume de conexões. O ProxySQL consome pouca CPU, mas a latência de rede entre a aplicação e o ProxySQL é crítica, então posicione-o o mais próximo possível da aplicação, geralmente na mesma sub-rede ou até na mesma máquina em arquiteturas menores.
A instalação no Ubuntu/Debian utiliza o repositório oficial do ProxySQL. Execute os comandos abaixo no servidor onde o ProxySQL ficará — no nosso caso, db3:
# ============================================================
# Instalação do ProxySQL — Ubuntu/Debian (no db3)
# ============================================================
# Adicione o repositório oficial do ProxySQL
sudo apt update
sudo apt install -y lsb-release wget gnupg
wget -O - 'https://repo.proxysql.com/ProxySQL/repo_pub_key' | sudo apt-key add -
echo "deb https://repo.proxysql.com/ProxySQL/proxysql-2.7.x/$(lsb_release -sc)/ ./" \
| sudo tee /etc/apt/sources.list.d/proxysql.list
sudo apt update
# Instale o ProxySQL
sudo apt install -y proxysql
# Habilite e inicie o serviço
sudo systemctl enable proxysql
sudo systemctl start proxysql
# Verifique o status
sudo systemctl status proxysql
# Saída esperada: Active: active (running)
Para CentOS/RHEL/Rocky Linux, o processo é similar, usando o repositório RPM oficial:
# ============================================================
# Instalação do ProxySQL — CentOS/RHEL/Rocky (no db3)
# ============================================================
# Adicione o repositório oficial do ProxySQL
sudo tee /etc/yum.repos.d/proxysql.repo <<'EOF'
[proxysql_repo]
name=ProxySQL YUM repository
baseurl=https://repo.proxysql.com/ProxySQL/proxysql-2.7.x/centos/$releasever
gpgcheck=1
gpgkey=https://repo.proxysql.com/ProxySQL/repo_pub_key
EOF
# Limpe o cache e instale
sudo yum clean all
sudo yum install -y proxysql
# Habilite e inicie o serviço
sudo systemctl enable proxysql
sudo systemctl start proxysql
# Verifique o status
sudo systemctl status proxysql
# Saída esperada: Active: active (running)
Após a instalação, o ProxySQL estará rodando na porta 6033 para conexões de aplicação e na porta 6032 para administração. A porta de administração utiliza o usuário admin com senha admin por padrão — você deve alterá-la imediatamente. A configuração do ProxySQL pode ser feita via arquivo de configuração ou via interface SQL administrativa. Nesta aula, usaremos a interface SQL, que é a forma mais flexível e a que recomendamos para ambientes dinâmicos. Primeiro, conecte-se à interface administrativa:
# ============================================================
# Conectando-se à interface administrativa do ProxySQL
# ============================================================
# O ProxySQL admin aceita MySQL client na porta 6032
mysql -u admin -padmin -h 127.0.0.1 -P 6032
# Saída esperada:
# Welcome to the MySQL monitor. Commands end with ; or \g.
# Your MySQL connection id is 1
# Server version: 5.5.30 (ProxySQL Admin Module)
# mysql>
Agora, vamos configurar os backends MySQL no ProxySQL. Precisamos informar ao ProxySQL os endereços dos três nós, definir qual é o grupo de leitura e qual é o grupo de escrita, e criar usuários de monitoramento e de aplicação. O ProxySQL utiliza hostgroups para agrupar servidores. Por convenção, o hostgroup 0 é para escritas (primário) e o hostgroup 1 é para leituras (secundários). No entanto, você pode usar qualquer numeração. O importante é que as regras de consulta saibam mapear cada tipo de operação para o hostgroup correto. Execute os comandos abaixo no prompt administrativo do ProxySQL:
-- ============================================================
-- Configurando os backends MySQL no ProxySQL
-- ============================================================
-- Insira os três servidores MySQL
INSERT INTO mysql_servers(hostgroup_id
Quer aprender na prática com especialistas?
A JRT Technology Solutions oferece treinamentos e implementação de MySQL para equipes corporativas.