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

Ontém necessitei implementar a já tradicional configuração de replicação 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 - replicação master-to-master

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 possuía 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 statusG; 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).
Experimente !