Alta disponibilidade com MySQL – Parte 2

postado em: Tutoriais | Comments

Olá pessoal! Este é o segundo de três posts relacionados a alta disponibilidade com MySQL e explicarei como fazer a replicação MySQL como Master to Master, de uma forma simples e eficiente. Se você não leu o primeiro post “Alta disponibilidade com MySQL – Parte 1” eu indico a leitura.

 

Como funciona a replicação?

A replicação do MySQL basicamente é formada por dois servidores, podendo ser um Master e um Slave ou dois Masters, isto vai depender da sua necessidade. O que acontece quando temos dois servidores replicados é que ao inserir um dado no banco, criar um usuário ou um banco de dados, o servidor que possui estas informações gravará as mudanças em um log binário que será trafegado até o servidor secundário que fará uma leitura deste log e fará as mesmas alterações feitas no servidor primário. Imagine os servidores como um espelho que tudo que um tem o outro também terá.

Como falei acima, a replicação precisa do log binário ou binary log mas também precisamos do relay log.

O log binário contém os “eventos” que descrevem as alterações feitas no banco de dados tais como operações de criação de tabelas, criação de usuário, criação de bancos ou alteração de dados nas tabelas. O log binário tem duas finalidades importantes:

  • Para a replicação, o log binário  em um servidor de replicação como master, fornece um registro das alterações de dados que devem ser enviados para servidores do tipo slave. O servidor master envia os eventos contidos no seu log binário para seus slaves, que executam esses eventos para fazer as mesmas alterações de dados que foram feitas no master.
  • Determinadas operações de recuperação de dados precisam do uso do log binário. Após um backup que foi restaurado, os eventos no log binário que foram registrados após o backup serão registrados novamente. Estes eventos trazem bancos de dados atualizados a partir do ponto do backup.

O log binário é crash-save, ou seja, apenas eventos ou operações completas são registrados ou gravados no slave. Tabelas corrompidas, por exemplo, farão sua replicação parar e estes dados não serão replicados para o slave.

O relay log assim como o log binário contém os eventos do MySQL, porém, é nele onde ficam os eventos que o slave copiará. Então basicamente no log binário ficam os eventos gravados pelo master e no relay log ficam os eventos copiados do master e que devem ser replicados.

Mas como é feita esta cópia e gravação dos dados de um lado para o outro? A replicação trabalha com duas threads: I/O Thread e SQL Thread.

I/O Thread: É a thread responsável por monitorar e copiar os eventos gerados pelo Master. Quando o master efetuar alguma alteração em seus dados, será gravado um evento no log binário, com isso, o I/O Thread do servidor slave fará uma leitura deste evento no log binário e gravará estas modificações no relay log. 

SQL Thread: É a thread responsável por ler o relay log e gravar os eventos gerados pelo master no slave. Após o I/O Thread gravar os eventos do log binário no relay log, o SQL Thread fará uma leitura do relay log e gravará em disco todas estas modificações.

A imagem abaixo ilustra bem como funciona a replicação do MySQL.

mysql_replicacao

Como configurar a replicação no MySQL?

Vamos trabalhar com dois servidores MySQL do tipo Master to Master, ou seja, você poderá gravar os seus dados em qualquer lado do seu “cluster”. O servidor um ou MYSQL01 terá o IP 192.168.0.1 e o servidor dois ou MYSQL02 terá o IP 192.168.0.2.

Primeiro precisamos configurar alguns parâmetros no my.cnf para que o servidor MySQL comece a gravar os logs binários e faça todo processo de replicação. Darei uma explicação breve sobre cada parâmetro e o que cada um controla para que você possa configurar de acordo com a sua necessidade.

binlog-format: É o parâmetro que configura a forma da replicação: Row, Statemant e Mixed. Row é mais indicada para replicação de dados com engine InnoDB, já Statemant é indicada para dados com engine MyISAM. Mixed é a forma de replicar com os dois métodos ao mesmo tempo.
log-bin: Habilita a gravação dos logs binários.
log-slave-updates: Faz com que o slave grave no seu próprio log binário as modificações.
max_binlog_size: Controla o tamanho máximo do log binário que queremos ter. Ao atingir o tamanho máximo, será criado um novo log binário.
max_relay_log_size: Controla o tamanho máximo do relay log que queremos ter. Ao atingir o tamanho máximo, será criado um novo relay log.
expire_logs_days: Controla o tempo máximo que um log será mantido em disco antes de ser excluído.
master-info-repository: É o parâmetro que configura onde serão gravadas as informações de conexão com o master.
relay-log-info-repository: Responsável por configurar onde serão gravadas as informações relacionados ao relay log.
server-id: ID do seu servidor. Cada servidor deve ter um ID e não pode haver servidores com o mesmo ID no sistema de replicação.
report-host: Nome do servidor que será utilizado na replicação.

Sabendo o que cada parâmetro faz, agora podemos iniciar a configuração dos servidores. No servidor com IP 192.168.0.1 você deverá configurar da seguinte forma

 binlog-format=MIXED
 log-bin
 log-slave-updates=true
 max_binlog_size=200M
 max_relay_log_size=200M
 expire_logs_days=1
 master-info-repository=TABLE
 relay-log-info-repository=TABLE
 server-id=1
 report-host=MYSQL01

Agora no servidor com IP 192.168.0.2, configure com estes parâmetros:

 binlog-format=MIXED
 log-bin
 log-slave-updates=true
 max_binlog_size=200M
 max_relay_log_size=200M
 expire_logs_days=1
 master-info-repository=TABLE
 relay-log-info-repository=TABLE
 server-id=2
 report-host=MYSQL02

Com os dois my.cnf configurados, basta reiniciar o MySQL para que estas configurações entrem em vigor. Após o serviço subir, no servidor MYSQL01 vamos configurar os usuários que farão a replicação entre os dois servidores

MYSQL01> GRANT REPLICATION SLAVE ON *.* TO replicador@'192.168.0.2' IDENTIFIED BY 'senha';

MYSQL02> GRANT REPLICATION SLAVE ON *.* TO replicador@'192.168.0.1' IDENTIFIED BY 'senha';

Vejam que eu criei os usuários especificando o host contrário a ele. Isso evita acessos indesejados e aumenta a segurança do seu servidor.

Agora no servidor MYSQL01 execute o comando MYSQL01> SHOW MASTER STATUS;. Este comando trará informações sobre o seu master:

master_mysql01
Master status

 

A “position” normalmente começa em 120. Como efetuei algumas alterações no meu banco antes de executar o comando, a minha position está com um valor maior. No MYSQL02 agora vamos ativar a replicação:
MYSQL02> CHANGE MASTER TO MASTER_HOST='192.168.0.1', MASTER_USER='replicacao', MASTER_PASSWORD='senha',
MASTER_PORT=3306, MASTER_LOG_FILE='MYSQL01-bin.000001', MASTER_LOG_POS=101609411; START SLAVE;

Agora vamos verificar o status da replicação com o comando MYSQL02> SHOW SLAVE STATUS \G. Se o retorno for igual o da imagem, um dos seus servidores já está replicando.

slave_status
Status da replicação

 

Observe que os parâmetros Slave_IO_Running e Slave_SQL_Running estão como “yes”, isto significa que o I/O Thread e o SQL Thread estão funcionando normalmente. Outros parâmetros importantes são: Last_IO_Errno, Last_IO_Error, Last_SQL_Errno e Last_SQL_Error, se os valores estiverem iguais a da imagem, não tivemos erros na ativação da replicação. O último parâmetro é o Slave_SQL_Running_State, é nele que será informado se o servidor está sincronizando ou está sincronizado.

Agora para concluir a replicação, execute os comandos de Master status no servidor MYSQL02 e o comando de ativação da replicação no MYSQL01. Fazendo isso, os dois servidores estarão replicando as informações. Um bom teste é criar um banco, um usuário e uma tabela no MYSQL01, verificar se o mesmo foi criado no MYSQL02 e excluir tudo pelo MYSQL02. Se os dados foram criados e removidos dos dois lugares, a sua replicação está 100% funcional!

Então é isso pessoal! Se ficaram com alguma dúvida ou dificuldade basta entrar em contato ou deixar o seu comentário. E não esqueçam que ainda teremos mais um post sobre alta disponibilidade!

Allan Moraes

Allan Moraes é gaúcho e entusiasta open source. Trabalha em uma Startup com foco em Plataforma como Serviço (PaaS), é especialista em MySQL, High Availability e High Scalability Architecture.