MySQL baseado na teoria de alta disponibilidade MHA

Prefácio

Sistema de alta disponibilidade
MySQL O MySQL está altamente disponível, como o nome indica, quando ocorre qualquer falha no host ou serviço MySQL, outro host pode assumir imediatamente o seu trabalho, e o requisito mínimo é garantir a consistência dos dados. Portanto, os objetivos a serem alcançados para um sistema de alta disponibilidade MySQL são os seguintes:

(1) Garantia de consistência de dados Este é o mais básico e pré-requisito. Se os dados primários e secundários forem inconsistentes, a troca não pode ser realizada. Claro, a consistência aqui também é relativa, mas a consistência final deve ser alcançada.

(2) Failover rápido. Quando o mestre falha, pode ser uma falha de máquina ou uma falha de instância. É necessário garantir que o negócio possa ser mudado para o nó de espera no menor tempo para que o negócio seja afetado pelo menor tempo.

(3) Simplificar a manutenção diária e concluir automaticamente a implantação de alta disponibilidade, manutenção, monitoramento e outras tarefas por meio de uma plataforma altamente disponível, que pode liberar a operação manual do DBA ao máximo e melhorar a eficiência da operação e manutenção diária.

(4) Gerenciamento unificado - quando há muitos conjuntos de replicação, as informações de instância altamente disponíveis, as informações de monitoramento e as informações de comutação podem ser gerenciadas de maneira uniforme.

(5) A implantação de alta disponibilidade não deve ter impacto sobre a arquitetura de banco de dados existente.Se a arquitetura do banco de dados precisar ser alterada ou ajustada por causa da implantação de alta disponibilidade, o custo aumentará.

As soluções atuais de alta disponibilidade do MySQL podem alcançar alta disponibilidade do banco de dados até certo ponto, como MMM, heartbeat + drbd e NDB Cluster. Há também o cluster Galera do MariaDB e a replicação do grupo MySQL 5.7.17. Esses softwares altamente disponíveis têm suas próprias vantagens e desvantagens. Ao selecionar uma solução de alta disponibilidade, ela se baseia principalmente nos requisitos de negócios para consistência de dados. Finalmente, devido à alta disponibilidade e alta confiabilidade do banco de dados, é recomendado usar a arquitetura MHA, pois MySQL GP não pode ser usado em produção, mas acredito que será usado no ambiente de produção gradualmente no futuro.

1. Introdução da Tecnologia MHA

MHA (Master High Availability) é atualmente uma solução relativamente madura para alta disponibilidade do MySQL. Foi desenvolvido por youshimaton, uma empresa japonesa DeNA (agora trabalhando no Facebook). É um excelente conjunto de soluções de failover e mestre para alta disponibilidade do MySQL. Da promoção de software de alta disponibilidade. No processo de failover do MySQL, o MHA pode concluir automaticamente a operação de failover do banco de dados em 0 ~ 30 segundos e, no processo de failover, o MHA pode garantir a consistência dos dados ao máximo para atingir o verdadeiro Alta disponibilidade no sentido. Além do failover, o MHA também oferece suporte à comutação mestre online, que é muito segura e eficiente e só precisa de tempo de gravação de bloqueio (0,5 a 2 segundos).

O software consiste em duas partes: MHA Manager (nó de gerenciamento) e MHA Node (nó de dados). O MHA Manager pode ser implantado em uma máquina separada para gerenciar vários clusters mestre-escravo ou pode ser implantado em um único nó escravo. O Nó MHA é executado em cada servidor MySQL. O MHA Manager detecta periodicamente o nó mestre no cluster. Quando o mestre falha, ele pode promover automaticamente o último escravo de dados para o novo mestre e, em seguida, redirecionar todos os outros escravos para o novo mestre. O mestre. Todo o processo de failover é completamente transparente para o aplicativo.

2. O MHA fornece as seguintes funções

No momento, o MHA suporta principalmente uma arquitetura mestre e escravo múltiplo. Para construir o MHA, um cluster de replicação deve ter pelo menos três servidores de banco de dados, um mestre e dois escravos, ou seja, um serve como mestre, um serve como mestre em espera e o outro serve como escravo. Claro, se você está considerando o custo, também pode usar um MHA de dois nós, um mestre e um escravo (medido).

Resumindo, o MHA fornece as seguintes funções:

(1) Monitoramento automático mestre e integração de failover (monitoramento mestre automatizado e failover)

(2) O MHA pode monitorar o status do mestre em um grupo de replicação. Se ele travar, pode fazer failover automaticamente.

(3) O MHA garante a consistência dos dados por meio do relé-log de diferença de todos os escravos.

(4) Quando o MHA está realizando failover e compensação de log para essas ações, geralmente leva apenas de 10 a 30 segundos.

(5) Em circunstâncias normais, o MHA selecionará o escravo mais recente como o novo mestre, mas você também pode especificar quais são os masers candidatos, portanto, quando o novo mestre for eleito, ele escolherá um desses hosts.

(6) Problemas de consistência que causam interrupção do ambiente de replicação não ocorrerão no MHA, tenha a certeza de usar.

No processo de failover automático do MHA, o MHA tenta salvar o log binário do servidor principal inativo para garantir que os dados não sejam perdidos ao máximo, mas isso nem sempre é viável. Por exemplo, se o hardware do servidor principal falhar ou não puder ser acessado via ssh, o MHA não poderá salvar o log binário e apenas fará o failover e perderá os dados mais recentes. O uso da replicação semissíncrona do MySQL 5.5 e superior pode reduzir muito o risco de perda de dados. O MHA pode ser combinado com replicação semissíncrona. Se apenas um escravo recebeu o log binário mais recente, o MHA pode aplicar o log binário mais recente a todos os outros servidores escravos, para que a consistência dos dados de todos os nós possa ser garantida.

(7) Failover mestre interativo manual (failover mestre interativo iniciado manualmente)

O MHA pode ser configurado para executar failover de forma interativa e manual e não oferece suporte ao monitoramento do status do mestre.

(8) Failover mestre não interativo (failover mestre não interativo)

Não interativo, failover automático, não fornece função de monitoramento de status mestre, o monitoramento pode ser feito por outros componentes (como: Pulsação do Pacemaker).

(9) Mestre de comutação online para um host diferente

Se você tem um master mais rápido e melhor e planeja substituir o master antigo por um novo, esse recurso é particularmente adequado para tais cenários.

Não é que o master esteja realmente abatido, mas temos muitas necessidades de manutenção de rotina do master.

3. Vantagens do MHA

1. O failover mestre e a promoção de escravo são muito rápidos.

2. Detecção automática, detecção múltipla, suporte para chamar outras interfaces de script durante o processo de comutação.

3. A falha principal não causará inconsistência de dados e preencherá os dados automaticamente para manter a consistência dos dados.

4. Não há necessidade de modificar nenhuma configuração de replicação, é simples e fácil de implantar e não tem impacto na arquitetura existente.

5. Não há necessidade de adicionar muitas máquinas adicionais para implantar o MHA e oferecer suporte ao gerenciamento centralizado de várias instâncias.

6. Não há impacto no desempenho.

7. Suporte para comutação online.

8. Motor de armazenamento cruzado, suporta qualquer motor.

4. Fluxo de trabalho de MHA

A figura a seguir mostra como gerenciar vários conjuntos de replicação mestre-escravo por meio do Gerenciador de MHA. O princípio de funcionamento do MHA pode ser resumido da seguinte forma:

1. Como o MHA monitora o mestre e o failover?

1.1 Verifique as configurações de replicação e confirme o status atual do mestre

Conecte todos os hosts, o MHA confirma automaticamente qual é o mestre atual e não há necessidade de especificar qual é o mestre no arquivo de configuração.

Se algum dos escravos desligar, o script sai imediatamente e interrompe o monitoramento.

Se alguns scripts necessários não forem instalados no nó do Nó MHA, o MHA será encerrado neste estágio e o monitoramento será interrompido.

1.2 Monitoramento mestre

Monitore o master até que ele desligue.

Nesse estágio, o MHA não monitora o escravo e as operações de Parar / Reiniciar / Adicionar / Remover no escravo não afetarão o processo de monitoramento do MHA atual. Ao adicionar ou excluir um escravo, atualize o arquivo de configuração, de preferência reinicie o MHA.

1.3 Verifique se o mestre falhou

Se o MHA Manager não conseguir se conectar ao servidor mestre em três intervalos, ele entrará neste estágio.

Se você definir secondary_check_script, o MHA chamará o script para fazer uma segunda verificação para determinar se o mestre está realmente inativo.

A próxima etapa é o fluxo de trabalho de masterha_master_switch.

1.4 Verifique a configuração do escravo novamente

Se qualquer configuração de replicação ilegal for encontrada (alguns mestres escravos não são os mesmos), o MHA interromperá o monitoramento e relatará um erro. Você pode definir ignore_fail para ignorar.

Esta etapa é para considerações de segurança. É muito provável que o arquivo de configuração copiado tenha sido alterado, portanto, verifique novamente é a maneira recomendada.

Verifique o status do último failover (failover)

Se o último failover relatou um erro, ou o último failover terminou muito recentemente (padrão 3 dias), o MHA para o monitoramento e para o failover e, em seguida, defina ignore_last_failover e wait_on_failover_error no comando masterha_manager para alterar essa detecção. Isso também é por razões de segurança. Failover frequente, verifique se há um problema com a rede ou outros erros?

1.5 Desligue o servidor mestre com falha (opcional)

Se master_ip_failover_script e / ou shutdown_script forem definidos no arquivo de configuração, o MHA chamará esses scripts.

Desligue o mestre morto para evitar a divisão do cérebro (discutível).

1.6 Recuperar um novo mestre

Salve o log bin do servidor mestre travado no gerenciador (se possível

Se o mestre morto puder fazer SSH, copie os logs binários da posição end_log_pos (Read_Master_Log_Pos) no escravo mais recente.

Eleição de um novo mestre

Geralmente, você decide quem eleger de acordo com as configurações do arquivo de configuração. Se você quiser configurar alguns candidatos a mestres, defina candidate_master = 1; se você quiser configurar alguns hosts, você nunca irá eleger, defina no_master = 1; confirme o último escravo (este escravo tem o mais recente Relay-log).

Restaurar e promover o novo mestre

De acordo com o antigo log binário mestre, o log de diferença é gerado e o log é aplicado ao novo mestre. Se ocorrer um erro nesta etapa (como: erro de chave duplicada), o MHA para de se recuperar e o restante dos escravos também para.

(2) Como o MHA muda o mestre online rapidamente?

As etapas a seguir são o que masterha_master_switch — master_state = alive faz.

2.1 Verifique as configurações de replicação e confirme o status do mestre atual

Conecte-se a todos os hosts listados no arquivo de configuração, o MHA confirma automaticamente qual é o mestre atual e não há necessidade de especificar qual é o mestre no arquivo de configuração.

Execute o comando flush tables no master (opcional). Isso pode diminuir o tempo de FLUSH TABLES WITH READ LOCK.

Nem monitorar mestre nem failover.

Verifique se as seguintes condições são atendidas.

A. O encadeamento IO está sendo executado em todos os escravos?

B. O encadeamento SQL está sendo executado em todos os escravos?

C. Se Seconds_Behind_Master é menor que 2 segundos (--running_updates_limit = N).

D. Se não há declaração de atualização longa no mestre superior a 2 segundos.

2.2 Confirme o novo mestre

O novo mestre precisa ser definido: parâmetro -new_master_host.

O mestre original e o novo mestre devem ter as mesmas condições de filtro de replicação (binlog-do-db e binlog-ignore-db).

2.3 O mestre atual para de gravar

Se você definir master_ip_online_change_script na configuração, o MHA o chamará. Você pode evitar perfeitamente a gravação definindo SET GLOBAL read_only = 1.

Execute FLUSH TABLES WITH READ LOCK no mestre antigo para evitar todas as gravações (–skip_lock_all_tables pode ignorar esta etapa).

2.4 Esperando que outros escravos alcancem o mestre atual, sincronização sem demora

Chame esta função MASTER_LOG_POS ().

2.5 Certifique-se de que o novo mestre pode ser escrito

Execute SHOW MASTER STATUS para determinar o nome do arquivo de log binário e a posição do novo mestre.

Se master_ip_online_change_script estiver definido, ele será chamado. Você pode criar usuários com permissões de gravação, SET GLOBAL read_only = 0.

2.6 Deixe outros escravos apontarem para o novo mestre

Execute CHANGE MASTER, START SLAVE em paralelo.

Introdução ao componente
MHA O software MHA consiste em duas partes, o kit de ferramentas Manager e o kit de ferramentas Node. As instruções específicas são as seguintes.

O kit de ferramentas do gerenciador inclui principalmente as seguintes ferramentas:

(1) masterha_check_ssh #Check the SSH configuration status of MHA;

(2) masterha_check_repl #check o status de replicação do MySQL;

(3) masterha_manger #Start MHA;

(4) masterha_check_status #Detectar o status atual de execução do MHA;

(5) masterha_master_monitor #Detectar se o master está inativo;

(6) masterha_master_switch #Control failover (automático ou manual);

(7) masterha_conf_host #Adicionar ou excluir informações do servidor configurado;

O kit de ferramentas do Node (essas ferramentas geralmente são acionadas por scripts do MHA Manager sem operação humana) incluem principalmente as seguintes ferramentas:

(1) save_binary_logs #Save e copie o log binário do master;

(2) apply_diff_relay_logs #Identify relay relay log events e aplica seus eventos diferenciais a outros slaves;

(3) purge_relay_logs #Clear relay logs (não bloqueará o thread SQL);

Nota: A fim de minimizar a perda de dados causada por danos ao hardware da biblioteca principal e tempo de inatividade, é recomendado configurar a replicação semissíncrona do MySQL ao configurar o MHA. Quanto ao princípio de replicação semissíncrona, verifique você mesmo (não é necessário).