Topologias de replicação no MySQL

No meu último artigo
http://www.sqlmagazine.com.br/colunistas.asp?artigo=Colunistas/eber/11_replicacao.asp, foi apresentado o mecanismo de replicação de dados do MySQL. Este recurso chamado de replicação Master-Slave permite que um servidor MySQL (slave) copie todas as alterações realizadas em um outro servidor, denominado de master. 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. No próximo artigo, apresentarei as novidades do MySQL 5.0.

Abraços e até breve!

Eber M. Duarte.

Eber Duarte é bacharel em Ciência da Computação, pós-graduado em Engenharia Elétrica e MySQL Professional Certified. Trabalha há 3 anos na EAC Software (BH/MG) como Analista e desenvolvedor de sistemas, atuando especialmente no desenvolvimento de sistemas Web. Atualmente, também é consultor e instrutor do banco de dados MySQL. Contatos: eber@eacnet.com.br www.mysqlbrasil.com.br ou www.eacsoftware.com.br