Aula 21: Replicação MySQL — Master-Slave e Group Replication
Nesta aula avançada do nosso curso, vamos explorar um dos pilares da alta disponibilidade e escalabilidade em bancos de dados: a Replicação MySQL. A replicação permite copiar dados de um servidor MySQL para um ou mais servidores de destino, criando ambientes resilientes, distribuídos geograficamente e prontos para atender cargas de leitura intensas ou garantir a continuidade operacional em caso de falhas. Diferentemente de uma simples cópia de backup, a replicação mantém os dados sincronizados de forma contínua e automática, com latência tipicamente inferior a um segundo em redes de baixa latência — algo que nossos especialistas da JRT Technology Solutions utilizam diariamente em projetos de infraestrutura crítica.
Ao longo desta aula, você aprenderá a projetar, configurar e validar dois modelos de Replicação MySQL: a replicação assíncrona master-slave (também chamada de replicação baseada em binlog) e a Group Replication, que implementa um cluster multi-master com detecção automática de falhas e consistência baseada no protocolo Paxos. Cada modelo tem suas características, vantagens e cenários ideais, e dominar ambos permitirá que você tome decisões arquiteturais corretas de acordo com os requisitos de disponibilidade, consistência e desempenho do seu ambiente.
Por que a replicação é tão importante? Em ambientes de produção, um único servidor de banco de dados representa um ponto único de falha. Se o hardware falhar, se houver manutenção programada ou se a carga exceder a capacidade da máquina, a aplicação inteira pode ficar indisponível. A Replicação MySQL resolve esse problema criando redundância de dados. Além disso, permite o escalonamento horizontal de leituras, ao distribuir consultas SELECT entre vários servidores réplicas, e oferece uma base sólida para estratégias de backup sem impacto na operação (backup na réplica, por exemplo).
Esta aula assume que você já concluiu as aulas anteriores do curso e possui conhecimentos sólidos de instalação e administração do MySQL 8.0, incluindo gerenciamento de usuários, configuração do arquivo my.cnf, uso do systemctl e noções de variáveis de sistema. Você também deve ter acesso a pelo menos duas máquinas (físicas ou virtuais) com sistema operacional Linux — Ubuntu/Debian ou CentOS/RHEL/Rocky Linux — e conectividade de rede entre elas. Caso ainda não tenha esse ambiente, recomendamos revisar as aulas anteriores antes de prosseguir.
Ao final desta aula, você será capaz de configurar uma replicação master-slave completa, com autenticação correta, binlogs ativos, GTIDs habilitados e verificação de integridade; configurar um cluster de Group Replication com três nós; diagnosticar e resolver os erros mais comuns que afetam a replicação; e aplicar boas práticas de monitoramento e manutenção. Terá, portanto, autonomia para implementar Replicação MySQL em ambientes reais de produção, como fazemos na JRT Technology Solutions ao projetar soluções de infraestrutura de alto desempenho e segurança da informação.
O que você vai aprender nesta aula
Esta aula foi cuidadosamente estruturada para que você atinja todos os objetivos a seguir. Cada tópico foi pensado para construir o conhecimento de forma progressiva, da teoria fundamental até a aplicação prática completa. Ao final, verifique se você consegue executar todos os itens sem consultar o material — esse é o verdadeiro teste de domínio.
- Compreender os fundamentos da Replicação MySQL: binlog, GTID, threads de replicação e formatos de logging;
- Diferenciar os modelos de replicação assíncrona e síncrona: master-slave vs. Group Replication, com seus prós e contras;
- Preparar o ambiente com MySQL 8.0 em Ubuntu/Debian e CentOS/RHEL/Rocky Linux, incluindo instalação e configuração básica de rede;
- Configurar a replicação master-slave passo a passo, desde a criação do usuário de replicação até a inicialização da réplica e a validação completa do fluxo;
- Habilitar e configurar GTIDs para replicação mais resiliente e simplificada em casos de failover;
- Implementar a Group Replication em um cluster de três nós, com eleição automática de primary e tolerância a falhas;
- Verificar e testar a replicação com comandos de diagnóstico, interpretando as saídas corretamente;
- Resolver erros recorrentes de replicação, incluindo problemas de server-id, autenticação, binlog purgado e inconsistências de GTID;
- Aplicar boas práticas de monitoramento, backup e failover em ambientes replicados de produção.
Pré-requisitos e Ambiente
Antes de iniciar esta aula, você precisa garantir que todo o ambiente esteja pronto. Como esta é uma aula avançada, assumimos que você já sabe instalar o MySQL 8.0 e possui noções de administração básica do sistema operacional. No entanto, para facilitar a padronização do laboratório, vamos apresentar rapidamente os comandos de instalação para as duas principais famílias de distribuições Linux. Se o MySQL já estiver instalado em suas máquinas, você pode pular esta parte e ir diretamente para a seção de configuração.
Para o laboratório desta aula, recomendamos a seguinte topologia mínima: três servidores Linux com MySQL 8.0 instalado, interconectados por uma rede local com baixa latência. Os nomes e IPs que usaremos nos exemplos são: db-master (192.168.1.10), db-slave-01 (192.168.1.20) e db-node-03 (192.168.1.30). Se você estiver trabalhando com máquinas virtuais, configure uma rede interna entre elas, desative o firewall para as portas 3306 e 33061 (ou crie regras de permissão) e sincronize os relógios com NTP. Caso esteja usando apenas duas máquinas para a replicação master-slave, ignore o terceiro nó até a seção de Group Replication.
Para instalar o MySQL 8.0 em Ubuntu ou Debian, execute os seguintes comandos com privilégios de superusuário. Primeiro, atualize os repositórios e instale o pacote mysql-server. Depois, execute o script de segurança mysql_secure_installation para definir a senha do root, remover usuários anônimos e desativar o login remoto do root, se necessário.
# Atualiza a lista de pacotes e instala o MySQL Server 8.0
sudo apt update
sudo apt install -y mysql-server
# Executa o assistente de segurança inicial (defina senha forte para o root)
sudo mysql_secure_installation
# Verifica o status do serviço
sudo systemctl status mysql● mysql.service - MySQL Community Server
Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2026-09-01 08:00:00 UTC; 35s ago
Main PID: 1024 (mysqld)
Tasks: 28 (limit: 4915)
Memory: 356.5M
CGroup: /system.slice/mysql.service
└─1024 /usr/sbin/mysqldPara CentOS, RHEL ou Rocky Linux, o processo é semelhante, mas o gerenciador de pacotes é o dnf (ou yum em versões mais antigas). Após a instalação, é necessário iniciar e habilitar o serviço para que ele inicie automaticamente no boot.
# Instala o MySQL Server 8.0 a partir dos repositórios oficiais do MySQL
sudo dnf install -y https://dev.mysql.com/get/mysql80-community-release-el8-3.noarch.rpm
sudo dnf module disable mysql -y
sudo dnf install -y mysql-community-server
# Inicia o serviço e o habilita no boot
sudo systemctl start mysqld
sudo systemctl enable mysqld
# Obtém a senha temporária do root gerada automaticamente
sudo grep 'temporary password' /var/log/mysqld.log
# Executa o assistente de segurança para alterar a senha e remover usuários anônimos
sudo mysql_secure_installation
# Verifica o status
sudo systemctl status mysqld● mysqld.service - MySQL Server
Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2026-09-01 08:05:00 UTC; 10s ago
Main PID: 1180 (mysqld)
Tasks: 28 (limit: 4915)
Memory: 360.1M
CGroup: /system.slice/mysqld.service
└─1180 /usr/sbin/mysqldAlém do MySQL, verifique se o hostname de cada servidor está corretamente configurado e se a resolução de nomes funciona entre eles. Isso é crítico para a Replicação MySQL, pois o servidor de origem e as réplicas precisam se comunicar pelo nome ou IP. Em nossos projetos na JRT Technology Solutions, padronizamos o uso de IPs fixos e a entrada /etc/hosts em todos os nós para evitar falhas de DNS em momentos de estresse. Em cada máquina, edite o arquivo /etc/hosts e adicione as seguintes linhas:
# Arquivo /etc/hosts — adicione em TODOS os servidores
192.168.1.10 db-master
192.168.1.20 db-slave-01
192.168.1.30 db-node-03Com o ambiente pronto, você pode seguir para a próxima seção, onde vamos estabelecer os fundamentos teóricos necessários para entender o que acontece internamente durante a replicação.
Fundamentos da Replicação MySQL: Binlog, Threads e GTIDs
A Replicação MySQL é baseada no registro binário de eventos, conhecido como binlog (Binary Log). O binlog é um arquivo criado pelo servidor MySQL que registra todas as mudanças de dados — como INSERT, UPDATE, DELETE e comandos DDL — na ordem em que foram executadas. Diferentemente dos logs de transação (redo log) usados para recuperação de crash do InnoDB, o binlog é um registro lógico de eventos, projetado especificamente para replicação e recuperação de dados em um ponto no tempo. Sem o binlog ativo, a replicação não pode funcionar.
Na replicação master-slave tradicional, o processo funciona em três etapas principais. Primeiro, o servidor master grava as transações no binlog. Em seguida, uma thread chamada dump thread no master lê os eventos do binlog e os envia para cada réplica conectada. Por fim, no lado da réplica, duas threads atuam: a I/O thread (ou receptor thread no MySQL 8.0) baixa os eventos do binlog do master e os grava localmente em arquivos chamados relay logs; e a SQL thread (ou applier thread) lê os relay logs e aplica as transações no banco de dados local. Esse modelo assíncrono permite que a réplica fique temporariamente atrasada em relação ao master, especialmente sob carga elevada ou em redes lentas.
O MySQL 8.0 introduziu o conceito de GTID (Global Transaction Identifier), que atribui um identificador único e global a cada transação commitada. Um GTID é formado pelo par server_uuid:transaction_id — por exemplo, 3f2c8a7d-11e4-8b6f-00ff7a5b9c0e:1. Com GTIDs habilitados, a replicação se torna mais resiliente e simplificada: a réplica sabe exatamente quais transações já foram aplicadas, o que facilita o failover automático e a identificação de inconsistências. Nos ambientes que implementamos na JRT Technology Solutions, o uso de GTID é padrão em todas as implantações de Replicação MySQL.
O formato do binlog também é um parâmetro importante. O MySQL suporta três modos: STATEMENT, ROW e MIXED. No modo ROW, recomendado e padrão a partir do MySQL 8.0, o binlog registra as mudanças linha a linha, o que garante consistência total entre master e réplica mesmo para transações complexas com funções não determinísticas como NOW(), UUID() ou RAND(). O modo STATEMENT registra apenas a instrução SQL, o que pode gerar divergências se a instrução depender de variáveis de ambiente ou retornar resultados diferentes em cada servidor. O modo MIXED combina os dois, usando declarações na maioria dos casos e linhas quando necessário. Para esta aula, utilizaremos o formato ROW, que é o mais seguro e recomendado para produção.
Compreender esses conceitos é essencial antes de passarmos à prática. Na próxima seção, colocaremos essa teoria em ação e configuraremos um ambiente de replicação master-slave completo, passo a passo, com todos os comandos e arquivos necessários.
Passo a Passo: Configurando a Replicação Master-Slave
Agora que você entende os fundamentos da Replicação MySQL, vamos implementar uma replicação master-slave no laboratório. O cenário consiste em dois servidores: db-master (192.168.1.10) e db-slave-01 (192.168.1.20). O objetivo é fazer com que todas as transações commitadas no master sejam automaticamente aplicadas na réplica. Vamos seguir uma sequência rigorosa de etapas, começando pela configuração do arquivo my.cnf em cada servidor.
O primeiro passo é editar o arquivo de configuração do MySQL no servidor master. Em sistemas Ubuntu/Debian, o arquivo fica em /etc/mysql/mysql.conf.d/mysqld.cnf; em CentOS/RHEL/Rocky, em /etc/my.cnf. Em ambos os casos, adicione ou modifique as linhas mostradas abaixo na seção [mysqld]. Cada parâmetro será explicado em detalhes.
# ==============================================================
# ARQUIVO DE CONFIGURAÇÃO DO MASTER — /etc/my.cnf ou /etc/mysql/mysql.conf.d/mysqld.cnf
# ==============================================================
[mysqld]
# Identificador único do servidor dentro da topologia de replicação
# NUNCA use o mesmo server-id em dois servidores que participam da replicação
server-id = 1
# Ativa o binary log, essencial para a replicação
# O nome "mysql-bin" é o prefixo dos arquivos gerados
log_bin = /var/lib/mysql/mysql-bin
# Define o formato do binlog como ROW (recomendado para consistência total)
binlog_format = ROW
# Ativa os GTIDs para replicação mais resiliente
gtid_mode = ON
enforce_gtid_consistency = ON
# Mantém 7 dias de binlog (segurança para réplicas atrasadas)
binlog_expire_logs_days = 7
# Define o banco de dados que será replicado (opcional; use se quiser replicar apenas alguns schemas)
# binlog_do_db = meu_banco
# Endereço de bind — ajuste conforme sua rede (0.0.0.0 aceita conexões de qualquer interface)
bind-address = 0.0.0.0
# Define o tamanho máximo do binlog antes da rotação (opcional)
max_binlog_size = 256M
# Ativa a sincronização do binlog a cada transação (mais seguro)
sync_binlog = 1Cada linha deste arquivo tem uma função clara. O parâmetro server-id é obrigatório e deve ser único para cada servidor na topologia: sem ele, o MySQL não participa da replicação. O log_bin ativa o binary log e define o caminho dos arquivos; sem isso, o servidor não pode atuar como master. O binlog_format define o formato dos eventos registrados — usamos ROW para máxima consistência. As opções gtid_mode e enforce_gtid_consistency habilitam o GTID, exigindo que todas as transações sejam consistentes com o modelo. O binlog_expire_logs_days evita que os arquivos de binlog cresçam indefinidamente. O bind-address define em qual interface o MySQL escuta — 0.0.0.0 permite conexões remotas. Por fim, sync_binlog força a gravação do binlog em disco a cada transação, evitando perda de eventos em caso de falha de energia, ao custo de um pequeno overhead de I/O.
Agora, no servidor slave (réplica), edite o arquivo de configuração correspondente e adicione os seguintes parâmetros. Note que o server-id deve ser diferente (neste caso, 2), e o binlog também deve ser ativado, pois a réplica pode, futuramente, atuar como master para outra réplica (replicação em cadeia) ou em caso de promoção durante um failover.
# ==============================================================
# ARQUIVO DE CONFIGURAÇÃO DA RÉPLICA — /etc/my.cnf ou /etc/mysql/mysql.conf.d/mysqld.cnf
# ==============================================================
[mysqld]
# Identificador único — use um valor diferente do master e de qualquer outra réplica
server-id = 2
# Ativa o binary log também na réplica (necessário para failover e replicação em cadeia)
log_bin = /var/lib/mysql/mysql-bin
# Formato ROW para consistência
binlog_format = ROW
# Ativa GTIDs na réplica
gtid_mode = ON
enforce_gtid_consistency = ON
# Dias para expirar binlog
binlog_expire_logs_days = 7
# Ativa a aplicação multicliente da replicação (opcional, mas recomendado para réplicas sob carga)
# replica_parallel_workers = 4 (disponível no MySQL 8.0)
slave_parallel_workers = 4
# Endereço de bind
bind-address = 0.0.0.0
# Sincronização do binlog
sync_binlog = 1
# Garante que a réplica guarde o binlog das transações aplicadas (para failover)
log_slave_updates = ONO parâmetro slave_parallel_workers (ou replica_parallel_workers em versões mais recentes) permite que a réplica aplique transações em paralelo, reduzindo o atraso de replicação sob carga elevada. O log_slave_updates é fundamental se você pretende usar esta réplica como master de outras réplicas — ele instrui o servidor a gravar no seu próprio binlog as transações recebidas via replicação. Isso é essencial para topologias de replicação em cadeia ou para failover manual, pois garante que o binlog da réplica contenha todas as transações do master.
Após editar os arquivos, reinicie o serviço do MySQL em ambos os servidores para que as novas configurações entrem em vigor. Em sistemas com systemd, utilize:
# No master e na réplica (execute separadamente em cada servidor)
sudo systemctl restart mysql # Ubuntu/Debian
# ou
sudo systemctl restart mysqld # CentOS/RHEL/Rocky
# Verifique se o serviço subiu sem erros
sudo systemctl status mysql # ou mysqld● mysql.service - MySQL Community Server
Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2026-09-01 09:10:00 UTC; 8s ago
Main PID: 2350 (mysqld)
Tasks: 28 (limit: 4915)
Memory: 340.2M
CGroup: /system.slice/mysql.service
└─2350 /usr/sbin/mysqldCom os servidores reiniciados e as configurações aplicadas, o próximo passo é criar o usuário de replicação no servidor master. Esse usuário será utilizado pela réplica para se autenticar e baixar os eventos do binlog. Conecte-se ao MySQL como root no master e execute os comandos SQL a seguir. Substitua a senha "SenhaReplicacaoSegura#2026!" por uma senha forte de sua escolha.
-- Conecte-se ao MySQL no servidor master
mysql -u root -p
-- Cria o usuário de replicação com privilégio mínimo necessário
CREATE USER 'replicador'@'%' IDENTIFIED BY 'SenhaReplicacaoSegura#2026!';
-- Concede o privilégio REPLICATION SLAVE (ou REPLICATION REPLICA no MySQL 8.0)
GRANT REPLICATION SLAVE ON *.* TO 'replicador'@'%';
-- Aplica as mudanças de privilégios
FLUSH PRIVILEGES;
-- Verifica a criação do usuário
SELECT user, host FROM mysql.user WHERE user = 'replicador';+------------+------+
| user | host |
+------------+------+
| replicador | % |
+------------+------+
1 row in set (0.00 sec)O comando CREATE USER cria a conta replicador com acesso a partir de qualquer host (%). Em ambientes mais restritivos, você pode substituir % pelo IP específico da réplica (por exemplo, 'replicador'@'192.168.1.20') para reduzir a superfície de ataque. O GRANT REPLICATION SLAVE concede o privilégio mínimo necessário para a replicação — o usuário só pode ler binlogs, não tem acesso direto a dados. O FLUSH PRIVILEGES recarrega a tabela de privilégios em memória, aplicando as mudanças imediatamente.
Agora, precisamos obter as coordenadas atuais do binlog no master. Essas coordenadas consistem no nome do arquivo de binlog atual e na posição (offset) onde a próxima transação será gravada. A réplica usará essas informações para saber a partir de onde iniciar a replicação. Se você estiver utilizando GTIDs (como configuramos), o MySQL pode iniciar a replicação automaticamente a partir do conjunto de GTIDs já executados no master, sem a necessidade de especificar manualmente o arquivo e a posição — mas é importante conhecer ambos os métodos.
Para obter as coordenadas do binlog no master, execute:
-- No master, execute:
SHOW MASTER STATUS;+------------------+----------+--------------+------------------+------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+------------------------------------------+
| mysql-bin.000001 | 856 | | | 3f2c8a7d-11e4-8b6f-00ff7a5b9c0e:1 |
+------------------+----------+--------------+------------------+------------------------------------------+
1 row in set (0.00 sec)Anote o nome do arquivo (mysql-bin.000001) e a posição (856). Com GTIDs habilitados, o conjunto Executed_Gtid_Set também é exibido, mostrando quais transações já foram aplicadas no master. Na configuração da réplica, usaremos o GTID, que é mais robusto para failover.
O próximo passo é conectar-se à réplica e configurar a replicação apontando para o master. No MySQL 8.0, os comandos CHANGE MASTER TO foram substituídos por CHANGE REPLICATION SOURCE TO, embora ambas as sintaxes ainda funcionem por compatibilidade. Vamos utilizar a nova nomenclatura, recomendada pela Oracle.
-- Conecte-se ao MySQL na réplica (db-slave-01)
mysql -u root -p
-- Pausa a replicação antes de alterar a configuração (boa prática)
STOP REPLICA;
-- Configura a fonte da replicação usando GTID
CHANGE REPLICATION SOURCE TO
SOURCE_HOST = '192.168.1.10',
SOURCE_USER = 'replicador',
SOURCE_PASSWORD = 'SenhaReplicacaoSegura#2026!',
SOURCE_AUTO_POSITION = 1;
-- Inicia a replicação
START REPLICA;
-- Verifica o status da replicação
SHOW REPLICA STATUS\G*************************** 1. row ***************************
Replica_IO_State: Waiting for source to send event
Source_Host: 192.168.1.10
Source_User: replicador
Source_Port: 3306
Connect_Retry: 60
Source_Log_File: mysql-bin.000001
Read_Source_Log_Pos: 856
Relay_Log_File: db-slave-01-relay-bin.000002
Relay_Log_Pos: 1056
Relay_Source_Log_File: mysql-bin.000001
Replica_IO_Running: Yes
Replica_SQL_Running: Yes
Exec_Source_Log_Pos: 856
Relay_Log_Space: 1256
Until_Condition: None
Source_Server_Id: 1
Source_UUID: 3f2c8a7d-11e4-8b6f-00ff7a5b9c0e
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: 10
Source_UUID: 3f2c8a7d-11e4-8b6f-00ff7a5b9c0e
Source_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Source_SSL_Allowed: No
Source_SSL_CA_File:
Source_SSL_CA_Path:
Source_SSL_Cert_File:
Source_SSL_Cipher:
Source_SSL_Key:
Source_SSL_Verify_Server_Cert: No
Replica_IO_Running_State: Waiting for source to send event
Replica_SQL_Running_State: Replica has read all relay log; waiting for more updates
Retrieved_Gtid_Set: 3f2c8a7d-11e4-8b6f-00ff7a5b9c0e:1
Executed_Gtid_Set: 3f2c8a7d-11e4-8b6f-00ff7a5b9c0e:1
Auto_Position: 1
Replicate_Rewrite_Db:
Channel_Name:
Source_TLS_Version:
Source_public_key_path:
Get_Source_public_key: 0
Network_Namespace:A saída do SHOW REPLICA STATUS é densa, mas os campos críticos são Replica_IO_Running: Yes e Replica_SQL_Running: Yes. Ambas as threads da réplica estão em execução, o que indica que a replicação está funcional. O campo Replica_IO_State: Waiting for source to send event mostra que a réplica está aguardando novos eventos do master. O Source_Host confirma o endereço do master, e Source_User o usuário de replicação. O Executed_Gtid_Set e o Retrieved_Gtid_Set devem estar idênticos ao Executed_Gtid_Set do master, indicando sincronização total.
Para testar a replicação de forma prática, crie um banco de dados e uma tabela no master, insira alguns registros e verifique se eles aparecem na réplica. Execute os comandos abaixo no servidor master:
-- No master, execute:
CREATE DATABASE IF NOT EXISTS curso_replicacao;
USE curso_replicacao;
CREATE TABLE clientes (
id INT AUTO_INCREMENT PRIMARY KEY,
nome VARCHAR(100) NOT NULL,
email VARCHAR(100) UNIQUE,
criado_em TIMESTAMP DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB;
INSERT INTO clientes (nome, email) VALUES
('Carlos Silva', 'carlos.silva@email.com'),
('Maria Souza', 'maria.souza@email.com'),
('João Pereira', 'joao.pereira@email.com');
-- Verifica os dados no master
SELECT * FROM clientes;+----+----------------+---------------------------+---------------------+
| id | nome | email | criado_em |
+----+----------------+---------------------------+---------------------+
| 1 | Carlos Silva | carlos.silva@email.com | 2026-09-01 09:15:00 |
| 2 | Maria Souza | maria.souza@email.com | 2026-09-01 09:15:00 |
| 3 | João Pereira | joao.pereira@email.com | 2026-09-01 09:15:00 |
+----+----------------+---------------------------+---------------------+
3 rows in set (0.01 sec)Agora, na réplica, consulte a mesma tabela para confirmar que os dados foram replicados automaticamente:
-- Na réplica, execute:
USE curso_replicacao;
SELECT * FROM clientes;+----+----------------+---------------------------+---------------------+
| id | nome | email | criado_em |
+----+----------------+---------------------------+---------------------+
| 1 | Carlos Silva | carlos.silva@email.com | 2026-09-01 09:15:01 |
| 2 | Maria Souza | maria.souza@email.com | 2026-09-01 09:15:01 |
| 3 | João Pereira | joao.pereira@email.com | 2026-09-01 09:15:01 |
+----+----------------+---------------------------+---------------------+
3 rows in set (0.00 sec)Se você chegou até aqui e os dados estão idênticos, parabéns! A replicação master-slave está funcionando corretamente. Na próxima seção, detalharemos a configuração avançada e as verificações sistemáticas para garantir que o ambiente esteja íntegro e pronto para produção.
Configuração Detalhada e Parâmetros Avançados da Replicação MySQL
Além dos parâmetros básicos que configuramos, a Replicação MySQL oferece uma série de ajustes avançados que podem melhorar o desempenho, a segurança e a resiliência do ambiente. Nesta seção, vamos explorar esses parâmetros e mostrar o conteúdo completo de um arquivo de configuração de produção que utilizamos como referência em nossos projetos na JRT Technology Solutions. Cada opção será explicada em detalhes para que você entenda o impacto de cada escolha.
Um dos ajustes mais importantes em réplicas sob carga intensa é a replicação paralela. No MySQL 8.0, a réplica pode aplicar transações em múltiplas threads simultâneas, desde que as transações não escrevam nas mesmas linhas (detecção de conflito baseada em viés de commit). Para ativar esse recurso, defina os parâmetros replica_parallel_workers (número de threads) e replica_parallel_type como DATABASE ou LOGICAL_CLOCK. O modo LOGICAL_CLOCK é mais eficiente, permitindo paralelismo mesmo dentro do mesmo banco de dados, desde que as transações sejam independentes. Em cargas de leitura mistas com muitas escritas pequenas, isso pode reduzir drasticamente o lag de replicação.
Outro conjunto de parâmetros controla a segurança e a integridade. O sync_binlog que configuramos como 1 garante que cada evento do binlog seja gravado em disco antes da confirmação da transação. O innodb_flush_log_at_trx_commit tem efeito semelhante para o log de transações do InnoDB: o valor 1 é o mais seguro, pois força a gravação do redo log a cada commit. Em réplicas, muitos administradores relaxam esses parâmetros para 0 ou 2 para ganhar desempenho, aceitando uma pequena janela de perda em caso de crash — mas isso deve ser avaliado com cuidado. Em nossos ambientes de produção na JRT Technology Solutions, mantemos os valores conservadores no master e toleramos alguma flexibilidade nas réplicas apenas após análise de risco.
Abaixo, apresentamos um arquivo de configuração completo para o master, com parâmetros avançados comentados. Este arquivo pode ser usado como referência para um ambiente de produção real. Lembre-se de substituir os valores conforme sua topologia.
# ==============================================================
# ARQUIVO DE CONFIGURAÇÃO COMPLETO DO MASTER — PRODUÇÃO
# MySQL 8.0 — Replicação MySQL master-slave
# ==============================================================
[mysqld]
# Identificação do servidor (obrigatório e único)
server-id = 1
# Caminho e prefixo dos arquivos de binary log
log_bin = /var/lib/mysql/mysql-bin
# Formato ROW para máxima consistência
binlog_format = ROW
# Ativa GTID
gtid_mode = ON
enforce_gtid_consistency = ON
# Expiração dos binlogs (7 dias)
binlog_expire_logs_days = 7
# Tamanho máximo do binlog antes da rotação
max_binlog_size = 256M
# Sincroniza binlog a cada transação (máxima segurança)
sync_binlog = 1
# Sincroniza redo log do InnoDB a cada commit
innodb_flush_log_at_trx_commit = 1
# Define o endereço de bind (comente para aceitar todas as interfaces)
bind-address = 0.0.0.0
# Define o charset padrão e collation
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
# Ajustes de InnoDB para desempenho
innodb_buffer_pool_size = 2G
innodb_log_file_size = 512M
innodb_flush_method = O_DIRECT
# Ativa o log de erros
log_error = /var/log/mysql/error.log
# Ativa o log de consultas lentas (útil para diagnóstico)
slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 2
# Define o tamanho máximo de pacote para evitar erros com blobs grandes
max_allowed_packet = 256M
# Ativa a compressão de binlog (economiza banda em links de replicação)
# binlog_transaction_compression = ON
# binlog_transaction_compression_level_zstd = 3Note que os parâmetros avançados como innodb_buffer_pool_size, innodb_log_file_size e innodb_flush_method são específicos do InnoDB e afetam o desempenho geral do servidor, não apenas a replicação. O tamanho do buffer pool deve ser ajustado de acordo com a memória disponível da máquina — uma regra prática é alocar entre 50% e 70% da RAM para o buffer pool em servidores dedicados ao MySQL. O innodb_flush_method como O_DIRECT evita o double buffering e melhora a performance de I/O em sistemas Linux. O parâmetro binlog_transaction_compression está comentado, mas pode ser ativado para economizar largura de banda em links de replicação entre data centers — algo muito útil em arquiteturas distribuídas.
Para a réplica, o arquivo de configuração é semelhante, com a adição de parâmetros específicos para a replicação paralela e o registro de atualizações. Segue o conteúdo completo comentado:
# ==============================================================
# ARQUIVO DE CONFIGURAÇÃO COMPLETO DA RÉPLICA — PRODUÇÃO
# MySQL 8.0 — Replicação MySQL master-slave
# ==============================================================
[mysqld]
# Identificação do servidor (diferente do master)
server-id = 2
# Ativa binlog na réplica (necessário para failover)
log_bin = /var/lib/mysql/mysql-bin
# Formato ROW
binlog_format = ROW
# Ativa GTID
gtid_mode = ON
enforce_gtid_consistency = ON
# Expiração dos binlogs
binlog_expire_logs_days = 7
# Registra no binlog da réplica as transações recebidas (failover)
log_slave_updates = ON
# Sincronização de binlog
sync_binlog = 1
# Parâmetros de replicação paralela (reduz lag)
replica_parallel_workers = 4
replica_parallel_type = LOGICAL_CLOCK
# Endereço de bind
bind-address = 0.0.0.0
# Charset padrão
character-set-server = utf8mb4
collation-server = utf
Quer aprender na prática com especialistas?
A JRT Technology Solutions oferece treinamentos e implementação de MySQL para equipes corporativas.
