Artigo da SQL Magazine 33 - Técnicas avançadas de replicação no MySQL

Artigo da SQL Magazine - edição 33.

Gostei (1)

(0)

[fechar]

Você não gostou da qualidade deste conteúdo?

(opcional) Você gostaria de comentar o que não lhe agradou?

Capa SQl 33

Clique aqui para ler todos os artigos desta edição

Técnicas avançadas de replicação no MySQL

Giuseppe Maxia

Você já deve ter ouvido falar a respeito do MySQL Cluster, que é uma arquitetura para se conseguir disponibilidade e desempenho elevados. Uma das vantagens do MySQL Cluster é que cada nó é par de um outro nó, visto que em um sistema de replicação normal, temos um nó mestre e muitos “escravos”, e as aplicações devem escrever somente para o nó mestre.

As principais desvantagens do MySQL Cluster (assim como do MySQL 5.0) são:

· O banco de dados trabalha somente em memória, requerendo assim mais recursos do que um banco de dados normal MySQL (o MySQL 5.1 introduz table spaces com a capacidade de armazenamento de dados não indexados no disco);

· Algumas características como buscas full-text, integridade referencial e níveis da isolação da transação mais elevados do que o READ COMMITTED, não estão disponíveis.

Existem alguns casos onde o MySQL Cluster é a solução perfeita, porém na maioria, a replicação ainda é a melhor escolha. A replicação, no entanto, também tem seus problemas:

· Há uma distinção entre o nó mestre e os nós escravos. As aplicações devem estar alertas às replicações, de modo que escreverão no mestre e lerão dos escravos.

· Existe o problema do fail-over. Quando o nó mestre falha, teremos os nós escravos prontos para substituí-los, porém o processo de detectar a falha e agir de forma correta requer a intervenção do administrador.

Este artigo objetiva apresentar meios de lidar com estas características falhas. Utilizando as características introduzidas no MySQL 5.0 e 5.1, é possível construir um sistema de replicação onde todos os nós trabalhem como mestre e escravo ao mesmo tempo, com um mecanismo de fail-over embutido.

Configurando um sistema de replicação Multimaster

Vamos considerar a situação em que configuramos um sistema de replicação com mais de um nó mestre. Um problema difícil de resolver em uma replicação multimaster é o conflito que pode acontecer com chaves geradas automaticamente. O AUTO_INCREMENT é completamente conveniente, porém, em um ambiente de replicação, será prejudicial. Se ambos os nós A e B inserem uma chave com esta característica na mesma tabela, os conflitos surgem imediatamente.

A solução para este problema está nas versões mais recentes do MySQL. A versão 5 introduz um par de variáveis de servidor para auto-increment replicado que resolve este problema específico e permite a criação de um array de nós peer-to-peer com replicação MySQL. Citando o manual:

· auto_increment_increment controla o incremento entre valores sucessivos de AUTO_INCREMENT;

· auto_increment_offset determina o ponto de início para valores da coluna de AUTO_INCREMENT.

Escolhendo valores não conflitantes para estas variáveis em nós mestres diferentes, os servidores em uma configuração multimaster não utilizarão valores conflitantes de AUTO_INCREMENT ao inserir novas linhas na mesma tabela. Para configurar os N servidores mestre, configuramos as variáveis da seguinte maneira:

· Configurar o auto_increment_increment para N em cada mestre.

· Configurar cada um dos N nós mestres para que tenham um auto_increment_offset diferente, utilizando os valores 1, 2…, N.

Utilizando estas duas variáveis como descrito no manual, garantimos que todos os nós no array de replicação utilizem seqüências diferentes de números de auto-incremento. Por exemplo, utilizando auto_increment_increment = 10 e auto_increment_offset = 3, os números gerados quando inserirmos três registros serão 3, 13 e 23. Utilizando 10 e 7, obteremos 7, 17, 27 e assim por diante.

Para um array de quatro nós, configuramos o auto_increment_increment com 10 para cada nó e o auto_increment_offset para 1 no primeiro nó, 2 para o segundo nó e assim por diante.

Isto está teoricamente claro, porém, ainda não está claro como iremos transformar estes servidores em nós peer-to-peer. A resposta é uma replicação circular, onde cada nó é o mestre do nó seguinte e escravo do nó anterior."

A exibição deste artigo foi interrompida.

Este é um post disponível para assinantes MVP

Este post também está disponível para assinantes da SQL Magazine DIGITAL
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!