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ções e um servidor de base de dados MySQL estão ligados de forma segura através de um 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 cluster Galera com VLAN e firewalls de nuvem

Um cluster Galera aumenta a camada de base de dados para três nós com replicação síncrona entre eles. Podemos utilizar um Linode VLAN para isolar o tráfego de replicação de redes públicas e privadas partilhadas, e um Cloud Firewall para restringir o acesso de fora do VLAN. Os nós Galera partilham um endereço IP flutuante para que, se um falhar, outro possa assumir o fornecimento de pedidos ao servidor de aplicações desconhecido.

Diagrama: Um servidor de aplicações 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 num 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 balanceador de carga também cria um único ponto de falha. A redundância continua sendo um componente crítico dessa implementação. O Linode NodeBalancers fornece uma solução pronta para uso e altamente disponível para facilitar a aderência da sessão, o monitoramento da integridade e a distribuição de solicitações de clientes para um conjunto de nós de aplicativos de back-end.

Diagrama: Um balanceador de carga distribui o tráfego entre dois servidores de aplicações, que se ligam ao cluster Galera para a base de dados de produção. São apresentadas três réplicas. Todos os componentes estão contidos no mesmo 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 *