
Clique aqui para ler todos os artigos desta edição
MySQL Cluster Disponibilidade total
Renato A. Golin
Quando pensamos em segurança dos dados, a primeira coisa que vem à mente é criptografia.
Esse é, de fato, um quesito fundamental da segurança, mas não é o único e, sozinho, não garante segurança alguma.
Segundo o British Standards Institute (equivalente à ISO para segurança), a segurança da informação é caracterizada pela preservação da confidencialidade, integridade e disponibilidade.
Neste artigo vamos cobrir a parte de disponibilidade, que é o maior benefício do MySQL Cluster.
O que é o MySQL Cluster?
O MySQL Cluster é uma tecnologia que foi oficialmente lançada na versão 4.1.12 do MySQL Max e ainda está sob um desenvolvimento pesado para que todas as funcionalidades do MySQL padrão sejam adicionadas ao Cluster.
Essa tecnologia é hoje, como o resto do MySQL, software livre.
Em uma replicação tradicional, o MySQL copia todos os dados do master para o slave mas sem a obrigação de garantir que os dados foram copiados corretamente. Diferentemente, o Cluster garante a integridade dos dados em todos os nós ao mesmo tempo, ou seja, o cluster se certifica que inseriu o dado em cada nó (máquinas que compõe o cluster) antes de disponibilizar esse dado para outro usuário. Isso é o que chamamos de replicação síncrona. Isso acontece por que o Cluster armazena cada pedaço do seu dado em mais de um nó ao mesmo tempo para que, quando um dos nós falhar, seus dados permaneçam acessíveis
a partir do outro nó.
Outra vantagem do Cluster é que não é compartilhada nenhuma informação sobre configuração entre os nós, ou seja, não é preciso mudar a configuração de todos os nós atuais para adicionar mais um. Com isso, fica fácil adicionar novas máquinas, sendo possível aumentar o poder de processamento do seu cluster sem a necessidade de reconfigurar todo o cluster.
Administrar tudo isso pode parecer complicado, entrar em cada máquina para configurar cada uma, mas o MySQL facilitou a vida do DBA criando um servidor de configuração que cuida de todos os parâmetros, logs, controle dos nós e adição de mais nós ao cluster. É o chamado Management Node (ou nó gerencial).
O MySQL Cluster consegue funcionar exatamente como um servidor MySQL tradicional, executando suas queries e retornando os dados obtidos como se fosse qualquer outro servidor MySQL: o Cluster é transparente para o usuário, para a sua aplicação e até para o cliente MySQL (texto ou MySQL Admin).
Resumindo: o MySQL Cluster garante a disponibilidade dos seus dados de forma síncrona e transparente, é facilmente gerenciável e escalável e ainda por cima, é livre!
Agora vamos ver quais são as peças existentes no Cluster e o que cada uma delas faz para garantir a disponibilidade dos seus preciosos dados.
Arquitetura
O Cluster é composto por três tipos diferentes de nós:
• Data Node (nó de dados): onde são armazenados seus dados;
• Management Node (nó de gerenciamento): que controla o cluster;
• SQL Node (nó SQL): onde são executadas as queries.
E dois tipos diferentes de clientes:
• MySQL Client (cliente do banco): que administra
os nós SQL (e executa queries também);
• Management Client (nó de dados): que administra o restante do cluster de banco de dados.
Essa arquitetura pode ser resumida pela Figura 1.
Figura 1. Resumo da arquitetura do MySQL Cluster.
O conceito de nó está relacionado à parte do programa que está em execução. Se uma máquina roda o programa ndbd, que é o programa relacionado ao nó de dados, esta máquina pode ser considerada um nó de dados. É possível ter mais de um nó em cada máquina como rodar o nó de gerenciamento e um nó SQL, mas a idéia é instalar cada componente do Cluster em uma máquina separada, pois afinal, estamos falando de disponibilidade! O coração do MySQL Cluster é o grupo de nós de dados.
Esses nós compartilham os dados entre si em uma arquitetura que possui dois conceitos básicos: réplicas e fragmentos.
Réplicas são o número de vezes que o dado aparecerá no cluster como um todo e Fragmentos são o número de pedaços em que essa réplica será repartida e distribuída nos nós de dados, ou seja, se tivermos duas réplicas, teremos cada dado armazenado no banco duas vezes, e se tivermos dois fragmentos, precisaremos de dois nós de dados diferentes para armazená-las.
Na Figura 2 ...