Em nossos blogs anteriores, discutimos o MHA como uma ferramenta de failover usada nas configurações mestre-escravo do MySQL. No mês passado, também postamos no blog sobre como lidar com o MHA quando ele travou. Hoje, veremos os principais problemas que os DBAs geralmente encontram com o MHA e como você pode corrigi-los.
Uma breve introdução ao MHA (alta disponibilidade principal)
MHA significa (Master High Availability) ainda é relevante e amplamente utilizado hoje, especialmente em configurações mestre-escravo baseadas em replicação não-GTID. O MHA executa bem um failover ou switch mestre, mas vem com algumas armadilhas e limitações. Depois que o MHA executa um failover mestre e uma promoção de escravo, ele pode concluir automaticamente sua operação de failover de banco de dados em aproximadamente 30 segundos, o que pode ser aceitável em um ambiente de produção. O MHA pode garantir a consistência dos dados. Tudo isso com zero degradação de desempenho e não requer ajustes ou alterações adicionais em suas implantações ou configurações existentes. Além disso, o MHA é construído em cima do Perl e é uma solução de HA de código aberto - portanto, é relativamente fácil criar auxiliares ou estender a ferramenta de acordo com a configuração desejada. Confira esta apresentação para mais informações.
O software MHA consiste em dois componentes, você precisa instalar um dos seguintes pacotes de acordo com sua função de topologia:
Nó do gerenciador MHA =MHA Manager (gerente)/Nó MHA (nó de dados)
Nós mestre/escravo =nó MHA (nó de dados)
O MHA Manager é o software que gerencia o failover (automático ou manual), toma decisões sobre quando e onde fazer o failover e gerencia a recuperação do escravo durante a promoção do mestre candidato para aplicação de logs de retransmissão diferencial. Se o banco de dados mestre morrer, o MHA Manager irá coordenar com o agente MHA Node, pois aplica logs de retransmissão diferencial aos escravos que não têm os eventos binlog mais recentes do mestre. O software MHA Node é um agente local que monitorará sua instância MySQL e permitirá que o MHA Manager copie logs de retransmissão dos escravos. O cenário típico é quando o mestre candidato para failover está atrasado e o MHA detecta que ele não possui os logs de retransmissão mais recentes. Portanto, ele aguardará seu mandato do MHA Manager enquanto procura o escravo mais recente que contém os eventos de log binário e copia os eventos ausentes do escravo usando scp e os aplica a si mesmo.
Observe que o MHA atualmente não é mantido ativamente, mas a versão atual em si é estável e pode ser “boa o suficiente” para produção. Você ainda pode ecoar sua voz pelo github para resolver alguns problemas ou fornecer patches ao software.
Principais problemas comuns
Agora vamos ver os problemas mais comuns que um DBA encontrará ao usar o MHA.
O escravo está atrasado, o failover não interativo/automatizado falhou!
Esse é um problema típico que faz com que o failover automatizado seja abortado ou falhe. Isso pode parecer simples, mas não aponta para apenas um problema específico. O atraso do escravo pode ter diferentes razões:
- Problemas de disco no mestre candidato fazendo com que ele seja vinculado à E/S de disco para processar leitura e gravação. Também pode levar à corrupção de dados se não for mitigado.
- Consultas incorretas são replicadas, especialmente tabelas que não têm chaves primárias ou índices clusterizados.
- alta carga do servidor.
- Servidor frio e servidor ainda não aquecido
- Não há recursos de servidor suficientes. É possível que seu escravo esteja com pouca memória ou recursos do servidor ao replicar gravações ou leituras de alta intensidade.
Esses podem ser mitigados antecipadamente se você tiver o monitoramento adequado do seu banco de dados. Um exemplo com relação aos atrasos do escravo no MHA é a memória baixa ao despejar um grande arquivo de log binário. Como exemplo abaixo, um mestre foi marcado como inativo e deve executar um failover não interativo/automático. No entanto, como o mestre candidato estava atrasado e precisa aplicar os logs que ainda não foram executados pelos threads de replicação, o MHA localizará o escravo mais atualizado ou mais recente, pois tentará recuperar um escravo contra o escravo mais antigo uns. Portanto, como você pode ver abaixo, enquanto estava executando uma recuperação de escravo, a memória ficou muito baixa:
[email protected]:~$ masterha_manager --conf=/etc/app1.cnf --remove_dead_master_conf --ignore_last_failover
Mon May 6 08:43:46 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Mon May 6 08:43:46 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Mon May 6 08:43:46 2019 - [info] Reading server configuration from /etc/app1.cnf..
…
Mon May 6 08:43:57 2019 - [info] Checking master reachability via MySQL(double check)...
Mon May 6 08:43:57 2019 - [info] ok.
Mon May 6 08:43:57 2019 - [info] Alive Servers:
Mon May 6 08:43:57 2019 - [info] 192.168.10.50(192.168.10.50:3306)
Mon May 6 08:43:57 2019 - [info] 192.168.10.70(192.168.10.70:3306)
Mon May 6 08:43:57 2019 - [info] Alive Slaves:
Mon May 6 08:43:57 2019 - [info] 192.168.10.50(192.168.10.50:3306) Version=5.7.23-23-log (oldest major version between slaves) log-bin:enabled
Mon May 6 08:43:57 2019 - [info] Replicating from 192.168.10.60(192.168.10.60:3306)
Mon May 6 08:43:57 2019 - [info] Primary candidate for the new Master (candidate_master is set)
Mon May 6 08:43:57 2019 - [info] 192.168.10.70(192.168.10.70:3306) Version=5.7.23-23-log (oldest major version between slaves) log-bin:enabled
Mon May 6 08:43:57 2019 - [info] Replicating from 192.168.10.60(192.168.10.60:3306)
Mon May 6 08:43:57 2019 - [info] Not candidate for the new Master (no_master is set)
Mon May 6 08:43:57 2019 - [info] Starting Non-GTID based failover.
….
Mon May 6 08:43:59 2019 - [info] * Phase 3.4: New Master Diff Log Generation Phase..
Mon May 6 08:43:59 2019 - [info]
Mon May 6 08:43:59 2019 - [info] Server 192.168.10.50 received relay logs up to: binlog.000004:106167341
Mon May 6 08:43:59 2019 - [info] Need to get diffs from the latest slave(192.168.10.70) up to: binlog.000005:240412 (using the latest slave's relay logs)
Mon May 6 08:43:59 2019 - [info] Connecting to the latest slave host 192.168.10.70, generating diff relay log files..
Mon May 6 08:43:59 2019 - [info] Executing command: apply_diff_relay_logs --command=generate_and_send --scp_user=vagrant --scp_host=192.168.10.50 --latest_mlf=binlog.000005 --latest_rmlp=240412 --target_mlf=binlog.000004 --target_rmlp=106167341 --server_id=3 --diff_file_readtolatest=/tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506084355.binlog --workdir=/tmp --timestamp=20190506084355 --handle_raw_binlog=1 --disable_log_bin=0 --manager_version=0.58 --relay_dir=/var/lib/mysql --current_relay_log=relay-bin.000007
Mon May 6 08:44:00 2019 - [info]
Relay log found at /var/lib/mysql, up to relay-bin.000007
Fast relay log position search failed. Reading relay logs to find..
Reading relay-bin.000007
Binlog Checksum enabled
Master Version is 5.7.23-23-log
Binlog Checksum enabled
…
…...
Target relay log file/position found. start_file:relay-bin.000004, start_pos:106167468.
Concat binary/relay logs from relay-bin.000004 pos 106167468 to relay-bin.000007 EOF into /tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506084355.binlog ..
Binlog Checksum enabled
Binlog Checksum enabled
Dumping binlog format description event, from position 0 to 361.. ok.
Dumping effective binlog data from /var/lib/mysql/relay-bin.000004 position 106167468 to tail(1074342689)..Out of memory!
Mon May 6 08:44:00 2019 - [error][/usr/local/share/perl/5.26.1/MHA/MasterFailover.pm, ln1090] Generating diff files failed with return code 1:0.
Mon May 6 08:44:00 2019 - [error][/usr/local/share/perl/5.26.1/MHA/MasterFailover.pm, ln1584] Recovering master server failed.
Mon May 6 08:44:00 2019 - [error][/usr/local/share/perl/5.26.1/MHA/ManagerUtil.pm, ln178] Got ERROR: at /usr/local/bin/masterha_manager line 65.
Mon May 6 08:44:00 2019 - [info]
----- Failover Report -----
app1: MySQL Master failover 192.168.10.60(192.168.10.60:3306)
Master 192.168.10.60(192.168.10.60:3306) is down!
Check MHA Manager logs at testnode20 for details.
Started automated(non-interactive) failover.
Invalidated master IP address on 192.168.10.60(192.168.10.60:3306)
The latest slave 192.168.10.70(192.168.10.70:3306) has all relay logs for recovery.
Selected 192.168.10.50(192.168.10.50:3306) as a new master.
Recovering master server failed.
Got Error so couldn't continue failover from here.Assim, o failover falhou. Este exemplo acima mostra que o nó 192.168.10.70 contém os logs de retransmissão mais atualizados. No entanto, neste cenário de exemplo, o nó 192.168.10.70 é definido como no_master porque tem pouca memória. Ao tentar recuperar o escravo 192.168.10.50, ele falha!
Correções/Resolução:
Este cenário ilustra algo muito importante. Um ambiente de monitoramento avançado deve ser configurado! Por exemplo, você pode executar um script em segundo plano ou daemon que monitora a integridade da replicação. Você pode adicionar como uma entrada por meio de um cron job. Por exemplo, adicione uma entrada usando o script interno masterha_check_repl :
/usr/local/bin/masterha_check_repl --conf=/etc/app1.cnfou crie um script em segundo plano que chame esse script e o execute em um intervalo. Você pode usar a opção report_script para configurar uma notificação de alerta caso ela não esteja de acordo com seus requisitos, por exemplo, o escravo está atrasado por cerca de 100 segundos durante uma alta carga de pico. Você também pode usar plataformas de monitoramento, como ClusterControl, configurá-lo para enviar notificações com base nas métricas que deseja monitorar.
Além disso, observe que, no cenário de exemplo, o failover falhou devido a um erro de falta de memória. Você pode considerar garantir que todos os seus nós tenham memória suficiente e o tamanho certo dos logs binários, pois eles precisariam despejar o log binário para uma fase de recuperação do escravo.
Escravo inconsistente, a aplicação de diferenças falhou!
Em relação ao atraso do escravo, como o MHA tentará sincronizar os logs de retransmissão para um mestre candidato, certifique-se de que seus dados estejam sincronizados. Diga para um exemplo abaixo:
...
Concat succeeded.
Generating diff relay log succeeded. Saved at /tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506054328.binlog .
scp testnode7:/tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506054328.binlog to [email protected](22) succeeded.
Mon May 6 05:43:53 2019 - [info] Generating diff files succeeded.
Mon May 6 05:43:53 2019 - [info]
Mon May 6 05:43:53 2019 - [info] * Phase 3.5: Master Log Apply Phase..
Mon May 6 05:43:53 2019 - [info]
Mon May 6 05:43:53 2019 - [info] *NOTICE: If any error happens from this phase, manual recovery is needed.
Mon May 6 05:43:53 2019 - [info] Starting recovery on 192.168.10.50(192.168.10.50:3306)..
Mon May 6 05:43:53 2019 - [info] Generating diffs succeeded.
Mon May 6 05:43:53 2019 - [info] Waiting until all relay logs are applied.
Mon May 6 05:43:53 2019 - [info] done.
Mon May 6 05:43:53 2019 - [info] Getting slave status..
Mon May 6 05:43:53 2019 - [info] This slave(192.168.10.50)'s Exec_Master_Log_Pos equals to Read_Master_Log_Pos(binlog.000010:161813650). No need to recover from Exec_Master_Log_Pos.
Mon May 6 05:43:53 2019 - [info] Connecting to the target slave host 192.168.10.50, running recover script..
Mon May 6 05:43:53 2019 - [info] Executing command: apply_diff_relay_logs --command=apply --slave_user='cmon' --slave_host=192.168.10.50 --slave_ip=192.168.10.50 --slave_port=3306 --apply_files=/tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506054328.binlog --workdir=/tmp --target_version=5.7.23-23-log --timestamp=20190506054328 --handle_raw_binlog=1 --disable_log_bin=0 --manager_version=0.58 --slave_pass=xxx
Mon May 6 05:43:53 2019 - [info]
MySQL client version is 5.7.23. Using --binary-mode.
Applying differential binary/relay log files /tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506054328.binlog on 192.168.10.50:3306. This may take long time...
mysqlbinlog: Error writing file 'UNOPENED' (Errcode: 32 - Broken pipe)
FATAL: applying log files failed with rc 1:0!
Error logs from testnode5:/tmp/relay_log_apply_for_192.168.10.50_3306_20190506054328_err.log (the last 200 lines)..
ICwgMmM5MmEwZjkzY2M5MTU3YzAxM2NkZTk4ZGQ1ODM0NDEgLCAyYzkyYTBmOTNjYzkxNTdjMDEz
….
…..
M2QxMzc5OWE1NTExOTggLCAyYzkyYTBmOTNjZmI1YTdhMDEzZDE2NzhiNDc3NDIzNCAsIDJjOTJh
MGY5M2NmYjVhN2EwMTNkMTY3OGI0N2Q0MjMERROR 1062 (23000) at line 72: Duplicate entry '12583545' for key 'PRIMARY'
5ICwgMmM5MmEwZjkzY2ZiNWE3YTAxM2QxNjc4YjQ4
OTQyM2QgLCAyYzkyYTBmOTNjZmI1YTdhMDEzZDE2NzhiNDkxNDI1MSAsIDJjOTJhMGY5M2NmYjVh
N2EwMTNkMTczN2MzOWM3MDEzICwgMmM5MmEwZjkzY2ZiNWE3YTAxM2QxNzM3YzNhMzcwMTUgLCAy
…
--------------
Bye
at /usr/local/bin/apply_diff_relay_logs line 554.
eval {...} called at /usr/local/bin/apply_diff_relay_logs line 514
main::main() called at /usr/local/bin/apply_diff_relay_logs line 121
Mon May 6 05:43:53 2019 - [error][/usr/local/share/perl/5.26.1/MHA/MasterFailover.pm, ln1399] Applying diffs failed with return code 22:0.
Mon May 6 05:43:53 2019 - [error][/usr/local/share/perl/5.26.1/MHA/MasterFailover.pm, ln1584] Recovering master server failed.
Mon May 6 05:43:53 2019 - [error][/usr/local/share/perl/5.26.1/MHA/ManagerUtil.pm, ln178] Got ERROR: at /usr/local/bin/masterha_manager line 65.
Mon May 6 05:43:53 2019 - [info]Um cluster inconsistente é muito ruim, especialmente quando o failover automático está habilitado. Nesse caso, o failover não pode continuar, pois detecta uma entrada duplicada para a chave primária '12583545 '.
Correções/Resolução:
Há várias coisas que você pode fazer aqui para evitar o estado inconsistente do cluster.
- Ative a replicação semi-síncrona sem perdas. Confira este blog externo, que é uma boa maneira de saber por que você deve considerar o uso de semi-sincronização em uma configuração de replicação padrão do MySQL.
- Execute constantemente uma soma de verificação em seu cluster mestre-escravo. Você pode usar pt-table-checksum e executá-lo uma vez por semana ou mês, dependendo de quão constantemente sua tabela é atualizada. Observe que pt-table-checksum pode adicionar sobrecarga ao tráfego do banco de dados.
- Use a replicação baseada em GTID. Embora isso não afete o problema em si. No entanto, a replicação baseada em GTID ajuda a determinar transações errôneas, especialmente aquelas que foram executadas diretamente no escravo. Outra vantagem disso é que é mais fácil gerenciar a replicação baseada em GTID quando você precisa alternar o host mestre na replicação.
Falha de hardware no mestre, mas os escravos ainda não recuperaram
Uma das muitas razões pelas quais você investiria em failover automático é uma falha de hardware no mestre. Para algumas configurações, pode ser mais ideal realizar o failover automático somente quando o mestre encontrar uma falha de hardware. A abordagem típica é notificar enviando um alarme - o que pode significar acordar a pessoa de plantão no meio da noite para que a pessoa decida o que fazer. Esse tipo de abordagem é feito no Github ou mesmo no Facebook. Uma falha de hardware, especialmente se o volume em que seus logs binários e diretório de dados residem for afetado, pode atrapalhar seu failover, especialmente se os logs binários estiverem armazenados nesse disco com falha. Por design, o MHA tentará salvar logs binários do mestre travado, mas isso não será possível se o disco falhar. Um cenário possível que pode acontecer é que o servidor não pode ser acessado via SSH. O MHA não pode salvar logs binários e precisa fazer failover sem aplicar eventos de log binários que existem apenas no mestre com falha. Isso resultará na perda dos dados mais recentes, especialmente se nenhum escravo alcançou o mestre.
Correções/Resoluções
Como um dos casos de uso do MHA, é recomendável usar a replicação semi-síncrona, pois reduz bastante o risco de perda de dados. É importante observar que quaisquer gravações que vão para o mestre devem garantir que os escravos tenham recebido os eventos de log binários mais recentes antes de sincronizar com o disco. O MHA pode aplicar os eventos a todos os outros escravos para que possam ser consistentes entre si.
Além disso, também é melhor executar um fluxo de backup de seus logs binários para recuperação de desastres caso o volume do disco principal falhe. Se o servidor ainda estiver acessível via SSH, apontar o caminho do log binário para o caminho de backup do seu log binário ainda pode funcionar, de modo que o failover e a recuperação do escravo ainda podem avançar. Dessa forma, você pode evitar a perda de dados.
Failover VIP (IP virtual) causando divisão de cérebro
O MHA, por padrão, não lida com nenhum gerenciamento VIP. No entanto, é fácil incorporar isso à configuração do MHA e atribuir ganchos de acordo com o que você deseja que o MHA faça durante o failover. Você pode configurar seu próprio script e conectá-lo aos parâmetros master_ip_failover_script ou master_ip_online_change_script. Também existem scripts de amostra que estão localizados no diretório
Durante um failover automático, assim que seu script com gerenciamento de VIP for invocado e executado, o MHA fará o seguinte:verificará o status, removerá (ou interromperá) o VIP antigo e, em seguida, reatribuirá o novo VIP ao novo mestre. Um exemplo típico de cérebro dividido é quando um mestre é identificado como morto devido a um problema de rede, mas, na verdade, os nós escravos ainda podem se conectar ao mestre. Isso é um falso positivo e geralmente leva à inconsistência de dados nos bancos de dados na configuração. As conexões de cliente de entrada usando o VIP serão enviadas para o novo mestre. Por outro lado, pode haver conexões locais em execução no antigo mestre, que deveria estar morto. As conexões locais podem estar usando o soquete unix ou localhost para diminuir os saltos de rede. Isso pode fazer com que os dados sejam desviados para o novo mestre e o restante de seus escravos, pois os dados do antigo mestre não serão replicados nos escravos.
Correções/Resolução:
Como dito anteriormente, alguns podem preferir evitar o failover automático, a menos que as verificações determinem que o mestre está totalmente inativo (como falha de hardware), ou seja, mesmo os nós escravos não conseguem alcançá-lo. A ideia é que um falso positivo pode ser causado por uma falha de rede entre o controlador do nó MHA e o mestre, portanto, um humano pode ser mais adequado nesse caso para tomar uma decisão sobre o failover ou não.
Ao lidar com alarmes falsos, o MHA possui um parâmetro chamado secondary_check_script. O valor colocado aqui pode ser seus scripts personalizados ou você pode usar o script interno /usr/local/bin/masterha_secondary_check que é enviado junto com o pacote MHA Manager. Isso adiciona verificações extras, que é realmente a abordagem recomendada para evitar falsos positivos. No exemplo abaixo da minha própria configuração, estou usando o script interno masterha_secondary_check :
secondary_check_script=/usr/local/bin/masterha_secondary_check -s 192.168.10.50 --user=root --master_host=testnode6 --master_ip=192.168.10.60 --master_port=3306No exemplo acima, o MHA Manager fará um loop baseado na lista de nós escravos (especificado pelo argumento -s) que verificará a conexão com o host mestre do MySQL (192.168.10.60). Observe que esses nós escravos no exemplo podem ser alguns nós remotos externos que podem estabelecer uma conexão com os nós do banco de dados dentro do cluster. Essa é uma abordagem recomendada especialmente para as configurações em que o MHA Manager está sendo executado em um datacenter ou rede diferente dos nós do banco de dados. A sequência a seguir ilustra como ele procede com as verificações:
- Do host MHA -> verifique a conexão TCP com o 1º nó escravo (IP:192.168.10.50). Vamos chamar isso de Conexão A. Em seguida, a partir do Nó Escravo, verifica a conexão TCP com o Nó Mestre (192.168.10.60). Vamos chamar isso de Conexão B.
Se a "Conexão A" foi bem-sucedida, mas a "Conexão B" não foi bem-sucedida em ambas as rotas, masterha_secondary_check O script sai com o código de retorno 0 e o MHA Manager decide que o MySQL master está realmente morto e iniciará o failover. Se a "Conexão A" não for bem-sucedida, masterha_secondary_check sai com o código de retorno 2 e o MHA Manager adivinha que há um problema de rede e não inicia o failover. Se a "Conexão B" foi bem-sucedida, masterha_secondary_check sai com o código de retorno 3 e o MHA Manager entende que o servidor mestre MySQL está realmente ativo e não inicia o failover.
Um exemplo de como ele reage durante o failover com base no log,
Tue May 7 05:31:57 2019 - [info] OK.
Tue May 7 05:31:57 2019 - [warning] shutdown_script is not defined.
Tue May 7 05:31:57 2019 - [info] Set master ping interval 1 seconds.
Tue May 7 05:31:57 2019 - [info] Set secondary check script: /usr/local/bin/masterha_secondary_check -s 192.168.10.50 -s 192.168.10.60 -s 192.168.10.70 --user=root --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306
Tue May 7 05:31:57 2019 - [info] Starting ping health check on 192.168.10.60(192.168.10.60:3306)..
Tue May 7 05:31:58 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May 7 05:31:58 2019 - [warning] Connection failed 1 time(s)..
Tue May 7 05:31:58 2019 - [info] Executing SSH check script: exit 0
Tue May 7 05:31:58 2019 - [info] Executing secondary network check script: /usr/local/bin/masterha_secondary_check -s 192.168.10.50 -s 192.168.10.60 -s 192.168.10.70 --user=root --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306 --user=vagrant --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306 --master_user=cmon [email protected] --ping_type=SELECT
Master is reachable from 192.168.10.50!
Tue May 7 05:31:58 2019 - [warning] Master is reachable from at least one of other monitoring servers. Failover should not happen.
Tue May 7 05:31:59 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May 7 05:31:59 2019 - [warning] Connection failed 2 time(s)..
Tue May 7 05:32:00 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May 7 05:32:00 2019 - [warning] Connection failed 3 time(s)..
Tue May 7 05:32:01 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May 7 05:32:01 2019 - [warning] Connection failed 4 time(s)..
Tue May 7 05:32:03 2019 - [warning] HealthCheck: Got timeout on checking SSH connection to 192.168.10.60! at /usr/local/share/perl/5.26.1/MHA/HealthCheck.pm line 343.
Tue May 7 05:32:03 2019 - [warning] Secondary network check script returned errors. Failover should not start so checking server status again. Check network settings for details.
Tue May 7 05:32:04 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May 7 05:32:04 2019 - [warning] Connection failed 1 time(s)..
Tue May 7 05:32:04 2019 - [info] Executing secondary network check script: /usr/local/bin/masterha_secondary_check -s 192.168.10.50 -s 192.168.10.60 -s 192.168.10.70 --user=root --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306 --user=vagrant --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306 --master_user=cmon [email protected] --ping_type=SELECT
Tue May 7 05:32:04 2019 - [info] Executing SSH check script: exit 0Outra coisa a adicionar é atribuir um valor ao parâmetro shutdown_script. Este script é especialmente útil se você tiver que implementar um STONITH adequado ou um node fencing para que ele não ressuscite. Isso pode evitar a inconsistência de dados.
Por fim, certifique-se de que o MHA Manager resida na mesma rede local junto com os nós do cluster, pois diminui a possibilidade de interrupções na rede, especialmente a conexão do MHA Manager aos nós do banco de dados.
Evitando SPOF no MHA
O MHA pode falhar por vários motivos e, infelizmente, não há recurso interno para corrigir isso, ou seja, alta disponibilidade para MHA. No entanto, como discutimos em nosso blog anterior "Master High Availability Manager (MHA) Crashed! What Do I Do Now?", Existe uma maneira de evitar SPOF para MHA.
Correções/Resolução:
Você pode aproveitar o Pacemaker para criar nós ativos/em espera manipulados pelo gerenciador de recursos do cluster (crm). Como alternativa, você pode criar um script para verificar o funcionamento do nó do gerenciador MHA. Por exemplo, você pode provisionar um nó de espera que verifica ativamente o nó do gerenciador de MHA ssh'ing para executar o script interno masterha_check_status assim como abaixo:
[email protected]:~$ /usr/local/bin/masterha_check_status --conf=/etc/app1.cnf
app1 is stopped(2:NOT_RUNNING).em seguida, faça algumas cercas de nós se esse controlador estiver bloqueado. Você também pode estender a ferramenta MHA com um script auxiliar que é executado via cron job e monitorar o processo do sistema do script masterha_manager e reativá-lo se o processo estiver morto.
Perda de dados durante o failover
O MHA depende da replicação assíncrona tradicional. Embora suporte semi-sincronização, ainda assim, a semi-sincronização depende da replicação assíncrona. Nesse tipo de ambiente, a perda de dados pode ocorrer após um failover. Quando seu banco de dados não está configurado corretamente e usando uma abordagem antiquada de replicação, pode ser um problema, especialmente ao lidar com consistência de dados e transações perdidas.
Outra coisa importante a ser observada com a perda de dados com MHA é quando o GTID é usado sem a semi-sincronização ativada. O MHA com GTID não se conectará por meio de ssh ao mestre, mas tentará sincronizar os logs binários para recuperação de nó com os escravos primeiro. Isso pode levar a mais perda de dados do que em comparação com MHA não-GTID com semi-sincronização não habilitada.
Correções/Resoluções
Ao realizar o failover automático, crie uma lista de cenários quando você espera que o MHA faça o failover. Como o MHA está lidando com a replicação mestre-escravo, nossos conselhos para evitar a perda de dados são os seguintes:
- Ativar replicação semi-sincronizada sem perdas (existe na versão MySQL 5.7)
- Use a replicação baseada em GTID. Claro, você pode usar a replicação tradicional usando as coordenadas x e y do log binário. No entanto, torna as coisas mais difíceis e demoradas quando você precisa localizar uma entrada de log binário específica que não foi aplicada no escravo. Portanto, com o GTID no MySQL, é mais fácil detectar transações errôneas.
- Para conformidade com ACID de sua replicação mestre-escravo do MySQL, habilite estas variáveis específicas:sync_binlog =1, innodb_flush_log_at_trx_commit =1. Isso é caro, pois requer mais poder de processamento quando o MySQL chama a função fsync() ao confirmar e desempenho pode ser vinculado ao disco em caso de grande número de gravações. No entanto, usar RAID com cache de backup de bateria economiza sua E/S de disco. Além disso, o próprio MySQL melhorou com o commit do grupo de logs binários, mas ainda usar um cache de backup pode salvar algumas sincronizações de disco.
- Aproveite a replicação paralela ou a replicação escrava multithread. Isso pode ajudar seus escravos a se tornarem mais eficientes e evitar atrasos de escravos em relação ao mestre. Você não quer que seu failover automático ocorra quando o master não estiver acessível através de uma conexão ssh ou tcp, ou se ele encontrar uma falha de disco e seus slaves estiverem atrasados. Isso pode levar à perda de dados.
- Ao realizar um failover online ou manual, é melhor executá-lo fora dos períodos de pico para evitar contratempos inesperados que podem levar à perda de dados. Ou para evitar pesquisas demoradas em seus logs binários enquanto há muita atividade em andamento.
MHA diz que o aplicativo não está funcionando ou o failover não funciona. O que devo fazer?
A execução de verificações usando o script integrado masterha_check_status verificará se o script mastreha_manager está em execução. Caso contrário, você receberá um erro como abaixo:
[email protected]:~$ /usr/local/bin/masterha_check_status --conf=/etc/app1.cnf app1 is stopped(2:NOT_RUNNING).No entanto, há alguns casos em que você pode obter NOT_RUNNING mesmo quando masterha_manager está correndo. Isso pode ser devido ao privilégio do ssh_user que você definiu, ou você executou masterha_manager com um usuário de sistema diferente, ou o usuário ssh encontrou uma permissão negada.
Correções/Resolução:
O MHA usará o ssh_user definido na configuração, se especificado. Caso contrário, usará o usuário do sistema atual que você usa para invocar os comandos MHA. Ao executar o script masterha_check_status por exemplo, você precisa garantir que o masterha_manager seja executado com o mesmo usuário especificado em ssh_user em seu arquivo de configuração ou o usuário que fará interface com os outros nós de banco de dados no cluster. Você precisa garantir que ele tenha chaves SSH sem senha, sem senha, para que o MHA não tenha problemas ao estabelecer conexão com os nós que o MHA está monitorando.
Observe que você precisa do ssh_user para ter acesso ao seguinte:
- Pode ler os logs binários e de retransmissão dos nós MySQL que o MHA está monitorando
- Deve ter acesso aos logs de monitoramento do MHA. Confira estes parâmetros no MHA:master_binlog_dir, manager_workdir e manager_log
- Deve ter acesso ao arquivo de configuração do MHA. Isso também é muito importante. Durante um failover, uma vez finalizado o failover, ele tentará atualizar o arquivo de configuração e remover a entrada do mestre morto. Se o arquivo de configuração não permitir o ssh_user ou o usuário do sistema operacional que você está usando no momento, ele não atualizará o arquivo de configuração, levando a uma escalada do problema se ocorrer um desastre novamente.
Lags mestres do candidato, como forçar e evitar failover com falha
Em referência ao wiki do MHA, por padrão, se um escravo atrás do mestre tem mais de 100 MB de logs de retransmissão (=precisa aplicar mais de 100 MB de logs de retransmissão), o MHA não escolhe o escravo como novo mestre porque leva muito tempo para recuperar .
Correções/Resoluções
No MHA, isso pode ser substituído definindo o parâmetro check_repl_delay=0. Durante um failover, o MHA ignora o atraso de replicação ao selecionar um novo mestre e executará transações ausentes. Essa opção é útil quando você define candidate_master=1 em um host específico e deseja certificar-se de que o host pode ser um novo mestre.
Você também pode integrar com pt-heartbeat para obter precisão de lag escravo (veja este post e este). Mas isso também pode ser amenizado com replicação paralela ou escravos de replicação multi-thread, presentes desde o MySQL 5.6 ou, com MariaDB 10 - alegando ter um aumento de 10x na replicação paralela e escravos multi-thread. Isso pode ajudar seus escravos a se replicarem mais rapidamente.
As senhas do MHA são expostas
Proteger ou criptografar as senhas não é algo que é tratado pelo MHA. Os parâmetros password ou repl_password serão expostos através do arquivo de configuração. So your system administrator or security architect must evaluate the grants or privileges of this file as you don’t want to expose valuable database/SSH credentials.
Fixes/Resolution:
MHA has an optional parameter init_conf_load_script. This parameter can be used to have a custom script load your MHA config that will interface to e.g. a database, and retrieve the user/password credentials of your replication setup.
Of course, you can also limit the file attribute of the configuration and the user you are using, and limit the access to the specific Ops/DBA's/Engineers that will handle MHA.
MHA is Not My Choice, What Are the Alternatives for replication failover?
MHA is not a one-size-fits-all solution, it has its limitations and may not fit your desired setup. However, here's a list of variants that you can try.
- PRM
- Maxscale with Mariadb Monitor or MariaDB Replication Manager (MRM)
- Orchestrator
- ClusterControl
