Avançar para o conteúdo principal
BlogBases de dadosArquitectura de Referência de Base de Dados Galera para MySQL e MariaDB

Arquitetura de referência de base de dados Galera para MySQL e MariaDB

Base de dados Galera para imagem de cabeçalho MySQL

É uma boa prática construir um plano antes de desenvolver a sua aplicação. Comece por definir os principais objectivos empresariais, recolher requisitos, avaliar uma potencial pilha de tecnologia e compreender as integrações. No final do processo, deverá ter um esboço da arquitectura de referência da sua aplicação, que actua como um plano para implementar os componentes da sua infra-estrutura e define a forma como os dados fluem entre esses componentes.

Neste exemplo, estamos a rever o design de uma base de dados utilizando a Galera para o MySQL e a MariaDB. As bases de dados são componentes de missão crítica de muitas aplicações. Este valioso activo depende da redundância para manter viva a sua carga de trabalho. Um único ponto de falha pode ter um impacto negativo nas operações comerciais, nos acordos de tempo de funcionamento, e na experiência global do utilizador. 

Utilizando arquitecturas de referência como guia, pode construir bases de dados resilientes e implementações de aplicações que escalam horizontalmente (sem tempo de paragem) à medida que o seu negócio cresce.

O que é Arquitectura de Referência?

As arquitecturas de referência são diagramas técnicos reutilizáveis que incorporam princípios de concepção comuns e as melhores práticas da indústria para a implementação de soluções. Uma arquitectura de referência de nuvens altamente abismada representa conexões entre as várias instâncias computacionais, equilibradores de carga, armazenamento, redes definidas por software e assim por diante - o valor das suas bases de dados torna-a uma área chave de enfoque aqui.

Bases de dados e Arquitectura de Referência

O principal objectivo é acrescentar redundância e evitar que a base de dados seja um único ponto de falha. Existem diferentes formas de alcançar este objectivo, dependendo das restrições de aplicação e de carga de trabalho. Por exemplo, uma aplicação pode ter um melhor desempenho ao dividir leituras e escritas num modelo de replicação primária-secundária. Uma necessidade de operações de escrita em escala exigiria uma estratégia com múltiplas primárias.

Outras considerações incluem o volume de dados, conformidade com ACID, processo de failover/eleição (manual ou automático), número esperado de ligações de clientes, e a tecnologia de base de dados escolhida. Estas considerações moldarão a solução de base de dados e formarão a imagem mais ampla de como estas peças funcionam em conjunto na sua arquitectura de referência.

Quando utilizar Galera

Galera é uma solução de base de dados de alta disponibilidade gratuita e de código aberto que é simples de gerir e não depende de um único fornecedor de nuvens. Se a sua tecnologia de base de dados é MySQL, ou um dos seus garfos como MariaDB ou Percona, recomendamos vivamente a Galera como uma solução durável e portátil.

Vantagens do Aglomerado Galera

  • Falhas do Nó - Previne as condições de fraccionamento do cérebro, invocando um quórum ponderado para eleger um componente primário no caso de falhas do nó.
  • Multi-Primary, Active-Active Cluster - Ler e escrever em qualquer nó do aglomerado.
  • Consistência de dados - Utiliza replicação síncrona baseada na certificação para garantir a conformidade ACID.
  • Provisionamento automático de nós - Quando os nós falhados se recuperam, ou quando novos nós se juntam ao cluster, são automaticamente postos em sincronia com o estado do componente primário utilizando Transferências de Estado Instantâneas (SST) ou Transferências de Estado Incrementais (IST).

Limitações do aglomerado de Galera

  • Não apoia o MyISAM - apenas apoia o motor InnoDB. As escritas para outros tipos de tabelas, incluindo tabelas de sistema, não são replicadas.
  • Formato da tabela - As tabelas sem chaves primárias não podem ser apagadas ou devidamente replicadas.
  • Consideração lógica - A lógica de aplicação pode precisar de ser reescrita para evitar o uso de bloqueio explícito da mesa.
  • Escalabilidade de escrita - Todos os nós devem certificar que podem escrever antes de se comprometerem, portanto, o desempenho de escrita diminui à medida que o agrupamento cresce. Recomendamos manter o tamanho do agrupamento em três nós, o suficiente para ter quórum e um desempenho de escrita óptimo

Eliminar pontos únicos de falha

Utilizemos o exemplo de uma pilha tradicional de LEMP, onde o software de aplicação e a base de dados foram separados em diferentes instâncias computacionais em preparação para a escala futura. Essa configuração pode parecer-se com isto:

Diagrama: Um servidor de aplicação e um servidor de base de dados MySQL estão ligados em segurança usando uma VLAN.

A separação das preocupações é uma boa prática, e certamente ajuda a apoiar a escalabilidade; mas a falta de redundância faz dos servidores de bases de dados e de aplicações um único ponto de falha. Podemos melhorar esta estrutura para eliminar esses pontos únicos de falha e construir a arquitectura de referência global.

Configuração simples do Galera Cluster com VLAN & Cloud Firewalls

Um aglomerado Galera aumenta a camada de base de dados para três nós com replicação síncrona entre eles. Podemos utilizar uma VLAN Linode para isolar o tráfego de replicação das redes públicas e privadas partilhadas, e uma Cloud Firewall para restringir o acesso a partir do exterior da VLAN. Os nós Galera partilham um endereço IP flutuante de modo a que, se um falhar, outro seja capaz de assumir os pedidos de serviço para o servidor de aplicações desconhecido.

Diagrama: Um servidor de aplicação aponta para um IP flutuante, que se liga a um cluster de base de dados MySQL Galera que fornece replicação síncrona para a base de dados de produção. Todos os componentes estão contidos dentro de uma VLAN.

A camada de base de dados está agora altamente disponível. O próximo ponto a focar é a abordagem ao servidor de aplicação. Este processo é simples para apátridas aplicações, mas é necessário ter em consideração as aplicações que são stateful. Dependendo da forma como o estado é mantido, poderá ser necessário refactor de código e/ou implementar replicação de ficheiros com ferramentas como Unison ou Gluster. Para este exemplo, assumir, excepto para os ficheiros de sessão temporários, que o estado da aplicação é mantido pela base de dados.

Equilíbrio de carga e replicação de aplicação

O balanceamento de carga dá à sua aplicação alta disponibilidade e escalabilidade horizontal, mas uma única instância de balanceamento de carga também cria um único ponto de falha. A redundância continua a ser um componente crítico desta implementação. Os Linode NodeBalancers fornecem uma solução pronta e altamente disponível para facilitar a aderência da sessão, monitorização da saúde, e distribuição dos pedidos dos clientes a um conjunto de nós de aplicação backend.

Diagrama: Um equilibrador de carga distribui o tráfego entre dois servidores de aplicação, que se ligam ambos ao aglomerado Galera para a base de dados de produção. São mostradas três réplicas. Todos os componentes estão contidos dentro da mesma VLAN.

Se um servidor de aplicações cair, o NodeBalancer começará apenas a dirigir o tráfego para o nó saudável. Logo que o nó não saudável recupere, retomará as ligações de equilíbrio como antes. Isto torna fácil adicionar, remover, ou actualizar servidores de aplicação sem tempo de inactividade, e devido à solução activa fornecida pela Galera, qualquer nó de aplicação pode ler/escrever em qualquer nó de base de dados.

A equipa de Engenharia de Soluções da Linode partilha estruturas, guias, e ferramentas como esta para desenvolver aplicações com as melhores práticas em mente. Leia mais sobre os benefícios de alta disponibilidade proporcionados pelos aglomerados de Galera. Se estiver pronto para começar a construir isto na Linode, consulte o nosso guia para a criação de clusters MariaDB com a Galeria, Debian, e Ubuntu.


Comentários

Deixe uma resposta

O seu endereço de correio electrónico não será publicado. Os campos obrigatórios estão marcados com *