Em tempos em que informações valem ouro e estas precisam manter-se disponíveis em tempo integral para que possam ser manipuladas, consultadas, transferidas, copiadas ou qualquer outra finalidade a que se destinem, é necessário redobrar a atenção com a disponibilidade dos servidores de bancos de dados. Um servidor instável, offline ou mesmo danificado pode trazer sérios prejuízos para empresas que trabalham com informações, realizam métricas e análises de dados, para o mercado de Big Data etc. Uma técnica já bastante popularizada de “backup” das informações de servidores de bancos de dados é a replicação. Ela consiste em criar réplicas dos dados entre servidores paralelos, de forma que, em caso de falha de um servidor, os dados ainda estejam disponíveis em outra instância para que o negócio não deixe de funcionar, garantindo dessa forma a confiabilidade e a disponibilidade centralizada das informações para todos os sistemas que delas necessitem. Um bom cenário de replicação útil para diversas empresas com as quais trabalhei é o seguinte:

• Uma empresa possui sua matriz localizada no estado de São Paulo e algumas filiais espalhadas pelo Brasil;
• A matriz da empresa precisa analisar em tempo real as informações geradas pelas filiais: cadastros de novos clientes, vendas, ordens de serviços, orçamentos etc.;
• As filiais necessitam de aprovação de determinadas ações das filiais, como nos casos de ordens de compra. Sendo assim, uma vez que os dados estejam centralizados na matriz, quaisquer alterações serão replicadas para as filiais e vice-versa.

No caso de uma falha em qualquer um desses servidores, após sua resolução, os dados serão atualizados de forma que nada seja perdido e o processo de negócios continue com a menor taxa de impacto possível, reduzindo o risco de prejuízos.

No mundo real

Você pode adaptar esse cenário para a sua necessidade com a finalidade de verificar se e quando é necessário ter replicação de dados na sua empresa. No mercado de SGBDs (Sistemas Gerenciadores de Bancos de Dados) atuais, é praticamente inexistente um sistema que não tenha o recurso de replicação de dados, uma vez que ele passou a ser prioridade e item de suma importância para quem precisa consumir a informação armazenada rapidamente, sem preocupações em relação à disponibilidade dos dados.

Replicação ou espelhamento?

Até pouco tempo atrás, o espelhamento – no caso dos bancos de dados – era diferente da replicação que temos hoje. A replicação tinha algum retardo, levava algum tempo para atualizar os outros servidores, enquanto o espelhamento consistia em manter uma cópia fiel em tempo real do servidor em outro local. Atualmente, a replicação pode ter o mesmo efeito de um servidor espelho, quando bem configurado, e o retardo, se existente, é muito pequeno, possuindo alguns milissegundos. No entanto, para fins didáticos do conceito de ambos os recursos, o espelhamento de volumes lógicos (locais onde são armazenados os dados) são tratados como volumes físicos presentes em uma infraestrutura única, o que não acontece na replicação, na qual os volumes podem estar em diferentes arquiteturas e infraestruturas, remota ou localmente.

Replicação no MySQL

A replicação de dados em servidores MySQL é bastante facilitada e trabalha basicamente com a configuração de binários. No cenário exemplo deste artigo, vamos trabalhar com apenas dois servidores. Ambos devem possuir o parâmetro server-id configurado, para que seja mais fácil identificá-los. Não é o objetivo deste artigo ensinar a instalação do servidor MySQL, então vamos partir da premissa de que você já possui duas instâncias do MySQL instaladas em dois servidores, que em meu exemplo terão os IPs 192.168.11.1 (master principal, que será o servidor que sofrerá efetivamente todas as alterações) e 192.168.11.2 (o slave), e ambas as versões são 5.1.x. Nesse cenário, a máquina master possui um banco de dados chamado finance e que será replicado para o servidor escravo. O servidor escravo possui um usuário previamente criado chamado adamante e que possui acesso ao banco de dados que será replicado. No arquivo my.cnf, deverá ser configurado o banco de dados a ser replicado e o server-id do servidor master seguinte:

log-bin = /var/log/mysql/mysql-bin.log
binlog-do-db=finance
server-id=1

O servidor escravo poderá sofrer a mesma alteração no arquivo my.cnf, no entanto, seu server-id será 2 (server-id=2):

log-bin = /var/log/mysql/mysql-bin.log
replicate-do-db=finance
server-id=2

Reinicie o servidor de banco de dados master e em seguida execute os comandos que irão garantir os privilégios necessários ao usuário adamante (presente no servidor escravo) para que este tenha acesso à replicação de dados do servidor master:

GRANT REPLICATION SLAVE ON *.* TO 'adamante'@'%meudominio.com.br;
FLUSH PRIVILEGES;

O próximo passo consiste em bloquear a tabela para receber dados, de forma que possamos realizar um dump completo para a primeira carga de dados no servidor escravo.

USE finance;
FLUSH TABLES WITH READ LOCK;

Dessa forma, todas as tabelas do banco de dados finance estarão congeladas para que seja possível criar um arquivo de exportação íntegro. É possível fazer a exportação do arquivo dump do banco de dados de duas formas: a primeira utilizando o comando mysqldump + nome da tabela e gerando um arquivo .sql que poderá ser importado no servidor escravo posteriormente, ou então através do nome do binário de dados, o que pode ser mais interessante caso sua massa de dados seja muito grande. Vamos trabalhar com o comando mysqldump que é bastante ágil e atende à maioria dos cenários atuais de pequenas e médias empresas. Vamos criar uma cópia do banco finance em um arquivo .sql que será transportado para o servidor escravo e que servirá para deixá-los idênticos nesse primeiro momento – lembrando que as tabelas do servidor master permanecem bloqueadas pelo comando LOCK enviado anteriormente. Execute o comando com o usuário root da máquina master (isso também poderia ser feito com algum usuário que tivesse permissões para exportação de dados, como o usuário adamante presente no servidor escravo):

mysqldump --u root --p 123456 --database finance > finance_export.sql

Uma vez exportados os dados, teremos um arquivo .sql contendo todo o conteúdo do banco de dados finance. Copie esse arquivo .sql para o servidor escravo, crie um banco de dados com o mesmo nome (finance) nesse servidor e importe o arquivo .sql que criamos para populá-lo com os dados.

mysqldump --u adamante --p 123456 --database finance < finance_export.sql

Reinicie o banco de dados escravo para que as configurações tenham efeito e em seguida vamos coletar uma informação importante para finalizar a configuração da replicação: o local do binário de dados. Execute o comando SHOW MASTER STATUS; no servidor master de forma que tenhamos um resultado parecido com este:

+------------------+----------+--------------+------------------+
 | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
 +------------------+----------+--------------+------------------+
 | mysql-bin.000159 | 114      | finance      | manual,mysql     |
 +------------------+----------+--------------+------------------+

Veja que o binário do banco de dados finance possui o nome mysql-bin.000159 e sua posição é 114. No servidor masters, vamos informar de onde os dados serão recebidos através do comando CHANGE MASTER.

CHANGE MASTER TO MASTER_HOST=192.168.11.1', MASTER_USER='adamante', 
MASTER_PASSWORD='123456', MASTER_LOG_FILE='mysql-bin.000159', 
MASTER_LOG_POS=114;
SLAVE START;

Isso finaliza a configuração da replicação entre os dois servidores. Desbloqueie as tabelas do servidor master com o comando UNLOCK TABLES; e a partir de então todas as alterações realizadas no servidor master serão replicadas no servidor escravo. Futuramente vou abordar a replicação de dados em outros SGBDs.

Até lá!