sexta-feira, 24 de fevereiro de 2012

Replicação master-to-master com MySQL 5.5


Ontém necessitei implementar a já tradicional configuração do master-to-master, descrito nesse outro post. O problema é que a versão instalada no servidor não era o default do Debian e modificações no procedimento foram necessárias para a versão instalada – mysql-5.5, baixada diretamente do site do Mysql.
Se sua solução necessitar de alta-disponibilidade, leia esse outro post para executar a parte de heartbeat.
Procedimento
Ficou relativamente mais simples; a base instalada ainda não estava em uso. Basicamente, após instalar a base de dados, simplesmente adicione essas linhas no /etc/my.cnf (no caso de ter instalado a partir de binários do site oficial, esse será o caminho do my.cnf) na sessão [mysqld]:

#----- master2master ---------
#configuracoes para o servico
#no node02 utilize 2 e no node01 utilize 1 no server-id
#auto-increment-increment= 2 no node02
# auto-increment-increment= 1 no node01

server-id = 2
replicate-same-server-id= 0
#o auto-increment abaixo segue o padrao do server id; 1 para 1, 2 para 2
auto-increment-increment= 2
#offset sempre 2
auto-increment-offset = 2
expire_logs_days = 10
max_binlog_size = 500M
#bases que nao serao replicadas devem ser explicitamente ignoradas
binlog_ignore_db = mysql

#bases a replicar. Para cada base que quiser replicar, ambas as linhas serão necessárias.
binlog_do_db = minhaBase
replicate-do-db = minhaBase

As configurações que eram descritas no my.cnf outrora, não mais existem a partir dessa versão. Para fazer as demais configurações, será necessário executar a seguinte query:

change master to
MASTER_HOST='10,0,0,1',
MASTER_USER='replication',
MASTER_PASSWORD='slave',
MASTER_PORT=3306,
MASTER_LOG_FILE='mysql-bin.000003',
MASTER_LOG_POS=4,
MASTER_CONNECT_RETRY=10;
Utilizei o último log que que possuia no momento. Dei a posição 4 apenas para ser fiel ao exemplo da documentação (e também porque eu estava com o relógio em contagem regressiva e precisava fazer essa configuração logo). No exemplo acima, estou configurando o node02 para ser slave do node01 (10.0.0.1), então, ao configurar o node01 não se esqueça de trocar o IP para o IP do node02, de forma que o node01 seja o escravo do node02.
Por fim, ajustar os privilégios e iniciar os slaves (em ambos os nodes):

grant all privileges on *.* to replication identified by 'slave';
slave start
Rodando show slave status\G; deve retornar algo como:

*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.0.0.1
Master_User: replication
Master_Port: 3306
Connect_Retry: 10
Master_Log_File: mysql-bin.000004
Read_Master_Log_Pos: 193
Relay_Log_File: db01-relay-bin.000006
Relay_Log_Pos: 339
Relay_Master_Log_File: mysql-bin.000004
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: minhaBase
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: 193
Relay_Log_Space: 644
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
1 row in set (0.00 sec)

ERROR:
No query specified

No primeiro momento tive um erro que não fui capaz de resolver imediatamente, então tomei os caminhos que achei necessário para solver o problema. Posteriormente pesquisei pela solução correta. O problema que tive foi:

Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: ‘Could not find first log file name in binary log index file’
Esse erro acontece normalmente (quando isso acontece) em uma queda abrupta do sistema, por exemplo. Não foi o meu caso, mas a causa foi diferença por manipulação das bases. Então, para corrigir o problema adota-se o procedimento de parar o serviço dos slaves e fazer um flush, inicialmente. Certamente esse erro se dará em 1 dos dois nodes, cujo node corresponderá ao master. Tomando essa definição como referência, execute os comandos adiante dos respectivos hosts:

Slave: stop slave;
Master: flush logs;
Master: show master status;
Após executar esse comando, anote o arquivo de log do master e sua respectiva posição. O slave ainda não está atuando. Agora no slave execute:

change master to MASTER_LOG_FILE=’mysql-bin.000004′, MASTER_LOG_POS=193;
Após feito, inicie a replicação do slave novamente:
slave start;
Não lí mais nenhum artigo desse blog de referência sobre esse procedimento de recovery, mas recomendo a visita através desse link. Parece uma boa fonte de informação, mas lembre-se que o site oficial do MySQL é vasto de documentação, além de extremamente organizado. Também tem alguns treinamentos espetaculares lá, se a minha empresa pagar, reporto a qualidade do curso e os resultados posteriormente.
Provavelmente farei outros posts sobre MySQL devido ao meu envolvimento atual com ele e também farei alguns posts sobre segurança digital (vasto tema).
Não trema na base; experimente !

Nenhum comentário:

Postar um comentário