Este artigo foi baseado no seguinte ambiente:
Tipo de Host: físico
Quantidade de hosts: 2
Distribuição Linux: Red Hat Enterprise Linux 6.1
Versão do MySQL: 5.1.52 (community)
IP do Host1: 10.1.1.1
IP do Host2: 10.1.1.2
O artigo a seguir, descreve a replicação baseada em ativo / passivo, ou seja, master -> slave. O host principal, que será o master, irá receber todas as atualizações no banco especificado para a replicação, e irá replicar para outro MySQL localizado em outro host, que será o slave. A principal utilidade nisso na rápida recuperação em caso de desastres físicos e também para balanceamento de carga de consulta, entre outras utilidades. Vale lembrar, que este tipo de replicação não é considerado seguro para recuperação de falhas lógicas como por exemplo, inserções ou deleções por engano, porque os dados serão replicados exatamente como são na base master para a slave.
1 – Configurando o Master.
Tenha em mente que o master é o banco que irá receber toda a carga de inserts, updates e deletes, só ele poderá sofrer alterações, enquanto o slave estará em modo read-only (somente leitura). Para este artigo, considere que o banco a ser replicado será o fictício ‘testdb‘.
Primeiramente, teremos de adicionar algumas linhas no arquivo /etc/my.cnf :
log-bin = /var/log/mysql/mysql-bin.log
binlog-do-db=testdb
server-id=1
Uma vez feito, iremos reiniciar o SGDB para aplicar as novas configurações:
# /etc/init.d/mysqld restart
Considerando que você já criou um usuário para a replicação, iremos chamá-lo de slave_user, e iremos também aplicar o privilégio necessário para usá-lo durante a replicação. Para tal, executamos o SQL:
GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'%' IDENTIFIED BY 'alguma_senha';
FLUSH PRIVILEGES;
Feito, o master encontra-se configurado.
2 – Preparando o ambiente para a replicação e configurando o Slave.
Agora que temos um master, necessitamos de mais alguns passos para que possamos replicá-lo em outro host.
Primeiro, precisamos fazer um dump do banco que iremos replicar, mas com a devida precaução para que o mesmo não seja alterado antes de o master e o slave estejam devidamente conectados e sincronizados. Esse trabalho é manual e pode tomar algum tempo dependendo do tamanho da base de dados bem como de sua infraestrutura. Para tal, precisamos executar o comando SQL para “travar” todas as tabelas do master:
USE testdb;
FLUSH TABLES WITH READ LOCK;
Uma vez feito isso, devemos, em linha de comando, executar o binário mysqldump para jogar toda a base de dados em um arquivo de texto plano, para que assim possamos transportá-lo para o outro host que será o slave. Note que durante todo este processo, as tabelas do banco ‘testdb‘ estarão travadas. O exemplo abaixo considera que o usuário do master é root e a senha é 123456. Execute no shell do Linux o seguinte comando:
# mysqldump -u root -p123456 –database testdb > testdb.sql
Uma vez que temos o banco inteiramente “dumpado” em um arquivo, agora você deve enviar da forma que mais lhe for conveniente para o outro host, que será o slave.
Agora, devidamente conectado ao slave. Editaremos o arquivo /etc/my.cnf do mesmo, é incluiremos algumas linhas:
server-id=2
replicate-do-db=testdb
Então, devemos criar o banco para receber nosso dump que foi transferido do servidor master, para isso executaremos o comando SQL e criaremos o banco testdb no slave:
CREATE DATABASE testdb;
Deveremos então importar todos os dados do master, neste que será o slave, e logo após iremos reiniciar o SGDB slave. Para tal, execute na shell do Linux no host do slave o comando:
# mysql -uroot -p123456 testdb < testdb.sql
# /etc/init.d/mysqld restart
Após reiniciá-lo, iremos ativar a replicação, para tal devemos coletar algumas informações ainda o master como arquivo de log e posição do log. Para tal, execute o comando SQL no master:
SHOW MASTER STATUS;
Este comando deverá mostrar uma saída parecida com essa:
+---------------+----------+--------------+------------------+
| File | Position | Binlog_do_db | Binlog_ignore_db |
+---------------+----------+--------------+------------------+
| mysql-bin.006 | 134 | testdb | |
+---------------+----------+--------------+------------------+
1 row in set (0.00 sec)
Isso significa que o nome do arquivo de log para esta replicação é mysql-bin.006 e encontra-se na posição 134. Agora iremos executar no slave o seguinte comando SQL:
USE testdb;
CHANGE MASTER TO MASTER_HOST=10.1.1.1', MASTER_USER='slave_user', MASTER_PASSWORD='alguma_senha', MASTER_LOG_FILE='mysql-bin.006', MASTER_LOG_POS=134;
SLAVE START;
Caso encontre algum erro, confira se o suporte a networking está habilitado no master já que a replicação é feita através de TCP/IP e não de UNIX Sockets. Caso esteja habilitado e você continuar recebendo mensagens de erro ao executar tal comando, favor repetir os passos e / ou consultar este artigo novamente para saber se houve algum erro durante a implementação.
Para conferir que está tudo OK, você deve executar o comando:
SHOW SLAVE STATUS\G
Esse comando irá lhe reportar o status do cluster de replicação. Caso esteja tudo OK, é hora de “destravar” as tabelas no master, executando no master o comando SQL:
UNLOCK TABLES;
Pronto, a replicação do banco testdb está feita. Para certificar-se se está funcionando de maneira correta, faça alterações no master e veja se as mesmas são replicadas no slave.
3 – Finalizando o artigo.
Espero que este artigo tenha lhe sido útil. Caso encontre erros aqui e/ou deseja sugerir mudanças ou adicionar mais informações ao artigo, escreva nos comentários e as devidas alterações serão feitas dando os devidos créditos aos autores.
