O mundo de MySQL & MariaDB

Guia de Replicação MySQL: Configuração, Tipos e Solução de Problemas para Alta Disponibilidade

Aplicações / Outros
目次

1. O que é Replicação MySQL? Visão geral e casos de uso

A Replicação MySQL é um recurso que sincroniza uma cópia de um banco de dados para outro servidor em tempo real. Isso aumenta a redundância e o desempenho do banco de dados. A seguir, explicamos em detalhes onde a Replicação MySQL é utilizada e como ela funciona.

Visão geral da Replicação MySQL

A Replicação MySQL consiste em um servidor mestre e um ou mais servidores escravos, compartilhando o conteúdo do banco de dados entre vários servidores. Especificamente, o servidor mestre registra as atualizações no log binário, e o servidor escravo lê e aplica essas atualizações para permanecer sincronizado. Isso permite que os serviços continuem funcionando mesmo se o servidor mestre falhar, ao mudar para um servidor escravo.

Casos de uso da Replicação MySQL

A Replicação MySQL é amplamente utilizada nos seguintes cenários:

  • Alta disponibilidade : Minimiza o tempo de inatividade ao mudar para um servidor escravo em caso de falha.
  • Balanceamento de carga : Distribui consultas somente de leitura para servidores escravos, reduzindo a carga no mestre.
  • Proteção de dados e backup : Como a replicação copia os dados em tempo real, ela também pode servir como solução de backup.

Tipos de replicação

A Replicação MySQL possui os seguintes tipos, dependendo de como os dados são sincronizados:

  • Replicação assíncrona : O mestre não aguarda a confirmação do escravo de que recebeu as atualizações, permitindo respostas mais rápidas. Contudo, alguns dados podem não chegar ao escravo se ocorrer uma falha.
  • Replicação semi‑síncrona : O mestre aguarda até que pelo menos um escravo confirme o recebimento dos dados antes de prosseguir. Isso oferece maior confiabilidade, mas pode ser um pouco mais lento.

Na próxima seção, explicaremos os conceitos básicos da Replicação MySQL, incluindo logs binários e GTIDs.

2. Conceitos básicos da Replicação MySQL

Para entender a Replicação MySQL, é essencial conhecer o papel do log binário e do GTID (Global Transaction ID), que garantem a replicação precisa dos dados.

Papéis de mestre e escravo

Na Replicação MySQL, o servidor mestre e o servidor escravo têm papéis distintos. O mestre registra as atualizações no log binário e as distribui para os escravos. O servidor escravo aplica esses logs para atualizar seus dados, mantendo o mesmo estado do mestre.

Log binário e log de retransmissão (Relay Log)

A Replicação MySQL depende de dois logs principais:

  1. Log binário
  • O log binário registra as alterações de dados (INSERT, UPDATE, DELETE, etc.) no servidor mestre. Isso garante que o escravo possa manter o mesmo estado do mestre.
  1. Log de retransmissão (Relay Log)
  • O relay log é armazenado no servidor escravo, contendo o log binário recebido do mestre. A thread SQL do escravo executa esse relay log sequencialmente para aplicar as mudanças.

O que é GTID (Global Transaction ID)?

O GTID atribui um ID exclusivo a cada transação, assegurando consistência entre múltiplos escravos. Com GTID, o rastreamento da posição do log binário torna‑se desnecessário, e apenas as transações não aplicadas são reaplicadas automaticamente, simplificando o gerenciamento.

Vantagens do GTID

  • Identificação única : Cada transação possui um GTID exclusivo, deixando claro quais transações já foram aplicadas.
  • Recuperação fácil : Após uma reinicialização, apenas as transações não aplicadas são reaplicadas automaticamente.
  • Gerenciamento eficiente : O GTID simplifica a administração da replicação em ambientes grandes com vários escravos.

Para habilitar o GTID, defina gtid_mode=ON e enforce_gtid_consistency=ON tanto no mestre quanto nos escravos. Isso ativa a replicação baseada em GTID.

Na próxima seção, abordaremos a configuração passo a passo da Replicação MySQL.

3. Passos para configurar a Replicação MySQL

Esta seção explica como configurar a Replicação MySQL passo a passo. Seguindo estas instruções, você pode montar um ambiente básico mestre‑escravo e alcançar a sincronização de dados em tempo real.

Configuração do servidor mestre

Primeiro, edite o arquivo de configuração do servidor mestre (geralmente my.cnf ou my.ini) para habilitar o log binário e atribuir um ID ao servidor.

  1. Editar o arquivo de configuração
  • Adicione as seguintes configurações à seção [mysqld] e defina um ID de servidor exclusivo (por exemplo, 1).
    [mysqld]
server-id=1
log-bin=mysql-bin
  • server-id deve ser exclusivo por servidor. log-bin habilita o registro binário.
  1. Criar um Usuário de Replicação
  • Crie um usuário de replicação no servidor master e conceda os privilégios necessários.
    CREATE USER 'repl'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;
  • Este usuário é necessário para que o slave acesse os dados do master.
  1. Verificar o Status do Master
  • Verifique o arquivo de log binário atual e a posição, que serão necessários para a configuração do slave.
    SHOW MASTER STATUS;
  • Os valores File e Position mostrados serão usados ao configurar o slave.

Configuração do Servidor Slave

Em seguida, edite o arquivo de configuração do servidor slave para definir um ID de servidor exclusivo e especificar as informações do master.

  1. Editar o Arquivo de Configuração
  • Atribua um server-id exclusivo (por exemplo, 2) ao servidor slave. O ID do servidor deve ser diferente do do master.
    [mysqld]
server-id=2
  • Também é comum habilitar read_only=ON para evitar gravações não intencionais no slave.
  1. Configurar as Informações do Master no Slave
  • Execute o comando a seguir no servidor slave, especificando o host do master, usuário, arquivo de log binário e posição do log.
    CHANGE MASTER TO
    MASTER_HOST='master_host',
    MASTER_USER='repl',
    MASTER_PASSWORD='password',
    MASTER_LOG_FILE='mysql-bin.000001',
    MASTER_LOG_POS=123;
  • Use os valores MASTER_LOG_FILE e MASTER_LOG_POS obtidos da saída do SHOW MASTER STATUS do master.
  1. Iniciar a Replicação
  • Execute o comando a seguir no servidor slave para iniciar a replicação.
    START SLAVE;

Verificar o Status da Replicação

Verifique se a replicação entre master e slave está funcionando corretamente.

  • Verificar o Status do Master
    SHOW MASTER STATUS;
  • Verificar o Status do Slave
    SHOW SLAVE STATUSG;
  • Se ambos Slave_IO_Running e Slave_SQL_Running exibirem Yes, a replicação está funcionando normalmente.

Na próxima seção, exploraremos opções avançadas de configuração para a Replicação MySQL, incluindo diferenças entre replicação assíncrona e semi-síncrona e configurações baseadas em GTID.

4. Tipos e Aplicações de Replicação

A Replicação MySQL possui dois tipos principais dependendo do método de sincronização: replicação assíncrona e replicação semi-síncrona. Compreender as diferenças e quando usar cada uma ajuda a otimizar desempenho e confiabilidade. Esta seção também aborda as vantagens de usar GTID (Identificador Global de Transação) nas configurações de replicação.

Diferenças entre Replicação Assíncrona e Semi-Síncrona

1. Replicação Assíncrona

Na replicação assíncrona, o servidor master responde imediatamente ao cliente assim que uma transação é concluída, sem aguardar que o slave aplique a atualização. Isso garante excelente capacidade de resposta, tornando-a adequada para sistemas de balanceamento de carga. No entanto, se ocorrer uma falha, quaisquer transações ainda não aplicadas ao slave podem ser perdidas.

2. Replicação Semi-Síncrona

Na replicação semi-síncrona, o servidor master aguarda até que pelo menos um slave tenha recebido os dados antes de responder ao cliente. Isso melhora a consistência dos dados, mas aumenta o tempo de resposta da transação, pois o master deve esperar pela confirmação. A replicação semi-síncrona é ideal para ambientes onde consistência de dados e confiabilidade são priorizadas.

Replicação com GTID

GTID (Identificador Global de Transação) atribui um ID exclusivo a cada transação, garantindo consistência entre os servidores master e slave. Habilitar GTID simplifica o gerenciamento da replicação em comparação com a replicação tradicional baseada em posição de log binário.

Vantagens do GTID

  • Consistência de Dados Aprimorada : O GTID permite que o slave identifique automaticamente transações não aplicadas, garantindo consistência.
  • Gerenciamento Simplificado : O GTID elimina a necessidade de especificar manualmente posições de log binário, facilitando operações de failover e recuperação.

Configuração de Replicação GTID

Para habilitar o GTID, adicione as seguintes opções aos arquivos de configuração do master e do slave.

Configuração do Servidor Master

[mysqld]
server-id=1
log-bin=mysql-bin
gtid_mode=ON
enforce_gtid_consistency=ON

Configuração do Servidor Slave

[mysqld]
server-id=2
gtid_mode=ON
enforce_gtid_consistency=ON
read_only=ON

Uma vez que o GTID esteja habilitado, a configuração da replicação no slave com o comando CHANGE MASTER TO lidará automaticamente com a replicação baseada em GTID.

Na próxima seção, explicaremos práticas de manutenção e monitoramento da Replicação MySQL.

5. Manutenção e Monitoramento da Replicação

Para operar a Replicação MySQL de forma eficaz, manutenção e monitoramento regulares são essenciais. Esta seção explica como verificar o status da replicação e como lidar com erros comuns.

Como Verificar o Status da Replicação

Use os seguintes comandos para monitorar a sincronização entre os servidores master e slave.

Verificar Status do Master

No servidor master, execute SHOW MASTER STATUS para visualizar o arquivo de log binário atual e a posição. Isso mostra as atualizações mais recentes a serem enviadas para os slaves.

SHOW MASTER STATUS;

Campos principais incluem:

  • File : Nome do arquivo de log binário atual
  • Position : Posição atual dentro do log binário
  • Binlog_Do_DB e Binlog_Ignore_DB : Bancos de dados incluídos ou excluídos da replicação

Verificar Status do Slave

No servidor slave, execute SHOW SLAVE STATUS para verificar a saúde da replicação.

SHOW SLAVE STATUSG;

Campos importantes incluem:

  • Slave_IO_Running e Slave_SQL_Running : Ambos devem ser Yes se a replicação estiver funcionando normalmente.
  • Seconds_Behind_Master : Indica o quão atrasado o slave está em segundos. Idealmente, isso deve ser 0.

Solução de Problemas na Replicação

Problemas comuns na replicação incluem erros de conexão e inconsistências de dados. Abaixo estão casos de erro típicos e soluções.

1. Erros de Conexão

Se Slave_IO_Running for No, o slave não pode se conectar ao master. Soluções possíveis incluem:

  • Verificar Host/IP do Master : Certifique-se de que o endereço correto está definido.
  • Configurações de Firewall : Confirme que a porta 3306 está aberta e acessível.

2. Inconsistência de Dados

Se erros aparecerem em Last_Error, o master e o slave podem ter dados inconsistentes. Para resolver:

STOP SLAVE;
# Fix the data manually
START SLAVE;

Para inconsistências graves, ressincronize restaurando um backup completo do master.

3. Atraso na Replicação

O atraso na replicação pode resultar de limitações de hardware ou problemas de rede no slave. Atualizar o hardware ou otimizar consultas pode melhorar o desempenho.

A próxima seção explica problemas comuns de replicação e suas soluções detalhadas.

6. Problemas Comuns de Replicação e Soluções

Vários problemas podem surgir durante a Replicação MySQL. Esta seção detalha problemas frequentes e como resolvê-los.

1. Slave_IO_Running Parado

Problema: Se Slave_IO_Running for No, o slave não pode se conectar ao master.

Causas e Soluções:

  • Problemas de Rede : Verifique o firewall e a conectividade com o master.
  • Host/IP do Master Incorreto : Verifique a configuração CHANGE MASTER TO.
  • Privilégios de Usuário : Certifique-se de que o usuário de replicação tem as permissões corretas com GRANT REPLICATION SLAVE .

2. Inconsistência de Dados do Slave

Problema: Os dados diferem entre master e slave.

Causas e Soluções:

  • Correção Manual : Pare o slave, corrija os dados inconsistentes, depois reinicie a replicação. STOP SLAVE; # Corrigir dados START SLAVE;
  • Ressincronização Completa : Para discrepâncias graves, reimporte um backup do master.

3. Atraso na Replicação

Problema: Seconds_Behind_Master é maior que 0, significando que o slave está atrasado.

Causas e Soluções:

  • Limitações de Hardware : Atualize as especificações do servidor slave.
  • Otimização de Consultas : Melhore os índices e consultas para reduzir o tempo de processamento no slave.

4. Erros de Privilégios do Usuário de Replicação

Problema: Erros em Last_Error indicam privilégios insuficientes.

Solução:

  • Conceda Privilégios Corretos : Garanta direitos de replicação adequados. GRANT REPLICATION SLAVE ON *.* TO 'repl'@'slave_ip'; FLUSH PRIVILEGES;

5. Crescimento do Log Binário

Problema: Os logs binários do master crescem excessivamente, consumindo espaço em disco.

Solução:

  • Rotação de Logs : Use expire_logs_days para purgar automaticamente logs antigos. SET GLOBAL expire_logs_days = 7; # Purge logs older than 7 days

Ao entender e se preparar para esses problemas comuns, os administradores podem manter operações de replicação estáveis.

7. Conclusão

A Replicação do MySQL é um recurso essencial para garantir consistência de dados e confiabilidade do sistema. Este artigo cobriu os básicos da replicação, procedimentos de configuração, monitoramento e solução de problemas. Abaixo está um resumo dos pontos principais.

Pontos Principais

  1. Escolha o Tipo Certo de Replicação
  • A replicação assíncrona oferece velocidade e balanceamento de carga, enquanto a replicação semi-síncrona fornece maior confiabilidade. Escolha com base nos requisitos do sistema.
  1. Aproveite o GTID
  • O GTID simplifica a replicação removendo a necessidade de especificar posições de log binário, tornando-o valioso para ambientes grandes ou críticos.
  1. Monitore o Status Regularmente
  • Use SHOW MASTER STATUS e SHOW SLAVE STATUS frequentemente para detectar anomalias precocemente e minimizar riscos.
  1. Domine Habilidades de Solução de Problemas
  • Esteja familiarizado com o tratamento de problemas específicos de replicação, como erros de conexão, inconsistências e atrasos.
  1. Gerencie os Logs Binários
  • Previna problemas de uso de disco configurando expire_logs_days e rotacionando logs regularmente.

A Replicação do MySQL requer monitoramento e manutenção contínuos, não apenas configuração inicial. Ao verificar o status regularmente e ajustar configurações conforme necessário, você pode construir e manter um sistema de banco de dados altamente confiável.

Esperamos que este guia ajude você a entender e implementar a Replicação do MySQL de forma eficaz, garantindo operações suaves e estáveis.