Alta disponibilidade com Galera Cluster

Para o administrador de bancos de dados que já está acostumado a trabalhar com servidores MySQL, é sabido que um dos assuntos que mais se debate internet e mundo afora é a replicação de dados que, de maneira nativa, já vem disponível no MySQL desde sua versão 4. Esse debate foca principalmente na melhor maneira de expandir este recurso sem que haja perda na confiabilidade de seu funcionamento e perda da consistência dos dados replicados, independente da topologia a ser utilizada pelo ambiente.

Considerando os tipos ou protocolos de replicação que temos hoje disponíveis nativamente no MySQL, podemos citar:

· replicação assíncrona: que é de longe a mais utilizada, onde um servidor atua como MASTER com vários SLAVES;

· replicação semi-síncrona: que além de um servidor atuar como MASTER com vários SLAVES, o servidor MASTER também aguarda a confirmação da aplicação da transação atual por um dos SLAVES para então iniciar a execução da próxima. Isso seria uma espécie de acknowledge (i.e. ack) que é enviado ao servidor mestre pelo servidor escravo;

· replicação síncrona: presente na solução conhecida como MySQL Cluster (NDB Cluster), onde os vários nós ou servidores são organizados como membros de um cluster e cada transação executada em qualquer dos SQL/App nodes ou nós de aplicação utilizam Two Phase Commit, executando no nó onde ela foi iniciada e posteriormente no armazenamento de dados do cluster. Ao final da execução é retornado um OK.

Enquanto o MySQL Cluster utiliza o termo “nó” ou “nodo” para cada uma das máquinas que são interligadas, a replicação admite que cada máquina ou é um servidor MASTER ou SLAVE, onde cada MASTER tem vários SLAVES e um SLAVE tem apenas um MASTER. Isso era assim até o lançamento, no MySQL 5.7 DMR 6, de um outro tipo de replicação denominado MultiSource/MultiChannel Replication, onde cada SLAVE pode ter vários MASTERS.

Dos três tipos de replicação nativos citados, fica evidente uma escala entre aquele que tem maior (assíncrono) e menor (síncrono) poder de processamento de transações. Por outro lado, precisamos analisar também qual é o método que permite maior confiabilidade e consistência da informação. Nesse caso, a escala é inversamente proporcional, pois o método síncrono é o mais seguro, seguido pelo semi-síncrono e, finalmente, pelo assíncrono.

Além das funcionalidades nativas do MySQL, existem várias empresas que investem em produtos para entregar replicação mais eficiente, mais confiável, de várias formas e topologias, resultando em maior resiliência em operações de failover e switchover (processo de detecção de falha e troca de um servidor MASTER para um dos SLAVES existentes). Todo esse processo pode não ser trivial dependendo da quantidade de servidores a serem analisados no momento de uma falha, pois nada impede de um servidor ter um número de transações maior que outro e isso pode trazer problemas de inconsistências e falta de confiabilidade no método de replicação adotado (Errant Transaction).

Foi pensando em toda essa conceituação que a empresa Finlandesa Codership Oy iniciou um projeto denominado Galera Cluster, que faz uso da interface aberta do (pluggable database) MySQL para se conectar a produtos externos e orquestrar o seu funcionamento. Uma vez adicionada a nova camada de controle dos dados e feitas algumas configurações, os servidores já poderão ser agrupados em um cluster. Nesse sentido, teríamos um ambiente com replicação entre vários servidores chamados de nós. Estes trabalham em replicação MASTER/MASTER, com:

· validação de pacotes (Write-Sets) através de replicação baseada em certificação;

· controle de valores auto incremento (PK) para que não haja violação de chaves primárias definidas com a propriedade auto_increment.

Isto permite realizar todo tipo de leitura e escrita de dados em qualquer um dos componentes do cluster, seja est ...