O que seria uma implementação de cluster galera estável, à prova de falhas e escalável

Question

Contexto: Estamos usando um cluster MariaDB Gallera com (apenas) 2 nós principais para um aplicativo da web. Ontem à noite tivemos uma falha de energia e agora não conseguimos recuperar os dados e descobrimos que o banco de dados estava corrompido nos dois nós. Nossa impressão inicial sobre essa configuração foi se um nó cair, o outro agiria rapidamente como o nó primário.

Minhas perguntas são,

1. Existe uma maneira de configurar um cluster para que sempre haja um nó de backup que será automaticamente replicado se um dos nós ficar inativo? Especialmente se houver uma falha de energia.

2. Qual seria a implementação correta do cluster da galeria?

Answer 1

Estamos usando um cluster Galera com 5 nós que têm um balanceador de carga na frente deles, que está continuamente verificando todos os nós. Nossa configuração é que só temos um dos nós servindo um destino de gravação e leitura para as conexões do balanceador de carga e os outros nós estão em espera ativa. Mas é claro que o Galera também suporta multi master read e write, para que você possa ajustá-lo ao seu gosto.

O tamanho mínimo do cluster precisa ser três, já que é necessário um número ímpar para evitar uma situação de divisão de cérebro quando a conexão entre os nós fica inativa por qualquer motivo. (Você também pode usar um arbitrador, mas a configuração mais fácil é apenas usar pelo menos 3 nós de cluster apropriados.) Usamos 5 nós para facilitar as atualizações no cluster e aumentar a resiliência.

O Galera também suporta um cluster através da WAN, mas isso requer algum ajuste extra nas configurações do servidor para não destruir o desempenho do servidor. Normalmente, um cluster com mais de 3 nós que possuem rede e energia redundantes deve ser adequado para os aplicativos.

Algo que você não disse em sua pergunta é o tipo de mecanismo de banco de dados que você está usando em seu cluster Galera. Vendo que você tem corrupção, eu acho que é provavelmente MyISAM? Se for esse o caso, você precisa migrar para o InnoDB, já que o MyISAM não é suportado pela Galera. Ele também tem outros benefícios, como a escrita mais resiliente, que evita a corrupção de dados, mesmo no caso improvável de o cluster realmente se desfazer e você precisar restaurar o banco de dados.

    

Answer 2

A resposta para a primeira pergunta, como na maioria dos problemas da computação, é: sim, se você tiver recursos e tempo suficientes. Se o cluster estiver em algum tipo de ambiente de datacenter, esperamos que tenha algum tipo de interface de gerenciamento fora de banda, como NICs de gerenciamento dedicado e / ou um sistema KVM.

Soluções modernas de gerenciamento de datacenter, como Datacenter Manager da Intel ou Sistemas de gerenciamento de datacenters da Raritan oferecem aos usuários a capacidade de configurar políticas para reinicializar sistemas automaticamente após uma falha de energia, enviar notificações e, potencialmente, até começar a girar nó failover externo ou baseado em nuvem. No entanto, existe potencialmente um grande custo e nível de especialização necessários para configurar e configurar todos os aspectos desse tipo de rede de segurança, o que requer muitos equipamentos, e testar e preparar completamente é difícil sem algum tempo de inatividade.

Outra ferramenta comum de gerenciamento de nós é o Nagios , que permite o gerenciamento e controle remoto de energia.

Além das opções de gerenciamento in-band e out-of-band, configure um servidor de gerenciamento de configuração usando uma ferramenta CM como Sal ou < O Chef ajudaria a garantir que os nós fossem configurados adequadamente e simplificasse bastante a tarefa de provisionar novos nós, mesmo em ambientes estranhos ou não. ambientes remotos. Os requisitos de armazenamento e banco de dados, bem como o ambiente de rede, ajudarão a determinar a arquitetura de cluster apropriada, especialmente no que diz respeito a armazenamento, energia e backups. Em alguns casos, pode ser valioso gerar clones do kickstart ou algum tipo de ajuda de instalação semelhante, como o AutoYaST, nos sistemas SUSE. Isso permitiria construir rapidamente nós limpos e importar dados necessários de instantâneos ou backups no caso de uma falha de hardware.

Salvar imagens personalizadas do sistema criadas com o sistema KIWI Build que importa, monta ou copia dados necessários é outra opção. O uso do KIWI permitiria que você cria imagens que podem ser implantadas em vários cenários, incluindo VMs, PXE, DVD / USB inicializável e muito mais. Projetar a imagem personalizada perfeita para suas necessidades usando o KIWI ou alguma outra ferramenta de compilação do sistema operacional pode ser bastante benéfica por diversos motivos.

Ser mais específico sobre a segunda questão é difícil sem saber quanto tempo você consideraria aceitável. A configuração e os recursos necessários para um cluster de alta disponibilidade de vários locais com backups remotos adicionais, failover e recuperação automáticos são drasticamente diferentes daqueles que seriam necessários para um cluster em que "alta disponibilidade" significa se a construção em que o cluster reside poder e internet precisa funcionar. Espero que algumas das informações sejam úteis.