Configurar escravo MySQL com SSL

Objetivo principal

Configurar um nó escravo MySQL que replique a base exampledb de um servidor mestre, usando conexão SSL entre mestre e escravo.

Variantes de busca relacionadas

replicação MySQL mestre-escravo
configurar slave MySQL com SSL
CHANGE MASTER TO exemplo
SHOW SLAVE STATUS interpretação

1 Pré-requisitos rápidos

Acesso root ao MySQL no servidor escravo e no mestre.
Snapshot SQL (snapshot.sql) exportado do mestre no ponto correto do binlog.
Certificados SSL instalados no escravo: ca-cert.pem, client-cert.pem, client-key.pem.
Usuário de replicação criado no mestre com privilégios REPLICATION SLAVE.
Porta 3306 acessível entre mestre e escravo (ou conforme sua configuração).

2 Passo a passo: configurar o escravo

Importante: execute cada comando com as credenciais corretas e substitua os valores de exemplo pelos retornados por SHOW MASTER STATUS; no servidor mestre.

2.1 Editar /etc/my.cnf no escravo

No servidor escravo (server2) abra o arquivo de configuração:

vi /etc/my.cnf

Edite a seção [mysqld] para incluir pelo menos as opções abaixo. O server-id deve ser único (diferente do mestre):

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1
ssl
server-id=2
master-connect-retry=60
replicate-do-db=exampledb

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

Nota importante: o valor de server-id deve ser único na topologia de replicação.

2.2 Reiniciar o MySQL no escravo

Depois de salvar /etc/my.cnf, reinicie o serviço MySQL:

/etc/init.d/mysqld restart

ou use o gerenciador de serviços da sua distribuição (systemctl restart mysqld) se aplicável.

2.3 Criar a base vazia no escravo

No escravo crie a base de dados vazia que receberá a replicação:

mysql -u root -p

No prompt MySQL:

CREATE DATABASE exampledb;
quit;

2.4 Parar o processo de slave (se já estiver rodando) e importar o snapshot

No escravo, pare o slave antes de carregar o snapshot e depois importe o dump SQL que você trouxe do mestre:

/usr/bin/mysqladmin --user=root --password=yourrootsqlpassword stop-slave
cd /tmp
mysql -u root -pyourrootsqlpassword exampledb < snapshot.sql

Em seguida, conecte ao MySQL novamente:

mysql -u root -p

2.5 Executar CHANGE MASTER TO com parâmetros SSL

No prompt MySQL do escravo, execute o comando abaixo substituindo os valores de MASTER_LOG_FILE e MASTER_LOG_POS pelos retornados por SHOW MASTER STATUS; no mestre. Ajuste MASTER_HOST, MASTER_USER e MASTER_PASSWORD conforme seu ambiente:

CHANGE MASTER TO MASTER_HOST='192.168.0.100', MASTER_USER='slave_user', MASTER_PASSWORD='slave_password', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=3096416, MASTER_SSL=1, MASTER_SSL_CA = '/etc/mysql/newcerts/ca-cert.pem', MASTER_SSL_CERT = '/etc/mysql/newcerts/client-cert.pem', MASTER_SSL_KEY = '/etc/mysql/newcerts/client-key.pem';

O que cada parâmetro significa:

MASTER_HOST: IP ou hostname do mestre.
MASTER_USER: usuário com privilégios de replicação no mestre.
MASTER_PASSWORD: senha desse usuário no mestre.
MASTER_LOG_FILE e MASTER_LOG_POS: arquivo e posição obtidos em SHOW MASTER STATUS; no mestre.
MASTER_SSL=1: ativa SSL para a conexão de replicação.
MASTER_SSL_CA / MASTER_SSL_CERT / MASTER_SSL_KEY: caminhos para os certificados no escravo.

2.6 Iniciar o slave e verificar status

Inicie o processo de replicação no escravo:

START SLAVE;

Verifique o status da replicação:

SHOW SLAVE STATUS \G

Você deve ver, entre outros campos, Slave_IO_Running: Yes e Slave_SQL_Running: Yes. Como está usando SSL, espere também valores nos campos Master_SSL_CA_File, Master_SSL_Cert e Master_SSL_Key.

Exemplo de saída esperada (apenas para referência):

mysql> SHOW SLAVE STATUS \G * 1. row * Slave_IO_State: Waiting for master to send event Master_Host: 192.168.0.100 Master_User: slave_user Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000001 Read_Master_Log_Pos: 3096416 Relay_Log_File: mysqld-relay-bin.000002 Relay_Log_Pos: 235 Relay_Master_Log_File: mysql-bin.000001 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: exampledb 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_Master_Log_Pos: 3096416 Relay_Log_Space: 235 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: Yes Master_SSL_CA_File: /etc/mysql/newcerts/ca-cert.pem Master_SSL_CA_Path: Master_SSL_Cert: /etc/mysql/newcerts/client-cert.pem Master_SSL_Cipher: Master_SSL_Key: /etc/mysql/newcerts/client-key.pem Seconds_Behind_Master: 0 1 row in set (0.00 sec)

Quando terminar, saia do shell MySQL:

quit;

Agora, toda alteração em exampledb no mestre será replicada automaticamente para exampledb no escravo. Teste a replicação com inserts/updates no mestre e confirme no escravo.

3 Verificações e critérios de aceitação

Slave_IO_Running = Yes
Slave_SQL_Running = Yes
MASTER_SSL_CA_File, MASTER_SSL_Cert e MASTER_SSL_Key não vazios
Seconds_Behind_Master próximo de 0 em cargas baixas
Dados de exampledb no escravo refletem as mudanças do mestre após teste

4 Checklist rápido por função

Administrador de banco: confirmar SHOW MASTER STATUS; no mestre e anotar File/Position.
Operações/Infra: garantir conectividade TCP 3306 e certificados SSL sincronizados.
Segurança: checar permissões dos arquivos de chave (chmod 600 para client-key.pem).
Backup: ter snapshot.sql e backup do datadir antes de alteração importante.

5 Playbook de resolução rápida (runbook)

Se Slave_IO_Running = No:
- Verifique conectividade para MASTER_HOST (ping, telnet 3306).
- Inspecione /var/log/syslog e /var/log/mysqld.log para mensagens de erro.
- Verifique usuário/senha e privilégios REPLICATION SLAVE no mestre.
Se Slave_SQL_Running = No:
- Verifique Last_Error e Last_Errno no SHOW SLAVE STATUS \G.
- Se for erro de sintaxe ou conflito de dados, considerar mysqlbinlog + aplicar manualmente ou ajustar replicação.
Erro SSL:
- Cheque caminhos de MASTERSSL* e permissões.
- Verifique se os certificados não expiraram e se o CA corresponde ao certificado do mestre.
Avançado: se o binlog do mestre não contiver a posição solicitada (arquivo removido/rotacionado), re-crie o dump do mestre e reconfigure o escravo a partir de um novo snapshot.

6 Alternativas e quando usar cada uma

Usar GTID-based replication (automatico failover e posições): preferível em topologias modernas; reescreve a forma de posicionamento (MASTER_AUTO_POSITION = 1).
rsync + mysqldump/stop + restart: útil para dados muito grandes quando um snapshot lógico é lento; exige downtime.
Replicação baseada em semisync: reduzir perda de dados em failover (síncrona parcial).

7 Segurança e boas práticas

Proteja as chaves: chmod 600 nas chaves privadas.
Use certificados emitidos por uma CA confiável interna.
Restrinja o usuário de replicação apenas aos privilégios necessários (REPLICATION SLAVE).
Monitore o estado de replicação com alertas (Slave_IO_Running/Slave_SQL_Running/Seconds_Behind_Master).

8 Testes e critérios de aceitação

Inserir uma linha na tabela de exampledb no mestre e confirmar a presença da linha no escravo em segundos.
Simular perda de conectividade: desconectar temporariamente o escravo e verificar que, após reconexão, ele retoma a replicação sem inconsistências.

9 Mental model (heurística)

Pense na replicação como dois fluxos: o IO thread lê o binlog do mestre (Slave_IO) e grava em relay logs; o SQL thread aplica esses relay logs localmente (Slave_SQL). Ambos precisam rodar.

10 Mini-glossário

Mestre: servidor MySQL que gera binlogs e fornece eventos para replicação.
Escravo: servidor que consome e aplica eventos do mestre.
Binlog: arquivo de log de transações do MySQL usado para replicação.

11 Recursos e links

MySQL: http://www.mysql.com/
CentOS: http://www.centos.org/

Resumo: siga os passos para editar /etc/my.cnf, reiniciar o serviço, importar o snapshot, executar CHANGE MASTER TO com parâmetros SSL, iniciar o slave e validar SHOW SLAVE STATUS. Use o playbook de resolução para diagnosticar falhas comuns.

Observação final: mantenha registros das posições de binlog ao gerar snapshots e automatize verificações periódicas do estado da replicação.

Configurar o servidor escravo MySQL