MHA para arquitetura de alta disponibilidade do cluster MySQL
Eu escrevi um artigo anteriormente: Falando sobre a arquitetura de alta disponibilidade do cluster MySQL . Desde então, muitos pequenos parceiros me perguntaram em segundo plano ou em outros canais, quando existem artigos detalhados relacionados ao gerenciamento de configurações, portanto, os trabalhadores migrantes também classificam as várias estruturas anteriores, uma a uma, e as publicam. Em seguida, o planejamento geral e a operação de configuração da arquitetura MHA serão lançados hoje.
1. Introdução à arquitetura
Atualmente, o MHA (Master High Availability) é uma solução relativamente madura na alta disponibilidade do MySQL, como um software de alta disponibilidade para promoção de failover e master-slave no ambiente de alta disponibilidade do MySQL. No processo de failover do MySQL, o MHA pode concluir automaticamente a operação de failover do banco de dados dentro de 0 a 30 segundos e, no processo de failover, o MHA pode garantir a consistência dos dados na maior medida possível para alcançar a verdadeira Alta disponibilidade no sentido.
O software consiste em duas partes: MHA Manager (nó de gerenciamento) e MHA Node (nó de dados). O MHA Manager pode ser implementado em uma máquina independente para gerenciar vários clusters master-slave, ou pode ser implementado em um nó slave. O nó MHA é executado em cada servidor MySQL, o MHA Manager detecta regularmente o nó mestre no cluster. Quando o mestre falha, ele pode promover automaticamente o escravo de dados mais recente para o novo mestre e, em seguida, redirecionar todos os outros escravos para o novo Mestre. Todo o processo de failover é completamente transparente para o aplicativo.
Atualmente, o MHA suporta principalmente uma arquitetura mestre-escravo.Para criar um MHA, no mínimo três servidores de banco de dados devem estar em um cluster de replicação.Um mestre e dois escravos, ou seja, um serve como mestre, um serve como mestre em espera e o outro serve como escravo , Porque pelo menos três servidores são necessários.
2. Planejamento de implantação
Informações do sistema
[root@db250 ~]# cat /etc/redhat-release
CentOS release 6.8 (Final)
[root@db250 ~]# uname -r 2.6.32-642.el6.x86_64Versão do banco de dados
mysql-5.7.17Planejamento ambiental
Db250 集群管理节点 192.168.4.250
Db251 主库 192.168.4.251 Db253 从库（备主库） 192.168.4.253 Db254 从库 192.168.4.254O diagrama da arquitetura é o seguinte
3. Configure o arquivo Hosts
Configure o arquivo hosts
cat>>/etc/hosts<<EOF
192.168.4.250 db250
192.168.4.251 db251 192.168.4.253 db253 192.168.4.254 db254 EOFVerificar após a configuração
[root@db254 ~]# tail -4 /etc/hosts
192.168.4.250 db250
192.168.4.251 db251 192.168.4.253 db253 192.168.4.254 db2544. Configuração de login sem segredo do SSH
Configurar login sem chave SSH
ssh-keygen -t rsa
ssh-copy-id 192.168.4.251
ssh-copy-id 192.168.4.253 ssh-copy-id 192.168.4.254---- As duas etapas acima precisam configurar todos os servidores
5. Instale o MySQL e configure a sincronização master-slave
Sincronize dados da biblioteca mestre para a biblioteca escrava, consulte o artigo anterior para operação de sincronização mestre-escravo
Sistema Linux banco de dados MySQL sincronização mestre-escravo processo de combate real
Verifique o status da sincronização mestre-escravo
mysql -uroot -p123456 -e "show slave status\G"|egrep "Slave_IO_Running|Slave_SQL_Running"
Configurar usuários e permissões de gerenciamento MHA em todos os nós do banco de dados
grant all on *.* to mha@'192.168.4.%' identified by '123456';Até agora, todo o ambiente básico foi configurado
6. Instale e configure o MHA
https: //downloads.mariadb.com ... #download endereço
Passe o pacote de instalação relevante para outros nós
Todo o processo de instalação do serviço MHA é o seguinte:
Instalar dependências
yum install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes –yInstalação do nó de gerenciamento
rpm -ivh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
yum localinstall -y mha4mysql-manager-0.52-0.noarch.rpm yum localinstall -y mha4mysql-node-0.52-0.noarch.rpmOutra instalação do nó
yum localinstall -y mha4mysql-node-0.52-0.noarch.rpmOs erros podem ser relatados durante o processo de instalação, siga as instruções para resolver
O processo de configuração é o seguinte:
[root@db250 ~]# mkdir /mha
[root@db250 ~]# vim /etc/masterha_default.cnf
[server default] #刚才授权的mysql管理用戶名 user=mha password=123456 manager_workdir=/mha manager_log=/mha/manager.log remote_workdir=/mha #ssh免密钥登录的帐号名 ssh_user=root #mysql复制帐号，用来在主从机之间同步二进制日志等 repl_user=slave repl_password=123456 #ping间隔，用来检测master是否正常 ping_interval= 1 [server1] hostname=db251 master_binlog_dir=/var/lib/mysql #候选master挂掉时候优先让它顶 candidate_master=1 [server2] hostname=db253 master_binlog_dir=/var/lib/mysql/ candidate_master=1 [server3] hostname=db254 master_binlog_dir=/var/lib/mysql/ no_master=1 #不能成为master
------ Os comandos de detecção relevantes são os seguintes ------------------
masterha_check_ssh Verifique o status de configuração SSH do MHA
masterha_check_repl Verifique o status de replicação do MySQL
masterha_manger Inicie o MHA
masterha_check_status Verifique o status atual de execução do MHA
masterha_master_monitor Verifique se o master está inoperante
masterha_master_switch Controle de failover (automático ou manual)
masterha_conf_host adicione ou exclua as informações do servidor configurado
Detectar login sem senha do SSH
Sincronização de detecção
7. Inicie o serviço MHA
[root@db250 ~]# masterha_manager --conf=/etc/masterha_default.cnf &
[1] 2035Fri Sep 1 01:52:25 2017 - [info] Reading default configuratoins from /etc/masterha_default.cnf.. Fri Sep 1 01:52:25 2017 - [info] Reading application default configurations from /etc/masterha_default.cnf.. Fri Sep 1 01:52:25 2017 - [info] Reading server configurations from /etc/masterha_default.cnf..Exibir log de inicialização
Também pode ser visto no log de inicialização que o DBmaster atual é o servidor DB251, indicando uma inicialização bem-sucedida.
8. Comutação automática de falha no teste
Em seguida, simule a falha, desative o db251
[root@db251 ~]# /etc/init.d/mysqld stop
Stopping mysqld: [ OK ]Verifique o log e verifique se o
novo banco de dados mestre foi alternado para o servidor db253. Em seguida, verifique a sincronização mestre-escravo.
Quando o servidor principal original é reparado, você precisa alterar manualmente o mestre original para escravo
[root@db250 ~]# grep -i"All other slaves should start" /mha/manager.log
Fri Sep 1 01:59:05 2017 - [info] All other slaves should start replicationfrom here. Statement should be: CHANGE MASTER TO MASTER_HOST='db253 or192.168.4.253', MASTER_PORT=3306,MASTER_LOG_FILE='slave-bin.000003',MASTER_LOG_POS=760546, MASTER_USER='slave', MASTER_PASSWORD='xxx';
Constatou que a biblioteca mestre original se tornou uma nova biblioteca escrava depois que ficou on-line e depois sincronizada com o DB253
Sincronização de gravação do mestre de teste
A sincronização é normal
Clique em-> Caminho técnico para os trabalhadores migrantes para seguir a conta pública do WeChat e a caixa de diálogo responder à palavra-chave: 1024 Você pode obter uma cópia dos produtos secos técnicos mais recentes da 2048G: incluindo operação e manutenção do sistema, banco de dados, redis, MogoDB, e-book, cursos básicos de Java, Projeto de combate real em Java, tutorial abrangente do arquiteto, projeto de combate real do arquiteto, big data, contêiner Docker, ELK Stack, aprendizado de máquina, vídeo de entrevista BAT, etc.