A Replicação MySQL é uma maneira muito popular de construir camadas de banco de dados altamente disponíveis. É muito conhecido, testado e robusto. Não é sem limitações, no entanto. Um deles, definitivamente, é o fato de utilizar apenas um “ponto de entrada” - você tem um servidor dedicado na topologia, o mestre, e é o único nó do cluster para o qual você pode emitir gravações. Isso leva a consequências graves - o mestre é o único ponto de falha e, caso falhe, nenhuma gravação pode ser executada pelo aplicativo. Não é surpresa que muito trabalho tenha sido feito no desenvolvimento de ferramentas, o que reduziria o impacto de uma perda de mestre. Claro, existem discussões sobre como abordar o tema, se o failover automatizado é melhor que o manual ou não. Eventualmente, esta é uma decisão de negócios a ser tomada, mas se você decidir seguir o caminho da automação, estará procurando as ferramentas para ajudá-lo a conseguir isso. Uma das ferramentas, que ainda é muito popular, é o MHA (Master High Availability). Embora talvez não seja mais mantido ativamente, ainda está em uma forma estável e sua enorme popularidade ainda o torna a espinha dorsal das configurações de replicação do MySQL de alta disponibilidade. O que aconteceria, porém, se o próprio MHA ficasse indisponível? Pode tornar-se um ponto único de falha? Existe uma maneira de evitar que isso aconteça? Neste post do blog, vamos dar uma olhada em alguns dos cenários.
Primeiramente, se você planeja usar o MHA, certifique-se de usar a versão mais recente do repositório. Não use versões binárias, pois elas não contêm todas as correções. A instalação é bastante simples. O MHA consiste em duas partes, gerenciador e nó. O nó deve ser implantado em seus servidores de banco de dados. Manager será implantado em um host separado, juntamente com o node. Então, servidores de banco de dados:nó, host de gerenciamento:gerenciador e nó.
É muito fácil compilar MHA. Acesse o GitHub e clone os repositórios.
https://github.com/yoshinorim/mha4mysql-manager
https://github.com/yoshinorim/mha4mysql-node
Então é tudo:
perl Makefile.PL
make
make installVocê pode ter que instalar algumas dependências de perl se você não tiver todos os pacotes necessários já instalados. No nosso caso, no Ubuntu 16.04, tivemos que instalar o seguinte:
perl -MCPAN -e "install Config::Tiny"
perl -MCPAN -e "install Log::Dispatch"
perl -MCPAN -e "install Parallel::ForkManager"
perl -MCPAN -e "install Module::Install"Depois de instalar o MHA, você precisa configurá-lo. Não entraremos em detalhes aqui, existem muitos recursos na internet que cobrem essa parte. Uma configuração de amostra (definitivamente não de produção) pode ter esta aparência:
[email protected]:~# cat /etc/app1.cnf
[server default]
user=cmon
password=pass
ssh_user=root
# working directory on the manager
manager_workdir=/var/log/masterha/app1
# working directory on MySQL servers
remote_workdir=/var/log/masterha/app1
[server1]
hostname=node1
candidate_master=1
[server2]
hostname=node2
candidate_master=1
[server3]
hostname=node3
no_master=1O próximo passo será ver se tudo funciona e como o MHA vê a replicação:
[email protected]:~# masterha_check_repl --conf=/etc/app1.cnf
Tue Apr 9 08:17:04 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Tue Apr 9 08:17:04 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Tue Apr 9 08:17:04 2019 - [info] Reading server configuration from /etc/app1.cnf..
Tue Apr 9 08:17:04 2019 - [info] MHA::MasterMonitor version 0.58.
Tue Apr 9 08:17:05 2019 - [error][/usr/local/share/perl/5.22.1/MHA/MasterMonitor.pm, ln427] Error happened on checking configurations. Redundant argument in sprintf at /usr/local/share/perl/5.22.1/MHA/NodeUtil.pm line 195.
Tue Apr 9 08:17:05 2019 - [error][/usr/local/share/perl/5.22.1/MHA/MasterMonitor.pm, ln525] Error happened on monitoring servers.
Tue Apr 9 08:17:05 2019 - [info] Got exit code 1 (Not master dead).Pois é, caiu. Isso ocorre porque o MHA tenta analisar a versão do MySQL e não espera hífens nela. Felizmente, a correção é fácil de encontrar:https://github.com/yoshinorim/mha4mysql-manager/issues/116.
Agora, temos o MHA pronto para o trabalho.
[email protected]:~# masterha_manager --conf=/etc/app1.cnf
Tue Apr 9 13:00:00 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Tue Apr 9 13:00:00 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Tue Apr 9 13:00:00 2019 - [info] Reading server configuration from /etc/app1.cnf..
Tue Apr 9 13:00:00 2019 - [info] MHA::MasterMonitor version 0.58.
Tue Apr 9 13:00:01 2019 - [info] GTID failover mode = 1
Tue Apr 9 13:00:01 2019 - [info] Dead Servers:
Tue Apr 9 13:00:01 2019 - [info] Alive Servers:
Tue Apr 9 13:00:01 2019 - [info] node1(10.0.0.141:3306)
Tue Apr 9 13:00:01 2019 - [info] node2(10.0.0.142:3306)
Tue Apr 9 13:00:01 2019 - [info] node3(10.0.0.143:3306)
Tue Apr 9 13:00:01 2019 - [info] Alive Slaves:
Tue Apr 9 13:00:01 2019 - [info] node2(10.0.0.142:3306) Version=5.7.25-28-log (oldest major version between slaves) log-bin:enabled
Tue Apr 9 13:00:01 2019 - [info] GTID ON
Tue Apr 9 13:00:01 2019 - [info] Replicating from 10.0.0.141(10.0.0.141:3306)
Tue Apr 9 13:00:01 2019 - [info] Primary candidate for the new Master (candidate_master is set)
Tue Apr 9 13:00:01 2019 - [info] node3(10.0.0.143:3306) Version=5.7.25-28-log (oldest major version between slaves) log-bin:enabled
Tue Apr 9 13:00:01 2019 - [info] GTID ON
Tue Apr 9 13:00:01 2019 - [info] Replicating from 10.0.0.141(10.0.0.141:3306)
Tue Apr 9 13:00:01 2019 - [info] Not candidate for the new Master (no_master is set)
Tue Apr 9 13:00:01 2019 - [info] Current Alive Master: node1(10.0.0.141:3306)
Tue Apr 9 13:00:01 2019 - [info] Checking slave configurations..
Tue Apr 9 13:00:01 2019 - [info] Checking replication filtering settings..
Tue Apr 9 13:00:01 2019 - [info] binlog_do_db= , binlog_ignore_db=
Tue Apr 9 13:00:01 2019 - [info] Replication filtering check ok.
Tue Apr 9 13:00:01 2019 - [info] GTID (with auto-pos) is supported. Skipping all SSH and Node package checking.
Tue Apr 9 13:00:01 2019 - [info] Checking SSH publickey authentication settings on the current master..
Tue Apr 9 13:00:02 2019 - [info] HealthCheck: SSH to node1 is reachable.
Tue Apr 9 13:00:02 2019 - [info]
node1(10.0.0.141:3306) (current master)
+--node2(10.0.0.142:3306)
+--node3(10.0.0.143:3306)
Tue Apr 9 13:00:02 2019 - [warning] master_ip_failover_script is not defined.
Tue Apr 9 13:00:02 2019 - [warning] shutdown_script is not defined.
Tue Apr 9 13:00:02 2019 - [info] Set master ping interval 3 seconds.
Tue Apr 9 13:00:02 2019 - [warning] secondary_check_script is not defined. It is highly recommended setting it to check master reachability from two or more routes.
Tue Apr 9 13:00:02 2019 - [info] Starting ping health check on node1(10.0.0.141:3306)..
Tue Apr 9 13:00:02 2019 - [info] Ping(SELECT) succeeded, waiting until MySQL doesn't respond..Como você pode ver, o MHA está monitorando nossa topologia de replicação, verificando se o nó mestre está disponível ou não. Vamos considerar alguns cenários.
Cenário 1 - Falha no MHA
Vamos supor que o MHA não esteja disponível. Como isso afeta o meio ambiente? Obviamente, como o MHA é responsável por monitorar a integridade do mestre e disparar o failover, isso não acontecerá quando o MHA estiver inativo. A falha mestre não será detectada, o failover não acontecerá. O problema é que você não pode realmente executar várias instâncias de MHA ao mesmo tempo. Tecnicamente, você pode fazer isso, embora o MHA reclame do arquivo de bloqueio:
[email protected]:~# masterha_manager --conf=/etc/app1.cnf
Tue Apr 9 13:05:38 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Tue Apr 9 13:05:38 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Tue Apr 9 13:05:38 2019 - [info] Reading server configuration from /etc/app1.cnf..
Tue Apr 9 13:05:38 2019 - [info] MHA::MasterMonitor version 0.58.
Tue Apr 9 13:05:38 2019 - [warning] /var/log/masterha/app1/app1.master_status.health already exists. You might have killed manager with SIGKILL(-9), may run two or more monitoring process for the same application, or use the same working directory. Check for details, and consider setting --workdir separately.No entanto, ele será iniciado e tentará monitorar o ambiente. O problema é quando ambos começam a executar ações no cluster. Pior caso seria se eles decidirem usar escravos diferentes como o candidato mestre e o failover será executado ao mesmo tempo (o MHA usa um arquivo de bloqueio que impede que os failovers subsequentes aconteçam, mas se tudo acontecer ao mesmo tempo, e aconteceu em nosso testes, esta medida de segurança não é suficiente).
Infelizmente, não há uma maneira integrada de executar o MHA de maneira altamente disponível. A solução mais simples será escrever um script que teste se o MHA está em execução e, se não estiver, inicie-o. Tal script teria que ser executado a partir do cron ou escrito na forma de um daemon, se 1 minuto de granularidade do cron não for suficiente.
Cenário 2 - Nó do gerenciador de MHA perdeu conexão de rede com o mestre
Sejamos honestos, esta é uma situação muito ruim. Assim que o MHA não puder se conectar ao mestre, ele tentará realizar um failover. A única exceção é se o secondary_check_script estiver definido e for verificado que o mestre está ativo. Cabe ao usuário definir exatamente quais ações o MHA deve executar para verificar o status do mestre - tudo depende do ambiente e da configuração exata. Outro script muito importante para definir é master_ip_failover_script - este é executado no failover e deve ser usado, entre outros, para garantir que o antigo master não apareça. Se você tiver acesso a maneiras adicionais de alcançar e parar o velho mestre, isso é realmente ótimo. Pode ser ferramentas de gerenciamento remoto como Integrated Lights-out, pode ser acesso a tomadas de energia gerenciáveis (onde você pode simplesmente desligar o servidor), pode ser acesso à CLI do provedor de nuvem, o que possibilitará parar a instância virtual . É de extrema importância parar o antigo mestre - caso contrário, pode acontecer que, depois que o problema de rede acabar, você acabe com dois nós graváveis no sistema, o que é uma solução perfeita para o cérebro dividido, condição em que os dados divergiram entre duas partes do mesmo cluster.
Como você pode ver, o MHA pode lidar muito bem com o failover do MySQL. Definitivamente requer uma configuração cuidadosa e você terá que escrever scripts externos, que serão utilizados para matar o antigo mestre e garantir que o cérebro dividido não aconteça. Dito isso, ainda recomendamos o uso de ferramentas de gerenciamento de failover mais avançadas, como Orchestrator ou ClusterControl, que podem realizar análises mais avançadas do estado da topologia de replicação (por exemplo, utilizando escravos ou proxies para avaliar a disponibilidade do mestre) e quais são e será mantido no futuro. Se você estiver interessado em saber como o ClusterControl executa o failover, gostaríamos de convidá-lo a ler esta postagem no blog sobre o processo de failover no ClusterControl. Você também pode aprender como o ClusterControl interage com o ProxySQL fornecendo failover suave e transparente para seu aplicativo. Você sempre pode testar o ClusterControl baixando-o gratuitamente.
