Configurando o escravo MySQL

Visão geral

Este guia descreve passo a passo como configurar um servidor MySQL como escravo (replicação mestre-escravo) e garantir que a conexão ao mestre use SSL. “Escravo” refere-se ao nó que recebe e aplica as alterações do mestre automaticamente.

Importante: mantenha a ordem das operações (parar slave se necessário, importar snapshot, configurar CHANGE MASTER TO, iniciar slave) para evitar inconsistências.

1. Editar my.cnf no escravo

No servidor que será o escravo (server2), abra /etc/mysql/my.cnf e verifique as configurações na seção [mysqld]. As seguintes linhas são necessárias e o valor de server-id deve ser único (diferente do mestre):

vi /etc/mysql/my.cnf

[...]
server-id=2
master-connect-retry=60
replicate-do-db=exampledb
[...]

Nota: replicate-do-db limita a replicação apenas à base exampledb. Remova ou ajuste conforme sua topologia.

Reiniciar o serviço MySQL

Após salvar my.cnf, reinicie o serviço MySQL:

/etc/init.d/mysql restart

2. Criar a base de dados vazia no escravo

Antes de iniciar a replicação com um snapshot, crie uma base de dados vazia com o mesmo nome no escravo:

mysql -u root -p

CREATE DATABASE exampledb;  
quit;

Isso garante que a importação do snapshot tenha o banco de destino pronto.

3. Parar o slave e importar o dump

No server2, pare o processo de slave (se estiver rodando) e importe o arquivo snapshot.sql:

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

Substitua yourrootsqlpassword pelo password real de root do MySQL no escravo. O comando importa os dados sincronizados que você gerou a partir do mestre.

4. Configurar o escravo para apontar ao mestre

Conecte novamente ao MySQL no escravo:

mysql -u root -p

Execute o comando CHANGE MASTER TO no escravo, substituindo os valores de MASTER_LOG_FILE e MASTER_LOG_POS pelos obtidos em SHOW MASTER STATUS; no mestre. O exemplo abaixo também força o uso de SSL entre escravo e mestre:

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=106, 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';

Parâmetros importantes:

• MASTER_HOST: IP ou hostname do mestre (ex.: 192.168.0.100).
• MASTER_USER: usuário com privilégio REPLICATION SLAVE no mestre.
• MASTER_PASSWORD: senha desse usuário no mestre.
• MASTER_LOG_FILE e MASTER_LOG_POS: provenientes de SHOW MASTER STATUS; no mestre (arquivo e posição binlog).
• MASTER_SSL: habilita SSL (1 = true).
• MASTER_SSL_CA / MASTER_SSL_CERT / MASTER_SSL_KEY: caminhos dos certificados no escravo.

Se não quiser SSL, remova MASTER_SSL, MASTER_SSL_CA, MASTER_SSL_CERT e MASTER_SSL_KEY, mas esteja ciente dos riscos de segurança em redes não confiáveis.

5. Iniciar o slave e verificar status

Inicie a replicação no escravo:

START SLAVE;

Verifique o status:

SHOW SLAVE STATUS \G

É essencial que as chaves Slave_IO_Running e Slave_SQL_Running apareçam com o valor Yes. Se alguma estiver em No, a replicação não está funcionando corretamente — verifique os erros nos campos Last_IO_Error e Last_SQL_Error e os logs do sistema (/var/log/syslog).

Exemplo de saída esperada:

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: 106  
               Relay_Log_File: mysqld-relay-bin.000002  
                Relay_Log_Pos: 251  
        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: 106  
              Relay_Log_Space: 407  
              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  
Master_SSL_Verify_Server_Cert: No  
                Last_IO_Errno: 0  
                Last_IO_Error:  
               Last_SQL_Errno: 0  
               Last_SQL_Error:  
1 row in set (0.00 sec)    
  
mysql>

Em seguida, saia do shell MySQL:

quit;

6. Testar a replicação

Para testar, faça uma alteração simples na base exampledb no mestre (por ex., criar uma tabela de teste ou inserir uma linha) e verifique se a alteração aparece no escravo.

Exemplo mínimo:

• No mestre: INSERT INTO exampledb.tabela_teste (col) VALUES (‘replica_test’);
• No escravo: SELECT * FROM exampledb.tabela_teste; — a linha deve existir.

Se não houver replicação, reveja logs e permissões.

Dicas de segurança e operacional

• Use usuários com o mínimo de privilégios: conceda apenas REPLICATION SLAVE ao usuário de replicação.
• Proteja as senhas: evite colocá-las em scripts sem proteção; use arquivos de configuração com permissão restrita quando necessário.
• Certificados SSL: mantenha os arquivos de chave/certificados com permissão 600 e propriedade root.
• Backups: sempre gere um snapshot consistente (mysqldump –master-data ou LVM snapshot) antes de iniciar a replicação.

Checklist por função

• Administrador SGBD:

  • Verificar server-id único.
  • Confirmar usuário e privilégios de replicação no mestre.
  • Gerar e transferir snapshot consistente.
  • Configurar e testar certificados SSL.

• Operações/DevOps:

  • Garantir conectividade (firewall, portas 3306).
  • Reiniciar serviços conforme necessário.
  • Monitorar logs (/var/log/syslog, error.log).

• Desenvolvedor:

  • Testar cenários de escrita no mestre e leitura no escravo.
  • Validar que replicação não altera comportamento da aplicação.

Mini-metodologia: passos essenciais (resumido)

1. Preparar o mestre: garantir snapshot coerente e anotar MASTER_LOG_FILE/POS via SHOW MASTER STATUS;.
2. Configurar my.cnf no escravo (server-id e replicate-do-db opcional).
3. Criar base vazia no escravo e importar snapshot.
4. Executar CHANGE MASTER TO com parâmetros corretos.
5. START SLAVE; verificar SHOW SLAVE STATUS \G.
6. Testar inserções no mestre e confirmar no escravo.

Fluxo de decisão rápido (Mermaid)

flowchart TD
  A[Snapshot disponível?] -->|Não| B[Gerar snapshot consistente no mestre]
  A -->|Sim| C[Importar snapshot no escravo]
  C --> D[Executar CHANGE MASTER TO com logs corretos]
  D --> E[START SLAVE]
  E --> F{Slave_IO_Running & Slave_SQL_Running == Yes}
  F -->|Sim| G[Testar replicação]
  F -->|Não| H[Verificar erros: SHOW SLAVE STATUS, /var/log/syslog]

Problemas comuns e como diagnosticar

• Slave_IO_Running = No: problemas de rede, credenciais ou host mestre incorreto. Verifique Master_Host, conectividade e se o usuário de replicação existe no mestre.
• Slave_SQL_Running = No: erro durante aplicação de eventos (incompatibilidade de esquema, instruções conflitantes). Verifique Last_SQL_Error.
• Erros SSL: confirme caminhos e permissões de MASTER_SSL_CA, MASTER_SSL_CERT e MASTER_SSL_KEY; verifique se o certificado do servidor mestre é válido.
• Inconsistência de dados: se o snapshot não era consistente com a posição do binlog, pode haver divergência. Refaça o snapshot com –master-data.

Critérios de aceitação (Kритерии приёмки)

• Slave_IO_Running: Yes
• Slave_SQL_Running: Yes
• Seconds_Behind_Master: valor numérico estável (pode ser 0)
• As alterações feitas no mestre aparecem no escravo em testes funcionais

Caixa de fatos (sem números inventados)

• Um server-id deve ser único em toda a topologia de replicação.
• Replicação mestre-escravo pode ser síncrona ou quase síncrona dependendo da configuração; o método acima é assíncrono por padrão.

Testes/aceitação

• Teste de conexão: telnet MASTER_HOST 3306 (ou nc) a partir do escravo.
• Teste de aplicação: inserir e confirmar replicação de linhas simples.
• Teste de certificado: renovar certificados e verificar reconexão do slave.

Links

• MySQL: http://www.mysql.com/
• Debian: http://www.debian.org/

Resumo final

Seguindo estes passos você terá um escravo MySQL configurado para replicar uma base específica (exampledb) a partir do mestre, com conexão SSL. Verifique sempre os logs e as posições de binlog antes de iniciar a replicação para garantir consistência.

Importante: monitore a replicação regularmente e proteja credenciais e certificados no sistema.