Arquiteturas para alta disponibilidade de clusters MySQL no Compute Engine

Last reviewed 2024-02-21 UTC

Neste documento, descrevemos várias arquiteturas que fornecem alta disponibilidade (HA, na sigla em inglês) para implantações do MySQL no Google Cloud. HA é a medida da resiliência do sistema em resposta a uma falha de infraestrutura subjacente. Neste documento, HA aborda a disponibilidade de clusters MySQL em uma única região da nuvem.

Este documento é destinado a administradores de bancos de dados, arquitetos de nuvem e engenheiros de DevOps, que querem aprender como aumentar a confiabilidade do nível de dados do MySQL, melhorando o tempo de atividade geral do sistema. Este documento é destinado a você se estiver executando o MySQL no Compute Engine. Se você usa o Cloud SQL para MySQL, este documento não é destinado a você.

Para um sistema ou aplicativo que requer um estado permanente para lidar com solicitações ou transações, a camada de permanência de dados precisa estar disponível para processar com êxito solicitações de mutações ou consultas de dados. Se o aplicativo precisar interagir com o nível de dados para solicitações de serviço, qualquer inatividade no nível de dados impedirá que o aplicativo execute as tarefas necessárias.

Dependendo dos objetivos de nível de serviço (SLOs, na sigla em inglês) do sistema, talvez você precise de uma topologia de arquitetura que forneça um nível mais alto de disponibilidade. Há mais de uma maneira de conseguir HA, mas, em geral, você provisiona infraestruturas redundantes que podem ser rapidamente acessíveis para o aplicativo.

Neste documento, falamos sobre os tópicos a seguir:

  • Definir termos que ajudam a entender os conceitos de banco de dados de HA.
  • Ajudar a entender várias opções de topologias de MySQL de HA.
  • Fornecer informações contextuais para ajudar a entender o que considerar em cada opção.

Terminologia

Há vários termos e conceitos que são padrão do setor e úteis para entender as finalidades além do escopo deste documento.

Replicação. O processo pelo qual as transações de gravação (INSERT, UPDATE ou DELETE) são capturadas, registradas e aplicadas em série a todos os nós do banco de dados na topologia, de forma confiável.

Nó de origem. Todas as gravações no banco de dados precisam ser direcionadas para um nó de origem. O nó de origem oferece uma leitura com o estado mais atualizado de dados permanentes.

Nó de réplica. Uma cópia on-line do nó de origem do banco de dados. As alterações são replicadas quase de modo síncrono do nó de origem para nós de réplica. É possível fazer a leitura a partir de nós de réplica, considerando que os dados podem ter um ligeiro atraso devido ao lag de replicação.

Lag de replicação. Uma medida de tempo que expressa a diferença entre quando uma transação é aplicada à réplica e quando ela é aplicada ao nó de origem.

Tempo de atividade. A porcentagem de tempo que um recurso está funcionando e capaz de enviar uma resposta a uma solicitação.

Detecção de falhas. O processo de identificar que ocorreu uma falha na infraestrutura.

Failover. O processo em que a infraestrutura de backup ou espera (neste caso, o nó de réplica) é promovida tornando-se a infraestrutura principal. Em outras palavras, durante o failover, o nó de réplica torna-se o nó de origem.

Objetivo de tempo de recuperação (RTO, na sigla em inglês). A duração aceitável do ponto de vista comercial, em termos de tempo real decorrido, para que o processo de failover do nível de dados seja concluído.

Fallback. O processo de restabelecer o antigo nó de origem após um failover.

Autocorreção. A capacidade de um sistema resolver problemas sem ações externas de um operador humano.

Partição de rede. Uma condição quando dois nós em uma topologia, por exemplo, os nós de origem e de réplica, não podem se comunicar entre si pela rede.

Dupla personalidade. Uma condição que ocorre quando dois nós acreditam simultaneamente que são o nó de origem.

Grupo de nós. Um conjunto de tarefas de recursos de computação que fornecem um serviço. Neste documento, esse serviço é o nível de permanência de dados.

Nó de quórum ou testemunha. Um recurso de computação separado que ajuda um grupo de nós a determinar o que fazer quando ocorre uma condição de dupla personalidade.

Eleição de origem ou líder. O processo pelo qual um grupo de nós cientes uns dos outros, incluindo nós de testemunha, determina qual nó deve ser o nó de origem.

Grupo de nós. Um conjunto de tarefas de recursos de computação que fornecem um serviço. Neste documento, esse serviço é o nível de permanência de dados.

Espera ativa. Um nó que representa uma cópia fechada de outro nó de origem e pode se tornar o novo nó de origem com tempo de inatividade mínimo.

Quando considerar uma arquitetura de alta disponibilidade

As arquiteturas de HA aumentam a proteção contra inatividade no nível de dados. Entender sua tolerância à inatividade e as respectivas vantagens e desvantagens das várias arquiteturas é fundamental para escolher a opção certa para seu caso de uso comercial.

Use uma topologia de HA quando quiser fornecer maior tempo de atividade no nível de dados para atender aos requisitos de confiabilidade de suas cargas de trabalho e serviços. Para ambientes em que determinado valor de inatividade é tolerado, uma topologia de HA gera custos e complexidades desnecessárias. Por exemplo, ambientes de desenvolvimento ou teste raramente precisam de alta disponibilidade de nível de banco de dados.

Considere seus requisitos de alta disponibilidade

O custo é uma consideração importante, porque o esperado é que a infraestrutura de computação e armazenamento custem pelo menos o dobro para oferecer HA. Ao avaliar as possíveis opções de HA do MySQL, considere as seguintes perguntas:

  • Quais serviços ou clientes dependem do seu nível de dados?
  • Qual é seu orçamento operacional?
  • Qual será o custo para sua empresa em caso de inatividade no nível de permanência de dados?
  • O processo precisa ser automatizado quanto?
  • Que nível de disponibilidade você espera alcançar? 99,5%, 99,9% ou 99,99%?
  • Com que rapidez você precisa fazer o failover? Qual é seu RTO?

Os itens a seguir contribuem para o tempo de recuperação e precisam ser considerados ao definir seu RTO:

  • Detecção da interrupção
  • Prontidão da instância de máquina virtual (VM) secundária
  • Failover de armazenamento
  • Tempo de recuperação do banco de dados
  • Tempo de recuperação do aplicativo

Arquitetura de alta disponibilidade do MySQL

No nível mais básico, HA no nível de dados consiste no seguinte:

  • Um mecanismo para identificar que ocorreu uma falha no nó de origem.
  • Um processo para realizar um failover em que o nó de réplica é promovido para nó de origem.
  • Um processo para alterar o roteamento de consultas, de modo que as solicitações de aplicativos cheguem ao novo nó de origem.
  • Ou um método para voltar à topologia original usando nós de origem e de réplica.

Neste documento, falamos sobre as três arquiteturas de HA a seguir:

Além da falha de infraestrutura, cada uma dessas arquiteturas pode ajudar a minimizar a inatividade no caso improvável de uma interrupção de zona. Você usa essas arquiteturas com alterações no Sistema de Nome de Domínio (DNS, na sigla em inglês) para fornecer HA multirregional e proteger contra interrupção de serviços regionais, mas esse tópico está fora do escopo deste documento.

Alta disponibilidade com Persistent Disks regionais

HA no nível de dados sempre depende de algum tipo de replicação de dados. A replicação mais simples é aquela que você não precisa gerenciar.

Com a opção de armazenamento Persistent Disk regional do Compute Engine, é possível provisionar um dispositivo de armazenamento em blocos que fornece replicação de dados síncrona entre duas zonas em uma região. Os Persistent Disks regionais fornecem um elemento básico fundamental para a implementação de serviços de HA no Compute Engine.

O diagrama a seguir ilustra a arquitetura de HA com Persistent Disks regionais.

Arquitetura para usar Persistent Disks regionais para alcançar alta disponibilidade.

Se a instância de VM do nó de origem ficar indisponível devido a uma falha de infraestrutura ou interrupção de zona, force a anexação do Persistent Disk regional a uma instância de VM na zona de backup da mesma região.

Para executar essa tarefa, é preciso seguir um destes procedimentos:

  • Inicie outra instância de VM na zona de backup em que o acesso ao disco permanente regional compartilhado esteja disponível.
  • Manter uma instância de VM de espera ativa na zona de backup. Uma instância de VM de espera ativa é aquela em execução idêntica à instância que você está usando. Depois de anexar o disco permanente regional, será possível iniciar o mecanismo de banco de dados.

Se a interrupção do serviço de dados for identificada imediatamente, a operação de anexação forçada normalmente será concluída em menos de um minuto, o que significa que um RTO medido em minutos pode ser atingido.

Se sua empresa puder tolerar a inatividade adicional necessária para você detectar e comunicar uma interrupção e para realizar o failover manualmente, não será necessário automatizar o processo.

Se a tolerância de RTO for menor, será possível automatizar o processo de detecção e failover. Se você automatizar essa arquitetura, o sistema será mais complicado, porque haverá vários casos extremos no processo de failover e fallback que você precisará considerar. Para mais informações sobre uma implementação totalmente automatizada dessa arquitetura, consulte a configuração de alta disponibilidade do Cloud SQL.

Vantagens

Há várias vantagens em alcançar HA com o uso de Persistent Disks regionais graças aos seguintes recursos:

  • Essa arquitetura oferece proteção simultânea contra vários modos de falha: falha na infraestrutura do servidor da zona principal, degradação do armazenamento em blocos de zona única ou interrupção total da zona.
  • A replicação de camada de banco de dados ou aplicativo não é necessária porque os Persistent Disks regionais fornecem replicação de dados contínua e síncrona no nível de bloco, que é totalmente gerenciada pelo Google Cloud. Um Persistent Disk regional detecta automaticamente erros e lentidão, alterna o modo de replicação e realiza a coleta de dados replicados para apenas uma zona.
  • Se houver problemas de armazenamento em uma zona principal, um Persistent Disk regional realizará automaticamente leituras da zona secundária. Essa operação pode resultar em maior latência de leitura, mas seu aplicativo pode continuar funcionando sem qualquer ação manual.

Considerações

As limitações dessa arquitetura estão relacionadas ao caráter de região única dessa topologia e a algumas das seguintes restrições herdadas de Persistent Disks regionais:

  • O Persistent Disk regional só pode ser montado em um banco de dados. Mesmo que a instância de VM do banco de dados em espera esteja em execução, essa instância não pode ser usada para exibir leituras do banco de dados.
  • A tecnologia básica por trás dessa arquitetura permite apenas a replicação entre zonas na mesma região. Consequentemente, o failover regional não é uma opção ao usar apenas essa arquitetura.
  • A capacidade de gravação do Persistent Disk regional é reduzida pela metade em comparação com os Persistent Disks zonais. Confirme se os limites de capacidade estão dentro da tolerância necessária.
  • A latência de gravação do Persistent Disk regional é um pouco maior do que a do Persistent Disk zonal. Recomendamos que você teste a carga de trabalho para verificar se o desempenho de gravação é aceitável para seus requisitos.
  • Durante um evento de falha e a transição resultante, você precisa forçar a anexação do Persistent Disk regional à VM da zona de espera. A operação de anexação forçada normalmente é executada em menos de um minuto. Por isso, considere esse tempo ao avaliar seu RTO.
  • A estimativa de RTO precisa considerar o tempo necessário para a anexação forçada do Persistent Disk regional e a detecção do sistema de arquivos de VM do disco anexado.

HA com nó de espera ativa e testemunha

Se você quiser um failover automatizado, será preciso usar uma arquitetura diferente. Uma opção é implantar um grupo de pelo menos dois nós do banco de dados, configurar a replicação assíncrona do banco de dados e iniciar os nós de testemunha para garantir que um quórum seja atingido durante a eleição do nó de origem.

Os processos de nós de bancos de dados de origem gravam transações e exibem consultas de leitura. O processo de replicação do banco de dados transmite alterações para o nó de réplica de espera ativa on-line.

Como o nó de testemunha pode ser uma máquina virtual pequena, ele oferece um mecanismo de baixo custo para garantir que a maioria do grupo esteja disponível para uma eleição de nó de origem.

Os nós do grupo avaliam continuamente o status dos outros nós do grupo. Os sinais que essas verificações de status consomem em intervalos de poucos segundos são chamados de sinais de funcionamento porque são usados para avaliar a integridade dos outros nós do grupo. Uma avaliação oportuna da integridade do nó de banco de dados é importante porque um nó de banco de dados de origem não íntegro precisa ser identificado rapidamente para que um failover do modo de espera ativa seja iniciado.

O quórum do grupo de nós é determinado pelo número de elementos de votação que precisam fazer parte da associação ativa do cluster para que o cluster inicie corretamente ou continue em execução. Para que um grupo de nós alcance um quórum em uma eleição de nó de banco de dados de origem, a maioria dos nós do grupo precisa participar. Para se proteger contra uma condição de dupla personalidade, o requisito da maioria garante que, em caso de partição de rede, dois grupos de votação não possam ter simultaneamente nós suficientes para votar.

A maioria do grupo consiste em (n+1)/2 nós, em que n é o número total de nós no grupo. Por exemplo, se houver três nós em um grupo, pelo menos dois nós precisarão estar funcionando para uma eleição de nó de origem. Se houver cinco nós em um grupo, pelo menos três nós serão necessários.

Os grupos são dimensionados com um número ímpar de nós caso haja uma partição de rede que impeça a comunicação entre subgrupos do grupo de nós. Se o grupo for par, há mais chances de que os subgrupos possam ter menos do que a maioria. Se o tamanho do grupo for ímpar, é mais provável que um dos subgrupos ou nenhum grupo tenha a maioria.

O diagrama a seguir compara um grupo de nós íntegro com um grupo de nós degradado.

Arquitetura comparando um grupo de nós íntegro a um grupo de nós degradado.

O diagrama mostra dois grupos de nós: um grupo de nós funcional e um grupo de nós degradado. O grupo de nós totalmente funcional e íntegro tem três membros. Nesse estado, os nós do banco de dados de origem e de réplica oferecem o propósito esperado. O quórum necessário para esse grupo de nós é dois nós.

O grupo de nós degradado mostra o estado em que os sinais de funcionamento do nó de origem não são mais enviados devido a uma falha de infraestrutura. Esse estado pode ser resultado da falha da instância do nó do banco de dados de origem ou do nó de origem ainda em execução. Por outro lado, uma partição de rede pode impedir a comunicação entre o nó de origem e os outros nós do grupo.

Independentemente da causa, o resultado é que a réplica e a testemunha determinam que o nó de origem não é mais íntegro. Nesse momento, a maioria do grupo realiza uma eleição de nó de origem, determina que o nó de espera ativa se torne o nó de origem e inicia um failover.

O diagrama a seguir mostra a replicação, o fluxo do sinal de funcionamento e a transação do banco de dados na arquitetura do nó de testemunha.

Arquitetura de uso do nó de espera ativa e testemunha para alcançar HA.

No diagrama anterior, essa arquitetura de alta disponibilidade depende do nó de réplica de espera ativa para iniciar rapidamente o processamento de gravações de produção em um failover. Os mecanismos do failover, como a promoção do nó de origem, são executados pelos nós do banco de dados no grupo.

Para implementar essa arquitetura, considere os dois projetos a seguir:

Vantagens

A arquitetura de espera ativa tem poucas partes móveis, é simples de implantar e oferece várias vantagens:

  • Com apenas mais um nó de testemunha de baixo custo, é fornecido um failover totalmente automatizado.
  • Essa arquitetura resolve falhas de longo prazo da infraestrutura tão facilmente quanto uma falha temporária (por exemplo, devido a uma reinicialização do sistema).
  • Com uma latência de replicação associada, é fornecida alta disponibilidade multirregional.

Considerações

O failover é automático, mas as seguintes tarefas operacionais permanecem:

  • Você gerencia a replicação entre os nós de origem e de réplica.
  • Você gerencia os nós de testemunha.
  • Você precisa implantar e gerenciar o roteamento de conexão usando um balanceador de carga.
  • Sem alterações na lógica do aplicativo, que estão fora do escopo deste documento, não é possível direcionar leituras para o nó de réplica.

HA com o Orchestrator and o ProxySQL

Se você combinar os componentes de código aberto, Orchestrator e ProxySQL, terá uma arquitetura capaz de detectar interrupções e tráfego de failover automaticamente, desde um nó de origem afetado até uma réplica íntegra recém-promovida.

Além disso, é possível rotear consultas de forma transparente para os nós de leitura ou gravação apropriados para melhorar o desempenho do nível de dados em estado estável.

O Orchestrator é uma solução de failover e um gerenciador de topologia de replicação com código aberto do MySQL. O software permite detectar, consultar e refatorar topologias de replicação complexas e fornece detecção de falhas confiável, recuperação inteligente e promoção.

O ProxySQL é um proxy ciente do protocolo de banco de dados com código aberto, de alto desempenho e altamente disponível para MySQL. O ProxySQL é escalonado para milhões de conexões em centenas de milhares de servidores de back-end.

O diagrama a seguir mostra a arquitetura combinada do Orchestrator e ProxySQL.

Arquitetura usando o Orchestrator e o ProxySQL para alcançar alta disponibilidade.

Nessa arquitetura, conforme ilustrado no diagrama anterior, o tráfego vinculado ao banco de dados é roteado por um balanceador de carga interno para instâncias redundantes do ProxySQL. Essas instâncias roteiam o tráfego para uma instância de banco de dados de leitura ou gravação com base na configuração de SQLSQL.

O Orchestrator fornece as seguintes etapas de detecção e recuperação de falhas:

  1. O Orchestrator determina que o nó do banco de dados de origem não está disponível.
  2. Todos os nós de réplica são consultados para fornecer uma segunda opinião sobre o status do nó de origem.
  3. Se as réplicas fornecerem uma avaliação consistente de que a origem não está disponível, o failover continuará.
  4. Conforme definido pela topologia, o nó promovido torna-se o novo nó de origem durante o failover.
  5. Quando o failover é concluído, o Orchestrator garante que o número correto de novos nós de replicação seja provisionado de acordo com a topologia.

A replicação contínua entre o banco de dados de origem na zona A e as réplicas do banco de dados em zonas alternativas mantém as réplicas atualizadas com todas as gravações roteadas para o d.e origem O Orchestrator verifica a integridade dos bancos de dados de origem e de réplica enviando continuamente sinais de funcionamento. O estado do aplicativo Orchestrator é mantido em um banco de dados separado do Cloud SQL. Se forem necessárias alterações na topologia, o Orchestrator poderá também enviar comandos aos bancos de dados.

O ProxySQL roteia o tráfego adequadamente para os novos nós de origem e de réplica quando o failover é concluído. Os serviços continuam lidando com o nível de dados usando o endereço IP do balanceador de carga. O endereço IP virtual é alternado com perfeição do nó de origem anterior para o novo.

Vantagens

Os componentes de arquitetura e a automação oferecem as seguintes vantagens:

  • O software usado nessa arquitetura fornece vários recursos de observabilidade, incluindo gráficos de topologia de replicação e visibilidade do tráfego de consulta.
  • O ProxySQL e o Orchestrator coordenam para fornecer failover e promoção de réplica automática.
  • A política de promoção da réplica é totalmente configurável. Ao contrário de outras configurações de HA, você tem a opção de promover um nó de réplica específico para de origem em caso de failover.
  • Após um failover, novas réplicas são provisionadas declarativamente de acordo com a topologia.
  • O ProxySQL oferece um benefício suplementar de balanceamento de carga, já que faz o roteamento transparente das solicitações de leitura e gravação para os nós de origem e de réplica com base nas políticas configuradas.

Considerações

Essa arquitetura aumenta a responsabilidade operacional e gera custos de hospedagem adicionais devido às seguintes considerações:

  • O Orchestrator e o ProxySQL precisam ser implantados e mantidos.
  • O Orchestrator precisa de um banco de dados separado para manter o estado.
  • Tanto o Orchestrator quanto o ProxySQL precisam ser configurados para alta disponibilidade. Por isso, há mais complexidade de configuração e implantação.

Além disso, o Orchestrator não é compatível com replicações de várias fontes, não é compatível com todos os tipos de replicação paralela e não pode ser combinado com software de clustering, como Galera ou Percona XtraDB. Para mais informações sobre as limitações atuais, consulte as Perguntas frequentes do Orchestrator.

A seguir