Pular para o conteúdo principal
BlogBancos de dadosGalera Arquitetura de referência de banco de dados para MySQL e MariaDB

Arquitetura de referência de banco de dados do Galera para MySQL e MariaDB

Banco de dados Galera para imagem de cabeçalho MySQL

É a melhor prática para construir um plano antes de desenvolver sua aplicação. Comece definindo as principais metas comerciais, coletando requisitos, avaliando uma potencial pilha de tecnologia e compreendendo integrações. No final do processo, você deve ter um esboço da arquitetura de referência de seu aplicativo, que atua como um plano para implementar os componentes de sua infra-estrutura e define como os dados fluem entre esses componentes.

Neste exemplo, estamos revisando um projeto de banco de dados utilizando Galera para MySQL e MariaDB. Os bancos de dados são componentes de missão crítica de muitas aplicações. Este valioso ativo depende de redundância para manter viva sua carga de trabalho. Um único ponto de falha pode afetar negativamente as operações comerciais, os acordos de tempo de atividade e a experiência geral do usuário. 

Usando arquiteturas de referência como guia, você pode construir bancos de dados e implementações de aplicações resilientes que escalam horizontalmente (sem tempo ocioso) à medida que seu negócio cresce.

O que é Arquitetura de Referência?

As arquiteturas de referência são diagramas técnicos reutilizáveis que incorporam princípios comuns de projeto e melhores práticas da indústria para a implementação de soluções. Uma arquitetura de referência de nuvem altamente abstrata retrata conexões entre as várias instâncias de computação, balanceadores de carga, armazenamento, redes definidas por software e assim por diante - o valor de seus bancos de dados faz dela uma área chave de foco aqui.

Bancos de dados e arquitetura de referência

O objetivo principal é acrescentar redundância e evitar que o banco de dados seja um único ponto de falha. Há diferentes maneiras de atingir este objetivo, dependendo das restrições de aplicação e de carga de trabalho. Por exemplo, uma aplicação pode ter um melhor desempenho dividindo leituras e escritas em um modelo de replicação primária secundária. Uma necessidade de operações de redação 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 conexões de clientes e a tecnologia de banco de dados escolhida. Estas considerações moldarão a solução de banco de dados e formarão o quadro mais amplo de como estas peças funcionam juntas em sua arquitetura de referência.

Quando usar Galera

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

Vantagens do Aglomerado Galera

  • Falhas nos nós - Previne as condições de cérebro dividido invocando um quorum ponderado para eleger um componente primário no caso de falhas nos nós.
  • Multi-Primary, Active-Active Cluster - Leia e escreva em qualquer nó do cluster.
  • Consistência de dados - Utiliza replicação síncrona baseada em certificação para garantir a conformidade ACID.
  • Provisionamento automático de nós - Quando os nós falhos se recuperam, ou quando novos nós entram no cluster, eles são automaticamente sincronizados com o estado do componente primário usando Transferências de Estado Instantâneas (SST) ou Transferências de Estado Incrementais (IST).

Limitações do Aglomerado Galera

  • Não há suporte MyISAM - suporta apenas 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 ser reescrita para evitar o uso de travamento 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 quorum e desempenho de escrita ideal.

Eliminar pontos únicos de falha

Vamos usar o exemplo de uma pilha LEMP tradicional, onde o software aplicativo e o banco de dados foram separados em diferentes instâncias computacionais em preparação para escala futura. Essa configuração pode se parecer com isto:

Diagrama: Um servidor de aplicação e um servidor de banco de dados MySQL são conectados com segurança usando uma VLAN.

A separação das preocupações é uma melhor prática e certamente ajuda a suportar a escalabilidade; mas a falta de redundância faz dos servidores de banco de dados e de aplicações um único ponto de falha. Podemos melhorar esta estrutura para eliminar estes pontos únicos de falha e construir a arquitetura geral de referência.

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

Um aglomerado Galera aumenta a camada de banco de dados para três nós com replicação síncrona entre eles. Podemos usar uma VLAN Linode para isolar o tráfego de replicação de redes públicas e privadas compartilhadas, e um Firewall Cloud para restringir o acesso de fora da VLAN. Os nós da Galera compartilham um endereço IP flutuante para que, se um falhar, outro seja capaz de assumir as solicitações de serviço para o servidor de aplicações desconhecido.

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

A camada de banco de dados está agora altamente disponível. O próximo ponto a ser focado é o endereçamento ao servidor de aplicação. Esse processo é simples para apátridas aplicações, mas é preciso levar em consideração as aplicações que são stateful. Dependendo de como o estado é mantido, você pode precisar refatorar o código e/ou implementar a replicação de arquivos com ferramentas como Unison ou Gluster. Para este exemplo, suponha, com exceção dos arquivos temporários de sessão, que o estado da aplicação seja mantido pelo banco de dados.

Balanceamento 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 sendo 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, o monitoramento da saúde e a distribuição das solicitações do cliente para um conjunto de nós de aplicação backend.

Diagrama: Um equilibrador de carga distribui o tráfego entre dois servidores de aplicação, ambos conectados ao cluster Galera para o banco de dados de produção. Três réplicas são mostradas. Todos os componentes estão contidos dentro da mesma VLAN.

Se um servidor de aplicação cair, o NodeBalancer começará apenas a direcionar o tráfego para o nó saudável. Assim que o nó insalubre se recuperar, ele retomará as conexões de equilíbrio como antes. Isto facilita a adição, remoção ou atualização de servidores de aplicação sem tempo de inatividade e, devido à solução ativa fornecida pela Galera, qualquer nó de aplicação pode ler/escrever em qualquer nó de banco de dados.

A equipe de Engenharia de Soluções da Linode compartilha 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 da Galera. Se você está pronto para começar a construir isto na Linode, confira nosso guia para a criação dos Clusters MariaDB com a Galeria, Debian, e Ubuntu.


Comentários

Deixe uma resposta

Seu endereço de e-mail não será publicado. Os campos obrigatórios estão marcados com *