Practical MySQL & MariaDB

Replicação MySQL Explicada: Configuração, GTID, Monitoramento e Guia de Solução de Problemas

Avançado / Outros
目次

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

A replicação MySQL é um recurso que sincroniza cópias de um banco de dados para outros servidores em tempo real. Isso melhora a redundância e o desempenho do banco de dados. A seguir, explicamos em detalhes quando a replicação MySQL é usada e como ela funciona.

Visão geral da replicação MySQL

A replicação MySQL compartilha o conteúdo do banco de dados entre vários servidores usando um servidor mestre e um ou mais servidores escravos. Especificamente, as atualizações de dados registradas no log binário do servidor mestre são lidas e aplicadas pelos servidores escravos para manter os dados sincronizados. Isso permite a continuidade do serviço ao mudar para um servidor escravo caso o servidor mestre encontre uma falha.

Casos de uso da replicação MySQL

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

  • Alta disponibilidade : Em caso de falha, mudar para um servidor escravo minimiza o tempo de inatividade.
  • Balanceamento de carga : Consultas somente leitura podem ser distribuídas para servidores escravos, reduzindo a carga no servidor mestre.
  • Proteção de dados e backup : Como a replicação duplica os dados em tempo real, ela também pode servir como um mecanismo de backup.

Tipos de replicação

A replicação MySQL inclui os seguintes tipos com base no método de sincronização:

  • Replicação assíncrona : O mestre continua sem aguardar confirmação do escravo. Isso permite tempos de resposta mais rápidos, mas pode resultar em alguns dados não chegarem ao escravo durante uma falha.
  • Replicação semi-síncrona : O mestre aguarda confirmação de que os dados foram recebidos pelo escravo antes de prosseguir. Isso oferece maior confiabilidade que a replicação assíncrona, embora com tempos de resposta ligeiramente mais lentos.

A próxima seção explica os conceitos fundamentais da replicação MySQL, incluindo logs binários e GTID.

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

Para entender a replicação MySQL, é importante compreender os papéis do log binário e do GTID (Global Transaction ID), que desempenham papéis críticos no processo de replicação. Esses elementos formam a base para uma replicação de dados precisa.

Papéis do mestre e do escravo

Na replicação MySQL, o servidor mestre e o servidor escravo têm papéis distintos. O mestre registra as atualizações de dados no log binário e as envia ao escravo. O escravo aplica os logs recebidos para atualizar seus dados. Como resultado, o escravo mantém os mesmos dados que o mestre.

Log binário e log de retransmissão

A replicação MySQL depende dos dois logs a seguir:

  1. Log binário
  • O log binário registra as atualizações de dados (como INSERT, UPDATE e DELETE) no servidor mestre. Isso permite que o servidor escravo mantenha o mesmo estado de dados que o mestre.
  1. Log de retransmissão
  • O log de retransmissão armazena os eventos do log binário recebidos do mestre no servidor escravo. O thread SQL do escravo executa o log de retransmissão sequencialmente para aplicar as alterações de dados.

O que é GTID (Global Transaction ID)?

GTID é um mecanismo que atribui um ID único a cada transação, ajudando a manter a consistência entre vários escravos. Ao usar GTID, especificar posições do log binário torna-se desnecessário. Apenas as transações que ainda não foram obtidas do mestre são aplicadas automaticamente ao escravo, simplificando muito o gerenciamento.

Vantagens do GTID

  • Identificação única : Cada transação recebe um GTID único, identificando claramente quais transações foram aplicadas.
  • Recuperação mais fácil : Ao usar GTID, apenas as transações não aplicadas são reprocessadas após uma reinicialização do mestre ou do escravo.
  • Gerenciamento operacional eficiente : Mesmo em ambientes de grande escala com vários escravos, a consistência das transações pode ser mantida com gerenciamento simplificado.

Para usar GTID, as configurações gtid_mode=ON e enforce_gtid_consistency=ON são necessárias. Configurar essas opções tanto no mestre quanto no escravo habilita a replicação baseada em GTID.

A próxima seção explica os passos específicos para configurar a replicação MySQL.

3. Procedimento de Configuração da Replicação MySQL

Esta seção explica os passos necessários para configurar a replicação MySQL. Seguindo estes passos, você pode configurar uma estrutura básica mestre‑escravo e habilitar a sincronização de dados em tempo real.

Configurando o 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 definir o ID do servidor.

  1. Editar o Arquivo de Configuração
  • Adicione as seguintes configurações na seção [mysqld] e defina um ID de servidor único (por exemplo, 1).
    [mysqld]
server-id=1
log-bin=mysql-bin
  • O server-id deve ser um número único para cada servidor, e log-bin habilita o log binário.
  1. Criar um Usuário de Replicação
  • Crie um usuário de replicação dedicado no servidor mestre 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 servidor escravo acesse os dados do mestre.
  1. Verificar o Status do Mestre
  • Verifique o arquivo de log binário atual e a posição (localização do log). Esta informação é necessária ao configurar o servidor escravo.
    SHOW MASTER STATUS;
  • O File (nome do arquivo de log) e a Position exibidos por este comando serão usados na configuração do escravo.

Configurando o Servidor Escravo

Em seguida, edite o arquivo de configuração do servidor escravo e configure o ID do servidor e as informações do mestre.

  1. Editar o Arquivo de Configuração
  • Defina um server-id único no servidor escravo também (por exemplo, 2). Este valor deve ser diferente do ID do servidor mestre.
    [mysqld]
server-id=2

  • Também é comum definir read_only=ON para impedir gravações de dados no servidor escravo. 1. Configurar as Informações do Mestre no Escravo

  • Execute o comando a seguir no servidor escravo, especificando o nome do host do mestre, usuário, nome do arquivo de log binário e posição.

    CHANGE MASTER TO
    MASTER_HOST='master_host',
    MASTER_USER='repl',
    MASTER_PASSWORD='password',
    MASTER_LOG_FILE='mysql-bin.000001',
    MASTER_LOG_POS=123;

  • Insira os valores confirmados anteriormente no mestre para MASTER_LOG_FILE e MASTER_LOG_POS . 1. Iniciar a Replicação

  • Execute o comando a seguir no servidor escravo para iniciar a replicação.

    START SLAVE;

Verificando o Status da Replicação

Verifique se a replicação entre o mestre e o escravo está configurada corretamente.

  • Verificar o Status do Mestre
    SHOW MASTER STATUS;
  • Verificar o Status do Escravo
    SHOW SLAVE STATUS\G;
  • Se Slave_IO_Running e Slave_SQL_Running ambos exibirem Yes, a replicação está operando normalmente.

A próxima seção explica configurações avançadas de replicação, incluindo diferenças entre replicação assíncrona e semi‑síncrona e a configuração usando GTID.

4. Tipos de Replicação e Uso Avançado

A replicação MySQL inclui dois tipos principais baseados no método de sincronização de dados: replicação assíncrona e replicação semi‑síncrona. Ao entender suas características e escolher com base no seu caso de uso, você pode melhorar tanto o desempenho quanto a confiabilidade do sistema. Esta seção também explica os benefícios de usar GTID (Identificador Global de Transação) para a configuração da 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 mestre retorna uma resposta ao cliente imediatamente após concluir uma transação. Em outras palavras, o mestre pode continuar processando novas solicitações mesmo que a sincronização com o servidor escravo esteja atrasada. Isso oferece excelente desempenho de resposta e é adequado para sistemas focados na distribuição de carga. Contudo, durante uma falha, há o risco de que dados ainda não aplicados ao servidor escravo sejam perdidos.

2. Replicação Semi‑Síncrona

In semi-synchronous replication, the master server returns a response to the client only after confirming that data transfer to the slave server has completed. This improves data consistency, but because it waits for the slave, transaction response times may increase. Semi-synchronous replication is well suited for systems that require high data consistency or environments where data reliability is the top priority.

Replicação Usando GTID

GTID (Identificador Global de Transação) atribui um ID único a cada transação e mantém a consistência das transações entre o mestre e o escravo. Habilitar o GTID facilita o gerenciamento da replicação em comparação com a replicação tradicional baseada em posições de logs binários.

Vantagens do GTID

  • Consistência de Dados Aprimorada : Com o GTID, o escravo pode identificar automaticamente transações que ainda não foram aplicadas, facilitando a preservação da consistência.
  • Gerenciamento de Replicação Simplificado : O GTID melhora a eficiência para failover, troca de mestre/escravo e tarefas de recuperação. Como você não precisa mais especificar posições de logs binários, as operações se tornam mais simples.

Configuração da Replicação GTID

Para usar o GTID, você deve adicionar e habilitar as seguintes opções nos arquivos de configuração tanto do mestre quanto do escravo.

Configuração do Servidor Mestre

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

Configuração do Servidor Escravo

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

Em um ambiente com GTID habilitado, a replicação é realizada automaticamente via GTID simplesmente definindo as informações do mestre no escravo usando o comando CHANGE MASTER TO.

A próxima seção explica os métodos de manutenção da replicação MySQL e os principais pontos de monitoramento para a gestão operacional.

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

Para operar a replicação MySQL corretamente, manutenção e monitoramento regulares são essenciais. Esta seção explica os comandos para verificar se a replicação está funcionando normalmente e como lidar com erros comuns.

Como Verificar o Status da Replicação

Use os seguintes comandos para verificar o status de sincronização entre o mestre e o escravo.

Verificando o Status do Mestre

Você pode verificar o status da replicação do servidor mestre usando o comando SHOW MASTER STATUS. Este comando exibe o nome atual do arquivo de log binário e a posição, permitindo confirmar as atualizações mais recentes que devem ser entregues ao escravo.

SHOW MASTER STATUS;

A saída normalmente inclui os seguintes campos:

  • File : O nome atual do arquivo de log binário gerado pelo mestre
  • Position : A posição atual dentro do log binário
  • Binlog_Do_DB e Binlog_Ignore_DB : Bancos de dados incluídos/excluídos da replicação

Verificando o Status do Escravo

Você pode verificar o status da replicação do servidor escravo usando o comando SHOW SLAVE STATUS. Os resultados incluem informações necessárias para determinar se o escravo está operando corretamente.

SHOW SLAVE STATUS\G;

Os campos principais incluem:

  • Slave_IO_Running e Slave_SQL_Running : Se ambos forem Yes, o escravo está funcionando normalmente.
  • Seconds_Behind_Master : Indica o quão atrasado o escravo está em relação ao mestre (em segundos). Idealmente, esse valor deve ser 0.

Solucionando Problemas de Replicação

Problemas comuns durante a operação de replicação incluem erros de conexão e inconsistências de dados. Abaixo estão casos típicos de erro e como resolvê-los.

1. Erros de Conexão

Se Slave_IO_Running for No, isso significa que o escravo não pode conectar ao mestre. Tente o seguinte:

  • Verifique o nome de host ou endereço IP do mestre : Certifique‑se de que o endereço do mestre está correto.
  • Verifique as configurações de firewall : Confirme que a porta necessária (geralmente 3306) está aberta.

2. Inconsistência de Dados

Se Last_Error contiver uma mensagem de erro, pode ter ocorrido uma inconsistência de dados entre o master e o slave. Nesses casos, pare o slave e aplique correções antes de reiniciar a replicação.

STOP SLAVE;
# Restart after applying fixes
START SLAVE;

3. Reduzindo o Atraso de Replicação

O atraso de replicação pode ser causado por limitações de hardware do slave ou por problemas de rede. Se necessário, atualizar a configuração do servidor slave pode melhorar o desempenho.

A próxima seção explora os problemas de replicação em mais detalhes e fornece soluções adicionais.

6. Problemas Comuns e Suas Soluções

Durante a operação de replicação do MySQL, diversos problemas podem surgir. Esta seção explica os problemas comuns e como resolvê‑los. Detectar os problemas cedo e aplicar as correções corretas ajuda a manter a operação do sistema estável.

1. Quando Slave_IO_Running Está Parado

Sintoma: Se Slave_IO_Running mostrar No na saída de SHOW SLAVE STATUS, o slave não consegue se conectar ao master.

Causas e Soluções:

  • Problemas de Rede : Se houver um problema de conectividade de rede, o slave não pode acessar o master. Verifique as configurações de firewall e confirme que o master está acessível.
  • Nome de Host ou Endereço IP do Master Incorreto : Verifique se o nome de host ou endereço IP especificado em CHANGE MASTER TO está correto.
  • Problemas de Privilégios do Usuário : Se o usuário de replicação no master não tiver privilégios suficientes, a conexão falhará. Confirme que os privilégios corretos foram concedidos usando GRANT REPLICATION SLAVE .

2. Inconsistência de Dados no Slave

Sintoma: Se os dados não coincidirem entre o master e o slave, o slave pode entrar em um estado inconsistente.

Causas e Soluções:

  • Correção Manual de Dados : Pare o slave, corrija manualmente a transação problemática e então reinicie a replicação. STOP SLAVE; # Corrija os dados se necessário START SLAVE;
  • Ressincronização : Se a inconsistência for em grande escala, faça um backup completo do master e ressincronize o slave.

3. Atraso na Replicação

Sintoma: Se Seconds_Behind_Master não for 0 na saída de SHOW SLAVE STATUS, o slave está atrasado em relação ao master. Idealmente, esse valor deve estar o mais próximo possível de 0.

Causas e Soluções:

  • Limitações de Hardware do Slave : Se o servidor slave tem recursos insuficientes, ele pode não acompanhar. Atualizar o hardware pode ser eficaz.
  • Otimização de Consultas : Se as consultas recebidas do master demoram muito para ser executadas no slave, pode ocorrer atraso na replicação. Adicionar índices e otimizar as consultas pode reduzir o tempo de processamento.

4. Erros de Permissão do Usuário de Replicação

Sintoma: Se Last_Error mostrar uma mensagem relacionada a permissão, o slave pode não ter privilégios suficientes para se conectar ao master.

Causas e Soluções:

  • Reconfigurar Privilégios do Usuário : Certifique‑se de que exista um usuário com privilégios adequados no master. Reconfigure se necessário. GRANT REPLICATION SLAVE ON *.* TO 'repl'@'slave_ip_address'; FLUSH PRIVILEGES;

5. Crescimento do Log Binário

Sintoma: Os logs binários do master podem crescer excessivamente, consumindo espaço em disco.

Causas e Soluções:

  • Rotação de Log Binário : Exclua ou arquive regularmente os logs binários para evitar crescimento excessivo. Configurando expire_logs_days, você pode remover automaticamente logs mais antigos que um período especificado. SET GLOBAL expire_logs_days = 7; # Excluir logs mais antigos que 7 dias

Ao compreender esses problemas comuns de replicação do MySQL e suas soluções, você pode garantir uma gestão operacional mais fluida. A próxima seção resume os pontos principais para a gestão da replicação.

7. Conclusão

A replicação MySQL é um recurso crítico para melhorar a consistência dos dados e a confiabilidade do sistema. Neste artigo, abordamos tudo, desde os conceitos básicos da replicação MySQL até os procedimentos de configuração, práticas de monitoramento e métodos de solução de problemas. Abaixo está um resumo dos pontos principais para uma gestão eficaz da replicação.

Principais Conclusões

  1. Escolhendo o Tipo de Replicação Adequado
  • A replicação assíncrona oferece tempos de resposta mais rápidos e é ideal para distribuição de carga. No entanto, se a confiabilidade for a prioridade, a replicação semi‑síncrona é mais adequada. Escolha com base nos requisitos do seu sistema.
  1. Uso Eficaz do GTID
  • O GTID elimina a necessidade de especificar posições de log binário e permite uma gestão de transações fluida. É especialmente útil em ambientes com múltiplos slaves ou onde o failover é crítico.
  1. Monitoramento Regular de Status
  • Use SHOW MASTER STATUS e SHOW SLAVE STATUS para monitorar regularmente o estado operacional dos servidores master e slave. Ação rápida ao detectar anomalias minimiza riscos como inconsistência de dados ou atraso.
  1. Domínio da Solução de Problemas Básica
  • Problemas comuns de replicação incluem erros de conexão do slave, inconsistências de dados e atraso. Compreender soluções básicas para cada problema garante operações mais suaves.
  1. Gerenciamento de Log Binário
  • Como os logs binários podem consumir espaço significativo em disco, recomenda-se configurar expire_logs_days para limpeza automática e realizar manutenção regular.

A replicação MySQL não é uma tarefa de configuração única. Monitoramento contínuo e manutenção adequada são essenciais. Ao revisar regularmente o status do sistema e ajustar as configurações quando necessário, você pode construir e manter um sistema de banco de dados altamente confiável.

Esperamos que este guia ajude você a entender melhor e implementar a replicação MySQL. Desejamos operações de replicação suaves e estáveis.