Na Citymobil usamos um banco de dados MySQL como principal armazenamento persistente de dados. Temos vários clusters de banco de dados para diversos serviços e finalidades.

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

Solução HA baseada em VIP

Primeiro, direi brevemente qual é o nosso sistema de armazenamento de dados.

Usamos um esquema de replicação clássico com um mestre acessível para gravação e várias 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 por meio do HAProxy, que permite distribuição uniforme de carga e fácil escalonamento. O uso do HAProxy se deve a motivos históricos e atualmente estamos em processo de migração para ProxySQL.

A replicação é executada no modo semissíncrono com base em GTID. Isso significa que pelo menos uma réplica deve registrar uma transação antes que ela seja considerada bem-sucedida. Este modo de replicação fornece um equilíbrio ideal entre desempenho e segurança de dados no caso de falha de um nó mestre. Basicamente todas as alterações são transferidas do mestre para as 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, caso surjam problemas, pode iniciar um procedimento de recuperação automática. O desenvolvedor é responsável pelo procedimento em si, pois pode ser implementado de diversas formas: baseado em VIP, DNS, utilizando serviços de descoberta de serviços ou mecanismos auto-escritos.

Uma maneira simples de restaurar um master caso ele falhe é usar endereços VIP flutuantes.

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

• Um VIP é um endereço IP que não está associado a uma interface de rede física específica. Se um nó falhar ou durante a manutenção programada, podemos mudar 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 VIP, você precisa de acesso ao servidor via SSH, ou da utilização de utilitários especiais, por exemplo, keepalived.

Vejamos os possíveis problemas com nosso assistente e imaginemos como o mecanismo de recuperação automática deve funcionar.

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

1. O orquestrador atualiza a topologia do cluster, cada réplica informa que o mestre está indisponível. O orquestrador inicia o processo de seleção de uma réplica adequada para a função do novo mestre e inicia a recuperação.
2. Estamos tentando remover o VIP do antigo mestre - sem sucesso.
3. A réplica muda para a função de mestre. A topologia está sendo reconstruída.
4. Adicionando uma nova interface de rede com VIP. Como não foi possível remover o VIP, passamos a enviar periodicamente uma solicitação em background ARP gratuito. Este tipo de solicitação/resposta permite atualizar a tabela de mapeamento de endereços IP e MAC nos switches conectados, notificando assim que nosso VIP mudou. Isso minimiza a probabilidade split brain ao devolver o antigo mestre.
5. Todas as novas conexões são imediatamente redirecionadas para o novo mestre. Conexões antigas falham e chamadas repetidas ao banco de dados são feitas no nível do aplicativo.

O servidor está operando em modo normal, ocorreu uma falha no nível do SGBD

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

Outros problemas

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

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

Podem surgir problemas durante o processo de recuperação, que também deve ser notificado através da interface do orquestrador, além das ferramentas de monitoramento padrão. Expandimos a API REST adicionando este recurso (PR atualmente em revisão).

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

Escolhendo um novo mestre

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

• a réplica fica atrás do mestre;
• Versão MySQL do mestre e da réplica;
• tipo de replicação (RBR, SBR ou mista);
• localização no mesmo data center ou em data centers diferentes;
• disponibilidade errant GTID — transações que foram executadas na réplica e não estão no mestre;
• regras de seleção personalizadas também são levadas em consideração.

Nem toda sugestão é candidata ideal para 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. Orquestrador suporta o regras manuais com as quais você pode personalizar suas preferências de seleção de candidatos, do mais preferido ao ignorado.

Tempo de resposta e recuperação

Caso ocorra um incidente, é importante minimizar o tempo de inatividade do sistema, então vamos considerar os parâmetros do MySQL que afetam a criação e atualização da topologia do cluster pelo orquestrador:

• slave_net_timeout — o número de segundos durante os quais a réplica aguarda a chegada de novos dados ou um sinal de pulsação do mestre antes que a conexão seja reconhecida como perdida e reconectada. Quanto menor o valor, mais rápido a réplica pode determinar que a comunicação com o mestre foi interrompida. Definimos esse valor para 5 segundos.
• MASTER_CONNECT_RETRY — número de segundos entre tentativas de reconexão. No caso de problemas de rede, um valor baixo para este parâmetro permitirá uma reconexão rápida e impedirá o início do processo de recuperação do cluster. O valor recomendado é 1 segundo.
• MASTER_RETRY_COUNT — número máximo de tentativas de reconexão.
• MASTER_HEARTBEAT_PERIOD — 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 igual true, a função mestre não será aplicada na réplica candidata até que o thread SQL da réplica tenha concluído todas as transações não aplicadas do Relay Log. Usamos esta opção para evitar a perda de transações quando todas as réplicas candidatas ficam para trás.
• InstancePollSeconds — 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. Esse constante, igual a 1 segundo.

Cada nó do cluster é pesquisado pelo orquestrador uma vez a cada InstancePollSeconds segundos Quando um problema é detectado, o estado do cluster é forçado Atualizada, e então é tomada a decisão final de realizar a recuperação. Ao experimentar diferentes parâmetros de banco de dados e orquestrador, conseguimos reduzir o tempo de resposta e recuperação para 30 segundos.

bancada de teste

Começamos a testar o esquema HA com o desenvolvimento de um local bancada e implementação adicional em ambientes de teste e produção. O estande local é totalmente automatizado baseado em Docker e permite experimentar a configuração do orquestrador e da rede, dimensionar 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 de emulação do problema: atirar instantaneamente no mestre usando kill -9, encerre suavemente o processo e pare o servidor (docker-compose stop), simular problemas de rede usando iptables -j REJECT ou iptables -j DROP. Esperamos os seguintes resultados:

• o orquestrador detectará problemas com o mestre e atualizará a topologia em no máximo 10 segundos;
• o procedimento de recuperação será iniciado automaticamente: a configuração da rede será alterada, a função do mestre passará para a réplica, a topologia será reconstruída;
• o novo mestre se tornará gravável, as réplicas ativas não serão perdidas durante o 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, o 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 na carga sintética e real, etc. Portanto, realizamos periodicamente exercícios em condições reais, verificando como o sistema se comporta quando a conectividade da rede é perdida ou suas partes individuais são degradadas. No futuro, queremos construir uma infraestrutura completamente idêntica para ambos os ambientes e automatizar os seus testes.

Descobertas

A integridade do nó principal do sistema de armazenamento é uma das principais tarefas do SRE e da equipe de operações. A implementação do orquestrador e da solução HA baseada em VIP permitiu-nos 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, reduzindo o tempo de inatividade do sistema.

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

• dimensionar o esquema de HA para vários data centers exigirá uma única rede L2 entre eles;
• Antes de atribuir VIP no novo master, precisamos liberá-lo no antigo. O processo é sequencial, o que aumenta o tempo de recuperação;
• liberar o VIP requer acesso SSH ao servidor ou qualquer outro método de chamada de procedimentos remotos. Como o servidor ou banco de dados está enfrentando problemas que causaram o processo de recuperação, não podemos ter certeza de que a remoção do VIP será concluída com êxito. E isso pode levar ao aparecimento de dois servidores com o mesmo endereço IP virtual e um problema split brain.

Evitar split brain, você pode usar o método STONITH (“Shoot The Other Node In The Head”), que isola ou desativa completamente o nó problemático. Existem outras maneiras de implementar alta disponibilidade de 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 próprias desvantagens e vantagens.

Falei sobre nossa abordagem para criar um cluster de failover MySQL. É fácil de implementar e fornece um nível aceitável de confiabilidade nas condições atuais. À medida que todo o sistema em geral e a infra-estrutura em particular se desenvolvem, esta abordagem irá sem dúvida evoluir.

Fonte: habr.com