Replicação MySQL – Introdução

Ola pessoal,

Antes de configurarmos uma replicação no MySQL, é importante entendermos como ela funciona, por isso neste post vamos tratar de uma breve introdução a replicação Master x Slave no MySQL.

O MySQL por default já oferece suporte para Replicação. Funciona por um mecanismo assíncrono, unidirecional com o fornecimento de logs (binários) entre um servidor Master / Slave. Quando um servidor é denominado como Master, este recebe todas as atualizações (insert, alter, update), onde o Slave recebe todas as atualizações que ocorrem com êxito no master, mantendo desta forma os dados íntegros do servidor Master.

O Slave muitas vezes é definido como Ready Only, sendo possível apenas efetuar consultas (select) neste servidor, e demais comandos de alteração devem ser aplicados no servidor Master.

Existem Threads pré definidas no MySQL responsáveis pela comunicação entre os servidores, que são:

IO_THREAD – Responsável pela conexão entre o servidor Master X Slave e pelo download dos logs binarios entre a origem (Master) ao destino (Slave). Ao fazer o download dos logs binarios do servidor Master, o IO_THREAD armazena estes logs no relay log (Slave), arquivo que o Slave vai ler para aplicar as transações.

SQL_THREAD – Esta é a thread que aplica todos os logs obtidos no relay log no servidor Slave.

Resumindo (POR CIMA), o primeiro se conecta e obtem os logs do Master, e o segundo executa os logs obtidos no servidor Slave.

Uma imagem que resume muito bem este cenário:

AR

Imagem obtida no site: http://www.devmedia.com.br/

Não existe um limite definido de quantos slaves um único master pode ter abaixo dele. Como um servidores Slave consome uma quantidade pequena de recursos, este limite é baseado na disponibilidade do ambiente como em quantidade de consultas, escrita, disponibilidade de memória & Cpu entre outros. Se citarmos uma bala de “prata”, não é recomendável ter a mais de 30 slaves sob um master.

Nesta etapa, é totalmente viável configurar o servidor Master para receber apenas as requisições de atualização e escrita, e deixar que os Slaves trabalhem a demanda de selects, que no dia a dia sim, faz uma diferença 🙂

Outro ponto interessante sobre a replicação do MySQL é que um Slave também pode assumir o papel de Master para outros Slaves. Todas as alterações ocorrem em um Master superior, estas depois são enviadas para os Slaves imediatos, e esses Slaves retransmitem os dados para os outros Slaves em diante até que toda a cadeia seja alcançada.

Em um ambiente de produção concorrido, este cenário é muito interessante, pois o servidor Master recebe todas as requisições, replica para apenas um servidor que assume o papel de Master X Slave, e este replica os dados para mais 10 Slaves por exemplo.

Mas claro que isso torna o ambiente complexo, sendo necessária uma documentação de cada servidor para futuras manutenções. Um exemplo deste ambiente:

replication03

Este tipo de Slave também é denominado como Relay Slave

Para que uma replicação ocorra, é necessário que os servidore Master:

– Server id unico
– Esteja com o log binário (binlog) ativado
– Um usuário exclusivo para a replicação com o grant REPLICATION SLAVE
– Seja gerado um backup do master com a opção -master-data (Posição no Log)

Já no servidor Slave, basta:

– Server id unico (Diferente do Master)
– Efetuar o restore gerado do servidor Master
– Informar o ‘caminho’ e as demais propriedades do servidor master através do CHANGE MASTER TO
– Iniciar a replicação com o Start Slave

Obs: No MySQL 5.6, mesmo sem definir um ID no arquivo de configuração, o proprio serviço atribui valores distintos para diferenciar o Master x Slave.

Outra vantagem da replicação no MySQL é que um Slave pode ter uma versão Superior a de um Master. Isso mesmo, enquanto um servidor Master opera com a versão 5.1, um SLAVE pode operar com a 5.6.

Isso minimiza um possível downtime para um upgrade de versão, onde basta configurar um Slave com uma versão superior ao master, deixa-lo com um perfil de Relay Slave e alterar apenas o metodo de conexão da aplicação ao servidor MySQL. Porém não é recomendado o processo inverso, um servidor Slave com uma versão inferior ao Master, pois algumas instruções no servidor mais atual podem não ser interpretadas no Slave.

Outras opções:

– Você pode ignorar a replicação de uma base, ou até mesmo de tabelas especificas
– Você pode programar a replicação para execução de hora em hora

Mas nem tudo são flores nessa vida, existem também algumas limitações conhecidas na replicação do MySQL, como por exemplo a replicação de eventos entre servidores Master x Slave, que necessitam de uma intervenção manual.

Para maiores informações sobre estas limitações, consulte a documentação do MySQL referente:

http://dev.mysql.com/doc/refman/5.5/en/replication-features.html

Finalizando este assunto, a replicação do MySQL é uma otima opção se tratando de alta disponibilidade, backup, balanceamento de carga e redundancia. Sua configuração é simples, e a manutenção objetiva, limitada a alguns recursos como qualquer outra.

Mesmo com uma queda de rede, o Slave consegue rastrear o ultimo ponto de restore (relay log) e logo se reconstroi quando a conexão é estabelecida. Em casos especificos onde o intervalo entre o Master e Slave é muito grande, pode ser necessária a reconstrução da replicação, algo que também não é um bicho de sete cabeças.

No proximo post, iremos configurar uma replicação e analisar mais detalhes de como analisar o status da replicação, propriedades entre outros,

Referências:

http://www.devmedia.com.br/mysql-replicacao-de-dados/22923
http://www.devin.com.br/replicacao-mysql/
https://dev.mysql.com/doc/refman/5.6/en/replication.html

É isso ai pessoal.

Dúvidas, criticas ou sugestões? Fiquem a vontade, todo retorno é construtivo 🙂

Jose Wilson

2 Replies to “Replicação MySQL – Introdução”

    1. Ola Emery, tudo bem?

      Não entendi muito bem a sua pergunta, mas para obter a posição do master, basta executar o comando:

      mysql> show master status

      A posição do master é alterada a cada nova transação, então não vejo motivos para ‘manter’ a posição. Caso você precise construir uma replicação, faz sentido travar a escrita no master e obter a posição do mesmo para conseguir sincronizar com um slave:

      mysq> flush tables with read lock ;
      mysql> show master status;

      Pretendo exemplificar este processo em um novo post, mas caso não seja essa a sua dúvida, basta responder novamente.

      Abraços.

Deixe uma resposta