No CityMobile, usamos o banco de dados MySQL como armazenamento principal para dados persistentes. Temos vários clusters de banco de dados para vários serviços e propósitos.

A disponibilidade constante do assistente é um indicador crítico da integridade de todo o sistema e de suas partes individuais. A recuperação automática de cluster no caso de uma falha do assistente reduz bastante o tempo de resposta a incidentes e o tempo de inatividade do sistema. Neste artigo, examinarei um cluster de alta disponibilidade do MySQL baseado no MySQL Orchestrator e em endereços IP virtuais (VIP).

Solução VIP HA

Primeiro, falarei brevemente sobre como é o nosso sistema de armazenamento de dados.

Usamos o esquema de replicação clássico com um assistente somente gravação e muitas réplicas somente leitura. Um cluster pode conter um mestre intermediário - um nó que é uma réplica e um mestre para outros. Os clientes acessam réplicas através do HAProxy, que permite distribuição uniforme de carga e fácil escalabilidade. O uso do HAProxy é devido a razões históricas e agora estamos migrando para o ProxySQL.

A replicação é semi-síncrona com base emGTID. Isso significa que pelo menos uma réplica deve gravar a transação no log antes de ser considerada bem-sucedida. Esse modo de replicação fornece um equilíbrio ideal entre desempenho e segurança dos dados em caso de falha do nó principal. Basicamente, todas as alterações são transferidas do mestre para réplicas usando Row Based Replication (RBR), mas alguns nós podem ter mixed binlog format.

O orquestrador atualiza periodicamente o estado da topologia do cluster, analisa as informações recebidas e, em caso de problemas, pode iniciar o procedimento de recuperação automática. O desenvolvedor é responsável pelo próprio procedimento, pois ele pode ser implementado de várias maneiras: com base no VIP, DNS, usando serviços de descoberta de serviço ou mecanismos independentes.

Uma das maneiras mais fáceis de restaurar um assistente em caso de falha é usar endereços VIP flutuantes.

O que você precisa saber sobre esta solução antes de prosseguir:

VIP é um endereço IP que não está vinculado a uma interface de rede física específica. Quando um nó falha ou durante o trabalho agendado, podemos alternar o VIP para outro recurso com tempo de inatividade mínimo.
Liberar e emitir um endereço IP virtual é uma operação barata e rápida.
Para trabalhar com o VIP, é necessário acessar o servidor via SSH ou usar ferramentas especiais, por exemplo keepalived.

Vamos considerar possíveis problemas com o nosso mestre e imaginar como o mecanismo de recuperação automática deve funcionar.

A conectividade de rede com o mestre desapareceu ou ocorreu um problema no nível do hardware e o servidor está indisponível

, . , , .
VIP — .
. .
VIP. VIP , gratuitous ARP. / IP- MAC-, VIP. split brain .
Todas as novas conexões são redirecionadas imediatamente para o novo mestre. As conexões antigas falham, chamadas repetidas são feitas no banco de dados no nível do aplicativo.

O servidor está operando no modo normal; ocorreu uma falha no nível do DBMS

O algoritmo é semelhante ao caso anterior: atualizando a topologia e iniciando o processo de recuperação. Como o servidor está disponível, liberamos o VIP com êxito no mestre antigo, transferimos para o novo e enviamos várias solicitações de ARP. O possível retorno do assistente antigo não deve afetar o cluster reconstruído e o aplicativo.

Outros problemas

A falha de réplicas ou mestres intermediários não leva a ações automáticas e requer intervenção manual.

A interface de rede virtual é sempre adicionada temporariamente, ou seja, após a reinicialização, o servidor VIP não é automaticamente atribuído. Cada instância do banco de dados é iniciada por padrão no modo somente leitura, o orquestrador muda automaticamente o novo mestre para gravação e tenta instalar read onlyno antigo mestre. Essas ações visam reduzir a probabilidade split brain.

Durante o processo de recuperação, podem surgir problemas, que também devem ser notificados por meio da interface do usuário do orquestrador, além das ferramentas de monitoramento padrão. Expandimos a API REST adicionando esse recurso (o PR está atualmente em consideração).

O esquema geral da solução de HA é apresentado abaixo.

Escolhendo um novo assistente

A orquestra é inteligente o suficiente e tenta escolher a réplica mais adequada como novo mestre, de acordo com os seguintes critérios:

atraso da réplica do mestre;
Assistente de MySQL e versão de réplica;
tipo de replicação (RBR, SBR ou mista);
localização em um ou em diferentes data centers;
disponibilidade errant GTID- transações realizadas na réplica e ausentes no mestre;
regras de seleção personalizadas também são levadas em consideração.

Nem toda réplica é um candidato ideal para o papel de mestre. Por exemplo, uma réplica pode ser usada para fazer backup de dados ou o servidor tem uma configuração de hardware mais fraca. O orquestrador suporta regras manuais, com as quais você pode ajustar suas preferências para escolher um candidato, do mais preferido ao ignorado.

Tempo de resposta e recuperação

No caso de um incidente, é importante minimizar o tempo de inatividade do sistema; portanto, consideramos os parâmetros do MySQL que afetam a construção e a atualização da topologia de cluster pela orquestra:

slave_net_timeout- o número de segundos durante os quais a réplica aguarda novos dados ou um sinal de pulsação do mestre antes que a conexão seja reconhecida como perdida e a reconexão seja realizada. Quanto menor o valor, mais rápida a réplica poderá determinar que a conexão com o mestre está interrompida. Definimos esse valor para 5 segundos.
MASTER_CONNECT_RETRY- o número de segundos entre as tentativas de reconexão. No caso de problemas de rede, um valor baixo desse parâmetro permitirá que você se reconecte rapidamente e evite o início do processo de recuperação de cluster. O valor recomendado é de 1 segundo.
MASTER_RETRY_COUNT - O número máximo de tentativas para reconectar.
MASTER_HEARTBEAT_PERIOD- o intervalo em segundos após o qual o mestre envia um sinal de pulsação. O padrão é metade do valor slave_net_timeout.

Opções do orquestrador:

DelayMasterPromotionIfSQLThreadNotUpToDate- se for igual true, a função do assistente não será aplicada na réplica candidata até que o fluxo SQL da réplica conclua todas as transações não aplicadas do Relay Log. Usamos essa opção para não perder transações quando todas as réplicas candidatas estiverem atrasadas.
InstancePollSeconds - a frequência de construção e atualização da topologia.
RecoveryPollSeconds- frequência de análise de topologia. Se um problema for detectado, a recuperação da topologia será iniciada. Esta é uma constante igual a 1 segundo.

Cada nó do cluster é pesquisado pelo orquestrador uma vez a cada InstancePollSecondssegundo. Quando um problema é detectado, o estado do cluster é atualizado à força e, em seguida, é tomada a decisão final para executar a recuperação. Ao experimentar vários parâmetros do banco de dados e da orquestra, conseguimos reduzir a duração da resposta e recuperação para 30 segundos.

Suporte de teste

Começamos a testar o esquema de HA, desenvolvendo um banco de testes local e implementando-o ainda em um ambiente de teste e combate. O estande local é totalmente automatizado com base no Docker e permite experimentar a configuração da orquestra e da rede, escalar o cluster de 2 a 3 servidores para várias dezenas e realizar exercícios em um ambiente seguro.

Durante os exercícios, escolhemos um dos métodos para emular o problema: atire instantaneamente no assistente kill -9, conclua suavemente o processo e pare o servidor ( docker-compose stop), simule problemas de rede com iptables -j REJECTou iptables -j DROP. Esperamos estes resultados:

a orquestra detectará problemas com o mestre e atualizará a topologia em não mais que 10 segundos;
o procedimento de recuperação será iniciado automaticamente: a configuração da rede será alterada, o papel do assistente passará para a réplica, a topologia será reconstruída;
o novo mestre estará disponível para gravação, as réplicas ao vivo não serão perdidas no processo de reconstrução;
os dados começarão a ser gravados no novo mestre e replicados;
o tempo total de recuperação não será superior a 30 segundos.

Como você sabe, um sistema pode se comportar de maneira diferente em ambientes de teste e produção devido a diferentes configurações de hardware e rede, diferenças de carga sintética e real, etc. Portanto, periodicamente realizamos exercícios em condições reais, verificando como o sistema se comporta em caso de perda da conectividade da rede ou degradação de suas partes individuais. No futuro, queremos construir uma infraestrutura completamente idêntica para os dois ambientes e automatizar seus testes.

achados

A operacionalidade do nó principal do sistema de armazenamento é uma das principais tarefas da equipe e operação do SRE. A introdução da orquestra e soluções de alta disponibilidade baseadas no VIP permitiu alcançar os seguintes resultados:

detecção confiável de problemas com a topologia do cluster de banco de dados;
resposta automática e rápida a incidentes relacionados ao mestre, o que reduz o tempo de inatividade do sistema.

No entanto, a solução tem suas limitações e desvantagens:

escalar o esquema de alta disponibilidade para vários data centers exigirá uma única rede L2 entre eles;
Antes de atribuir um VIP ao novo mestre, precisamos liberá-lo no antigo. O processo é seqüencial, o que aumenta o tempo de recuperação;
VIP SSH- , . , , , VIP . IP- split brain.

Para evitar split brain, você pode usar o método STONITH (“Atire o outro nó na cabeça”), que isola ou desconecta completamente o nó problemático. Existem outras maneiras de implementar a alta disponibilidade do cluster: uma combinação de VIP e DNS, descoberta de serviços e serviços de proxy, replicação síncrona e outros métodos que têm suas desvantagens e vantagens.

Eu falei sobre a nossa abordagem para criar um cluster de failover do MySQL. É fácil de implementar e fornece um nível aceitável de confiabilidade no ambiente atual. Com o desenvolvimento de todo o sistema como um todo e a infraestrutura em particular, essa abordagem sem dúvida evoluirá.

Orchestrator e VIP como solução de alta disponibilidade para cluster MySQL