Replicação MySQL: Master-Slave e GTID para Alta Disponibilidade

O que é replicação MySQL e por que usar

Replicação MySQL move dados de um servidor (source/master) para um ou mais servidores (replicas/slaves) de forma assíncrona ou semissíncrona. Os casos de uso principais são:

• Alta disponibilidade: se o master cair, promove-se uma replica
• Read scaling: distribui queries de leitura entre múltiplas replicas
• Backups sem impacto: faz dump na replica, sem travar o master
• Análises e BI: queries analíticas pesadas rodando na replica, sem afetar OLTP

Configuração Básica Master-Slave

servidor master (my.cnf)

[mysqld]
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_format = ROW
binlog_row_image = FULL
expire_logs_days = 7
max_binlog_size = 100M
gtid_mode = ON
enforce_gtid_consistency = ON

servidor replica (my.cnf)

[mysqld]
server-id = 2
log_bin = /var/log/mysql/mysql-bin.log
relay_log = /var/log/mysql/mysql-relay-bin.log
read_only = ON
super_read_only = ON
gtid_mode = ON
enforce_gtid_consistency = ON

Configurando a replicação com GTID

-- No master: criar usuário de replicação
CREATE USER 'replicator'@'%' IDENTIFIED WITH mysql_native_password BY 'StrongPassword!1';
GRANT REPLICATION SLAVE ON *.* TO 'replicator'@'%';
FLUSH PRIVILEGES;

-- Na replica: configurar a fonte
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST = '10.0.1.10',
  SOURCE_USER = 'replicator',
  SOURCE_PASSWORD = 'StrongPassword!1',
  SOURCE_AUTO_POSITION = 1;

-- Iniciar a replicação
START REPLICA;

-- Verificar status
SHOW REPLICA STATUS\G

Usando GTID (Global Transaction Identifiers)

GTID é uma forma de identificar transações de forma global e única — elimina a necessidade de acompanhar posição de binlog manualmente, e simplifica o failover.

-- Verificar GTID executados no master
SELECT @@GLOBAL.gtid_executed;

-- Verificar se a replica está atualizada
SELECT GTID_SUBTRACT(
  (SELECT @@GLOBAL.gtid_executed FROM master_db),
  (SELECT @@GLOBAL.gtid_executed FROM replica_db)
) AS lag_transactions;

Monitorando o lag de replicação

O lag (Seconds_Behind_Source) é o indicador mais importante:

-- Na replica
SHOW REPLICA STATUS\G

-- Checar campos relevantes
-- Replica_IO_Running: Yes      ← thread de I/O ativa
-- Replica_SQL_Running: Yes     ← thread SQL ativa
-- Seconds_Behind_Source: 0    ← lag zero = atualizada

Monitoramento contínuo com Prometheus

# prometheus.yml snippet
- job_name: mysql_replica
  static_configs:
    - targets: ['replica-host:9104']  # mysqld_exporter

# Alertas relevantes
groups:
- name: mysql.replication
  rules:
  - alert: MysqlReplicationLag
    expr: mysql_slave_status_seconds_behind_master > 30
    for: 5m
    annotations:
      summary: "Replica lag {{ $value }}s — verificar"

  - alert: MysqlReplicationNotRunning
    expr: mysql_slave_status_slave_sql_running == 0
    for: 1m
    annotations:
      summary: "Thread SQL da replica parada — ação imediata"

Failover manual: promovendo uma replica

Quando o master cai, promover a replica mais atualizada:

-- 1. Identificar a replica mais avançada
SELECT @@GLOBAL.gtid_executed;  -- execute em todas as replicas

-- 2. Na replica eleita como novo master
STOP REPLICA;
RESET REPLICA ALL;

-- Remover read_only
SET GLOBAL read_only = OFF;
SET GLOBAL super_read_only = OFF;

-- 3. Redirecionar outras replicas para o novo master
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST = 'novo-master-ip',
  SOURCE_AUTO_POSITION = 1;
START REPLICA;

Failover automático com Orchestrator

Orchestrator é a ferramenta padrão de mercado para failover automático MySQL:

# Instalação
curl -s https://packagecloud.io/install/repositories/orchestrator/orchestrator/script.deb.sh | bash
apt install orchestrator

# Descobrir topologia
orchestrator -c discover -i master-host:3306

# Verificar topologia
orchestrator -c topology -i master-host

master:3306 (5.7.44-log)
  +- replica1:3306 [OK, 0s lag]
  +- replica2:3306 [OK, 0s lag]
  +- replica3:3306 [OK, 2s lag]

Com Orchestrator + hooks, o failover leva 15–30 segundos.

Replicação semissíncrona

Para aplicações que não toleram perda de dados no failover, configure replicação semissíncrona:

# master
plugin-load-add = semisync_master.so
rpl_semi_sync_master_enabled = 1
rpl_semi_sync_master_timeout = 3000  # 3s timeout antes de fallback

# replica
plugin-load-add = semisync_slave.so
rpl_semi_sync_slave_enabled = 1

Com semissíncrona, o master só confirma COMMIT após pelo menos uma replica receber o evento — garantindo zero data loss em failover.

Checklist de replicação saudável

• [ ] GTID habilitado em todos os servidores
• [ ] super_read_only = ON nas replicas
• [ ] Monitoramento de lag em Prometheus/Grafana com alertas
• [ ] Script de failover testado mensalmente
• [ ] Orchestrator ou MHA configurado para failover automático
• [ ] SSL na conexão de replicação
• [ ] Rotação automática de binlogs (7 dias max)
• [ ] Replica testada regularmente com um restore de backup