Artigos Banco de Dados Alta disponibilidade com Galera Cluster
Por que eu devo ler este artigo:Devido ao grande volume de informação que é gerado nos dias atuais e também à necessidade de sistemas estarem mais tempo disponíveis para melhor atender aos clientes, é preciso que os administradores de bancos de dados MySQL estejam preparados para lidar com alta disponibilidade e, principalmente, para permitir que a tecnologia acompanhe o crescimento dos negócios. Neste contexto, este artigo apresenta em detalhes como obter alta disponibilidade e escalabilidade em seu ambiente MySQL utilizando o Galera Cluster. O Galera Cluster é uma camada de abstração de dados que, se adicionada ao MySQL, possibilita que vários servidores de bancos de dados sejam organizados de forma interligada onde cada máquina é reconhecida como um nó de um 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 este localizado em uma LAN ou WAN.

Galera Cluster

O Galera Cluster, que tem como seu coração a API denominada WSREP (ou Write-Set Replication API), é uma camada de abstração de dados que, se adicionada ao MySQL, possibilita que vários servidores de bancos de dados sejam organizados de forma interligada onde cada máquina é reconhecida como um nó de um cluster.

O cluster pode ser formado por N servidores físicos e/ou virtuais. Tal organização faz com que não exista a necessidade de failover dentro de um mesmo cluster, pois todos os servidores de bancos de dados MySQL que compõem a implementação possuem o mesmo conjunto de dados. A obtenção do mesmo conjunto de dados é realizada através de uma replicação denominada virtualmente síncrona, processo este que é umas das principais características do produto. Falaremos mais sobre sincronia virtual e transações mais à frente.

A adição das configurações para habilitação da API do Galera Cluster ao MySQL é realizada através do arquivo de configuração do próprio MySQL, geralmente localizado em /etc ou /etc/mysql. Sabemos que toda vez que o MySQL é iniciado, o arquivo de configuração é lido e as variáveis com seus respectivos valores são carregadas em memória. A API tem suas variáveis que devem ser adicionadas a tal arquivo para que seu plugin possa ser carregado e suas configurações se tornem disponíveis ao MySQL através de algum cliente.

A WSREP API, por sua vez, ainda conta com outros dois componentes:

· A WSREP Hook, que é o conector de integração à extensão do modelo nativo de replicação do MySQL;

· A função dlopen() que é quem provê o canal de integração entre MySQL e o conector WSREP Hook.

Além disso, existe ainda o Galera Replication Plugin. Este é responsável pelo processo de certificação, replicação e comunicação entre os nós do cluster, utilizando um framework chamado Group Communication. Ele possibilita a utilização de sincronia virtual que mantém os nós do cluster atualizados em uma fração de segundos e gerencia a adesão de novos membros ao cluster. Seu objetivo é manter todos os nós atualizados com relação aos dados já confirmados no nó de origem de cada transação executada no cluster.

O principal protocolo utilizado para replicação, troca de mensagens e adesão ao cluster por novos membros é o TCP. O protocolo UDP pode ser utilizado para replicação de dados em LAN.

Além dos componentes do Galera Cluster citados (todos estão em um plugin que é configurado para ser lido na inicialização do MySQL conforme configuração adicionada em seu arquivo de configuração), ainda se faz necessário a instalação da suíte de backup Percona Xtrabackup, que é uma evolução do antigo InnoDB Hot Backup. Existe então uma integração entre MySQL, Galera Plugin e Xtrabackup para fazer com que novos nós ou mesmo nós que tiveram uma parada, recebam o conjunto de dados ou SNAPSHOT de forma automática, sendo tal SNAPSHOT incremental ou completo (backup incremental ou full). Trataremos sobre provisionamento de novos nós, ou mesmo, retorno de um nó a um cluster após uma parada problemática um pouco mais à frente.

Conceitos e estudos que deram origem ao produto

Normalmente em um esquema ou topologia de replicação do tipo MASTER/SLAVE, a informação é escrita no MASTER que roda em um servidor A. Essa informação é então replicada em forma de stream para um outro servidor B, onde roda um outro servidor de banco de dados que recebe tais informações e mantém o mesmo estado em relação aos dados do MASTER. Aqui, os dois servidores estão em um mesmo ponto no tempo com relação aos dados. Temos nesse cenário um tipo de banco de dados em cluster por obter a mesma informação sendo sincronizada em mais de um servidor físico. Um problema que podemos observar é que cada operação é então executada em forma de fila, sendo a replicação de dados um stream de alterações que são disponib ...

Quer ler esse conteúdo completo? Tenha acesso completo