Nesta série de blogs de três partes, explicaremos os detalhes e a funcionalidade de uma estrutura de alta disponibilidade (HA) para hospedagem MySQL usando replicação semissíncrona MySQL e a pilha Corosync mais Pacemaker. Na Parte I, vamos orientá-lo nos fundamentos da Alta Disponibilidade, os componentes de uma estrutura de alta disponibilidade e, em seguida, apresentar a estrutura de alta disponibilidade para MySQL.
O que é alta disponibilidade?
A disponibilidade de um sistema de computador é a porcentagem de tempo em que seus serviços estão ativos durante um período de tempo. É geralmente expresso como uma série de 9's. Por exemplo, a tabela abaixo mostra a disponibilidade e o tempo de inatividade correspondente medido ao longo de um ano.
| Disponibilidade % | Tempo de inatividade por ano |
| 90% (“um 9 “) | 36,53 dias |
| 99% (“dois 9s “) | 3,65 dias |
| 99,9% (“três 9s “) | 8,77 horas |
| 99,99% (“quatro 9s “) | 52,60 minutos |
| 99,999% (“cinco 9s “) | 5,26 minutos |
| 99,9999% (“seis 9s “) | 31,56 segundos |
O significado de Alta Disponibilidade varia de acordo com os requisitos de seu aplicativo e negócios. Por exemplo, se você não puder arcar com um tempo de inatividade de mais de alguns minutos por ano em seu serviço, dizemos que o serviço precisa ter 99,999% de alta disponibilidade.
Componentes de uma estrutura de alta disponibilidade
A essência de ser altamente disponível é a capacidade de se recuperar instantaneamente de falhas que podem ocorrer em qualquer parte de um sistema. Existem quatro componentes altamente essenciais em qualquer estrutura de alta disponibilidade que precisam trabalhar juntos de maneira automatizada para permitir essa capacidade de recuperação. Vamos analisar esses componentes em detalhes:
1. Redundância em infraestrutura e dados
Para que um serviço seja altamente disponível, precisamos garantir que haja redundância na hospedagem da infraestrutura, bem como uma redundância atualizada cópia dos dados que o serviço usa ou fornece. Isso funciona como um serviço de espera pronto para assumir o controle caso o primário seja afetado por falhas.
2. Mecanismo de detecção e correção de falhas
É extremamente importante detectar imediatamente quaisquer falhas em qualquer parte do sistema primário que possam afetar sua disponibilidade. Isso permitirá que a estrutura execute ações corretivas no mesmo sistema primário ou faça failover dos serviços para um sistema em espera.
3. Mecanismo de failover
Este componente lida com a responsabilidade de fazer failover dos serviços para sua infraestrutura de espera. Observe que, caso haja vários sistemas redundantes disponíveis, esse componente do mecanismo de failover deve identificar o sistema mais adequado entre eles e promovê-lo como serviço primário.
4. Mecanismo de redirecionamento de aplicativo/usuário
Uma vez que os sistemas em espera tenham assumido o controle como primário, esse componente garante que todas as conexões de aplicativos e usuários comecem a acontecer com o novo primário.
Estrutura de alta disponibilidade do MySQL explicada - Parte IClick To Tweet
A estrutura de alta disponibilidade para MySQL
Com base no modelo acima, usamos a seguinte estrutura de alta disponibilidade para nossa hospedagem MySQL no ScaleGrid:
- Uma configuração mestre-escravo de 3 nós usando replicação semissíncrona do MySQL para fornecer infraestrutura e redundância de dados.
- A pilha Corosync mais Pacemaker para fornecer detecção de falhas, correção e mecanismo de failover.
- Um mapeamento de DNS ou componente de IP virtual para fornecer o mecanismo de redirecionamento do aplicativo e do usuário.
Confira o diagrama abaixo para visualizar a pilha de software desta arquitetura:
Vamos revisar a funcionalidade de alguns dos principais componentes desta estrutura.
-
Corosync
O Corosync fornece uma estrutura de comunicação para os nós com transmissão confiável de mensagens entre eles. Ele forma um anel de cluster de nós e acompanha os nós que entram e saem do cluster por meio da associação ao cluster. O Corosync trabalha em estreita colaboração com o Pacemaker para comunicar sobre a disponibilidade do nó para que o Pacemaker possa tomar as decisões apropriadas.
-
Marcapasso
Também conhecido como Cluster Resource Manager (CRM), o Pacemaker garante a alta disponibilidade para MySQL em execução no cluster e detecta e trata falhas em nível de nó por meio da interface com o Corosync. Ele também detecta e trata falhas do MySQL fazendo interface com o Resource Agent (RA). O Pacemaker configura e gerencia o recurso MySQL por meio de operações de iniciar, parar, monitorar, promover e rebaixar.
-
Agente de recursos
O Agente de Recursos atua como uma interface entre o MySQL e o Pacemaker. Implementa iniciar, parar, promover, rebaixar e monitorar operações que são invocadas pelo Pacemaker. Existe um Agente de Recursos totalmente funcional chamado Percona Replication Manager (PRM) para MySQL implementado pela Percona. Isso foi aprimorado pelo ScaleGrid e está disponível em nossa página do GitHub.
-
Componente de mapeamento de DNS
O Agente de Recursos, ao concluir um failover bem-sucedido, invoca este componente que atualiza os registros DNS do servidor MySQL mestre com o endereço IP do novo mestre. Observe que os clientes sempre usam um nome DNS mestre para se conectar ao servidor MySQL e, gerenciando o mapeamento desse nome DNS para o endereço IP do mestre atual, podemos garantir que os clientes não precisem alterar suas strings de conexão ou propriedades quando há um failover.
Na Parte II desta série de blogs, você aprenderá sobre o componente crítico de redundância de dados que é obtido usando a replicação semissíncrona do MySQL. Também nos aprofundaremos nos detalhes e configurações de replicação semissíncrona que usamos para obter nosso suporte de alta disponibilidade e, por fim, analisaremos vários cenários de falha na Parte III e a maneira como a estrutura responde e se recupera dessas condições.
