Replicação de dados no MySQL

Prévia do material em texto

Replicação de dados no MySQL
O objetivo de um mecanismo de replicação de dados é permitir a manutenção de de várias cópias idênticas de um mesmo dado em vários servidores de banco de dados (SGBD). Os principais benefícios da replicação de dados é a redundância, o que torna o sistema menos sensível as falhas, a possibilidade de um balanceamento de carga do sistema, já que o acesso pode ser distribuídos entre as réplicas, e finalmente, ter-se um backup online dos dados, já que todos as replicas estariam sincronizadas. Este artigo, apresenta uma introdução ao mecanismo de replicação do MySQL, bem como as configurações básicas do SGBD para a realização desta tarefa.
O MySQL permite um tipo de replicação conhecido como Master-Slave, neste caso temos um servidor MySQL atuando como Master e um ou mais servidores MySQL atuando como Slaves. O servidor Master grava em um log binário de alterações todos os comandos de atualização da base de dados. Os slaves por sua vez se conectam ao master, lêem o arquivo de log binário e executam os comandos encontrados neste log. Desta forma, todas as alterações ocorridas no master são imediatamente replicadas para os outros servidores slave.
A replicação Master-Slave é um processo assíncrono, isto é, poderá existir um atraso de informações entre o master e os slaves dependendo do meio de comunicação entre eles. Além disto, como os slaves copiam as alterações do master, todas as modificações dos dados devem ser aplicadas ao master, caso contrário os servidores ficarão sem sincronismo. Este processo incremental com a execução de todas as alterações indicadas no log binário a partir de um determinado momento, não garante que os dados existentes antes do início da replicação eram idênticos. Neste caso, antes de iniciar a replicação é preciso sincronizar todos os servidores, colocando em todos eles uma cópia da base de dados a ser replicada.
Para configurar a replicação cada servidor MySQL deverá possuir um server-id único e o master deve estar com o log binário habilitado. Além disto, crie um usuário no master com o privilégio FILE (3.23.x) ou REPLICATION SLAVE (4.x ou superior), para que os slaves possam se conectar a este servidor e fazer a leitura do seu log binário. Nos slaves é preciso indicar o endereço do servidos master e o usuário que será utilizado para fazer a conexão. A seguir esta um exemplo de configuração do master e slave:
Master my.cnf                                           Slave my.cnf
[mysqld]                                                  [mysqld]
...                                                           ...
server-id=1                                              server-id=2
                                                             # IP ou DNS da máquina master
log-bin                                                    master-host=master.com.br 
...                                                          master-user=user_replication
                                                             master-password=senha_usuario
                                                             master-port=3306
Uma vez configurado os servidores, coloque a imagem dos dados a serem replicados em cada um dos servidores e reinicie o MySQL em todos os hosts. Depois disto a replicação estará funcionando. Para verificar o sucesso da configuração execute os comandos SHOW MASTER STATUS e SHOW SLAVE STATUS, respectivamente nos servidores master e slaves.
Topologias de replicação no MySQL
A restrição imposta por este recurso é a de que um slave poderá replicar apenas de um único master, sendo que a replicação multi-master está prevista para a versão 5.1.
Neste caso, é possível configurar várias topologias de replicação sem violar a condição apresentada anteriormente. A topologia mais comumente utilizada é aquela onde existe um servidor master e vários outros servidores atuando como slaves, como apresentado na Figura 1.
Figura 1. Topologia de replicação mais comum. 
O modelo anterior permite o balanceamento de carga entre os acessos de leitura e escrita, isto é, a aplicação se conecta ao master quando for executar uma escrita nos dados, e pode escolher um dos slaves para se conectar no momento em que for realizar uma leitura. Além disto, permite uma distribuição dos acessos de leitura entre os slaves existentes aumentando o desempenho do sistema como um todo. Ainda, caso haja uma falha no servidor master, um dos slaves pode ser colocado em seu lugar, já que estes mantêm uma cópia de tudo que acontece no servidor master. Vale ressaltar que esta troca de papéis deve ser implementada por uma ferramenta externa desenvolvida pelo administrador do banco de dados, já que o MySQL não provê mecanismos de fail-over embutidos no servidor. 
Existem outras topologias de replicação que permitem uma distribuição dos acessos de escrita, bem como as leituras. A primeira topologia que permite este balanceamento é conhecida como Master-Master, e é apresentada na Figura 2. 
Figura 2. Topologia Master-Master. 
Neste caso, as escritas podem ser distribuídas entre os masters 1 e 2, sendo que estes atuam como master e slave ao mesmo tempo. Assim, toda alteração ocorrida no master 1 se propaga para o master 2 e vice-versa. Neste cenário, é preciso projetar a aplicação de forma a não permitir colisões de chaves primárias, ou seja, imagine uma tabela com uma coluna AUTO_INCREMENT. Neste caso, pode ocorrer de o registro 5, por exemplo, ser inserido nos dois master ao mesmo tempo, o que levaria a uma falha de replicação interrompendo o mecanismo. Para evitar esta situação, seria necessário criar chaves que nunca se repetem, como é o caso dos GUUIDs (números gerados a partir do endereço do host e do timestamp), ou até mesmo colocar o número do servidor (server-id) para compor a chave primária de cada tabela. Assim, mesmo que houvesse inserções simultâneas nos masters não haveria colisões de chave primárias. Além disto, você pode manter slaves conectados a estes master como ocorria no primeiro caso.
Finalmente, para aplicações distribuídas geograficamente, pode-se criar servidores masters próximos às regiões que manipulam os dados, permitindo uma redução no tempo de acesso ao dado através da rede. Para isto, é necessário manter todas as regiões sincronizadas, e para isto, utilizamos a topologia de anel, onde define-se vários masters, como mostrado na Figura 3.
Figura 3. Topologia de anel. 
Desta forma, as alterações podem ser aplicadas a qualquer um dos masters existentes, permitindo a aplicação que pode estar distribuída, acessar uma base de dados mais próxima. O MySQL não grava, por padrão, no seu log binário os comandos recebidos através da replicação de dados. Daí, para que o anel funcione é preciso colocar em todos os masters o parâmetro log-slave-updates para que toda alteração, inclusive aquelas oriundas da replicação, sejam gravadas no seu log binário. Desta forma, é possível propagar uma alteração por todo o anel de servidores.
Estas são algumas técnicas que podem ser utilizadas para melhorar o desempenho do MySQL, garantindo alta disponibilidade e uma melhor distribuição do acesso dos clientes ao servidor.