MySQL----MHA Alta Disponibilidade

1. Teoria MHA

1.1 O que é MHA

MHA (MasterHigh Availability) é um excelente conjunto de software para failover e replicação mestre-escravo em um ambiente MySQL de alta disponibilidade.
O surgimento do MHA é para resolver o problema do ponto único do MySQL.
Durante o processo de failover do MySQL, o MHA pode concluir automaticamente a operação de failover em 0 a 30 segundos.
O MHA pode garantir a consistência dos dados ao máximo durante o processo de failover para alcançar alta disponibilidade no verdadeiro sentido.

1.2 Composição do MHA

• Nó MHA (nó de dados)
  Nó MHA é executado em cada servidor MySQL.

• Gerenciador MHA (nó de gerenciamento)
  O Gerenciador MHA pode ser implantado em uma máquina independente para gerenciar vários clusters mestre-escravo; também pode ser implantado em um nó escravo.
  O MHA Manager detectará regularmente o nó mestre no cluster. Quando o mestre falha, ele pode promover automaticamente o escravo com os dados mais recentes como o novo mestre e, em seguida, apontar novamente todos os outros escravos para o novo mestre. Todo o processo de failover é completamente transparente para o aplicativo.

1.3 Características do MHA

• Durante o processo de failover automático, o MHA tenta salvar o log binário do servidor mestre de inatividade para garantir que os dados não sejam perdidos ao máximo
• O uso da replicação semissíncrona pode reduzir bastante o risco de perda de dados. Se apenas um escravo tiver recebido o log binário mais recente, o MHA poderá aplicar o log binário mais recente a todos os outros servidores escravos, garantindo assim a consistência dos dados de todos os nós
• Atualmente, o MHA suporta arquitetura de um mestre e vários escravos, pelo menos três servidores, ou seja, um mestre e dois escravos

2. Implantação de um mestre e dois escravos do MHA

design experimental

Requisitos satisfeitos: Crie um cluster mysql de replicação de leitura e gravação de alta disponibilidade com um mestre e dois escravos. Quando o servidor mestre cair, o servidor escravo com os dados mais atualizados substituirá o servidor mestre e ocupará o VIP para garantir a operação normal.

Componentes experimentais:

servidor de nó	sistema	nome da CPU	endereço de IP	Ferramentas e serviços de instalação
servidor gerenciador de MHA	CentOS7.9 (64 bits)	gerente	192.168.44.100	Nó MHA e componentes do gerenciador
servidor mestre	CentOS7.9 (64 bits)	mysql1	192.168.44.101	Componentes do nó MHA
servidor Slave1	CentOS7.9 (64 bits)	mysql2	192.168.44.102	Componentes do nó MHA
servidor Slave2	CentOS7.9 (64 bits)	mysql3	192.168.44.103	Componentes do nó MHA
Endereço VIP: 192.168.44.150

1. Sincronização de horário
Realize a sincronização de horário nos servidores master e slave (sincronização de horário online)

2. Modifique os nomes de host dos nós Master, Slave1, Slave2 e gerenciador
hostnamectl set-hostname mysql1
hostnamectl set-hostname mysql2
hostnamectl set-hostname mysql3
hostnamectl set-hostname manager

3. Desligue os firewalls de todos os servidores e modifique os arquivos de hosts dos servidores master e slave

4. Modifique o arquivo de configuração do mestre Mysql /etc/my.cnf dos nós Master, Slave1 e Slave2

##Master 节点##
vim /etc/my.cnf
[mysqld]
server-id = 1
log_bin = mysql-bin
binlog_format = mixed
log-slave-updates = true
relay-log = relay-log-bin
relay-log-index = slave-relay-bin.index

systemctl restart mysqld

##Slave1、Slave2 节点##
vim /etc/my.cnf
server-id = 2 						#三台服务器的 server-id 不能一样
log_bin = mysql-bin
binlog_format = mixed
log-slave-updates = true
relay-log = relay-log-bin
relay-log-index = slave-relay-bin.index

systemctl restart mysqld

5. Crie dois soft links nos nós Master, Slave1 e Slave2

ln -s /usr/local/mysql/bin/mysql /usr/sbin/
ln -s /usr/local/mysql/bin/mysqlbinlog /usr/sbin/

6. Configure o mysql, um mestre e dois escravos
(1) Todos os nós do banco de dados autorizam o mysql
mysql -uroot -p
concedem o escravo de replicação para ' myslave'@'192.168.80.%' identificado por '123'; #Uso síncrono de o banco de dados
concede todos os privilégios em . para 'manager'@'192.168.80.%' identificado por 'mha123'; #manager use

conceder todos os privilégios em . para 'manager'@'mysql1' identificado por 'mha123 ' ; #Evitar que a biblioteca escrava seja incapaz de se conectar à biblioteca principal através do nome do host
conceder todos os privilégios em . conceder todos os privilégios em . para 'manager '@'mysql3' identificado por 'mha123'; liberar privilégios;

(2) Exibir arquivos binários e pontos de sincronização no nó mestre

show master status;

(3) Execute operações de sincronização nos nós Slave1 e Slave2

change master to master_host='192.168.44.100',master_user='myslave',master_password='123',master_log_file='mysql-bin.000002',master_log_pos=1761; 

start slave;

(4) Duas bibliotecas escravas devem ser configuradas para o modo somente leitura:

set global read_only=1;

7. Instale o software MHA
(1) Instale o ambiente dependente de MHA em todos os servidores, primeiro instale a fonte epel

yum install epel-release --nogpgcheck -y

yum install -y perl-DBD-MySQL \
perl-Config-Tiny \
perl-Log-Dispatch \
perl-Parallel-ForkManager \
perl-ExtUtils-CBuilder \
perl-ExtUtils-MakeMaker \
perl-CPAN

(2) Para instalar o pacote de software MHA, você deve primeiro instalar o componente de nó em todos os servidores
, pois cada versão do sistema operacional é diferente, aqui o CentOS7.4 deve escolher a versão 0.57.
O componente do nó deve ser instalado em todos os servidores primeiro e, finalmente, o componente do gerenciador deve ser instalado no nó do gerenciador MHA, porque o gerenciador depende do componente do nó.

cd /opt
tar zxvf mha4mysql-node-0.57.tar.gz
cd mha4mysql-node-0.57
perl Makefile.PL
make && make install

(3) Instale o componente gerenciador no nó do gerenciador MHA

cd /opt
tar zxvf mha4mysql-manager-0.57.tar.gz
cd mha4mysql-manager-0.57
perl Makefile.PL
make && make install

Após a instalação do componente #manager, várias ferramentas serão geradas em /usr/local/bin, incluindo principalmente as seguintes:
masterha_check_ssh verifica o status de configuração SSH do MHA
masterha_check_repl verifica o status de replicação do MySQL
masterha_manger inicia o script do gerenciador
masterha_check_status verifica o MHA atual em execução status
masterha_master_monitor detecção Master está desativado ou não
masterha_master_switch Failover de controle (automático ou manual)
masterha_conf_host Adicionar ou excluir informações do servidor configurado
masterha_stop Fechar gerenciador
#node Após a instalação do componente, vários scripts serão gerados em /usr/local/bin (essas ferramentas são geralmente fornecido pelo MHAManager O script é acionado sem operação manual) principalmente da seguinte forma:
save_binary_logs Salvar e copiar o log binário do mestre
apply_diff_relay_logs Identificar eventos diferenciais de log de relé e aplicar os eventos diferenciais a outro escravo
filter_mysqlbinlog Remover eventos ROLLBACK desnecessários (o MHA não usa mais esta ferramenta)
purge_relay_logs limpa logs de retransmissão (não bloqueia thread SQL)

8. Configure a autenticação sem senha em todos os servidores
(1) Configure a autenticação sem senha para todos os nós do banco de dados no nó gerenciador

ssh-keygen -t rsa 				#一路按回车键
yum -y install sshpass         #安装工具
ssh-copy-id 192.168.44.101
ssh-copy-id 192.168.44.102
ssh-copy-id 192.168.44.103

Modifique o arquivo /etc/ssh/ssh_conf

Modifique o arquivo /etc/ssh/ssh_conf

(2) Configure a autenticação sem senha para os nós do banco de dados mysql2 e mysql3 no mysql1

ssh-keygen -t rsa
ssh-copy-id 192.168.44.102
ssh-copy-id 192.168.44.103

(3) Configure a autenticação sem senha para os nós do banco de dados mysql1 e mysql3 no mysql2

ssh-keygen -t rsa
ssh-copy-id 192.168.44.101
ssh-copy-id 192.168.44.103

(4) Configure a autenticação sem senha para os nós do banco de dados mysql1 e mysql2 no mysql3

ssh-keygen -t rsa
ssh-copy-id 192.168.44.101
ssh-copy-id 192.168.44.102

9. Configure o MHA no nó gerenciador

(1) Copie os scripts relevantes para o diretório /usr/local/bin no nó gerenciador

cp -rp /opt/mha4mysql-manager-0.57/samples/scripts /usr/local/bin
//拷贝后会有四个执行文件
ll /usr/local/bin/scripts/

master_ip_failover #Script de gerenciamento de VIP durante a comutação automática
master_ip_online_change #Gerenciamento de VIP durante a comutação online
power_manager #Script para desligar o host após falha
send_report #Script para enviar alarme após failover

(2) Copie o script de gerenciamento VIP mencionado acima durante a troca automática para o diretório /usr/local/bin, onde o script master_ip_failover é usado para gerenciar VIP e failover

cp /usr/local/bin/scripts/master_ip_failover /usr/local/bin

(3) O conteúdo modificado é o seguinte: (Exclua o conteúdo original, copie diretamente e modifique os parâmetros relacionados ao vip. Você pode inserir: definir colar antes de copiar para resolver o problema de colagem do vim fora de ordem) vim /usr/local/
bin /master_ip_failover

#!/usr/bin/env perl
use strict;
use warnings FATAL => 'all';
 
use Getopt::Long;
 
my (
    $command, $orig_master_host, $orig_master_ip,$ssh_user,
    $orig_master_port, $new_master_host, $new_master_ip,$new_master_port,
    $orig_master_ssh_port,$new_master_ssh_port,$new_master_user,$new_master_password
);
 
# 这里定义的虚拟IP配置要注意，这个ip必须要与你自己的集群在同一个网段，否则无效
my $vip = '192.168.44.150/24';
my $key = '1';
# 这里的网卡名称 “ens33” 需要根据你机器的网卡名称进行修改
# 如果多台机器直接的网卡名称不统一，有两种方式，一个是改脚本，二是把网卡名称修改成统一
# 我这边实际情况是修改成统一的网卡名称
my $ssh_start_vip = "sudo /sbin/ifconfig ens33:$key $vip";
my $ssh_stop_vip = "sudo /sbin/ifconfig ens33:$key down";
my $ssh_Bcast_arp= "sudo /sbin/arping -I ens33 -c 3 -A $vip";

GetOptions(
    'command=s'          => \$command,
    'ssh_user=s'         => \$ssh_user,
    'orig_master_host=s' => \$orig_master_host,
    'orig_master_ip=s'   => \$orig_master_ip,
    'orig_master_port=i' => \$orig_master_port,
    'orig_master_ssh_port=i' => \$orig_master_ssh_port,
    'new_master_host=s'  => \$new_master_host,
    'new_master_ip=s'    => \$new_master_ip,
    'new_master_port=i'  => \$new_master_port,
    'new_master_ssh_port' => \$new_master_ssh_port,
    'new_master_user' => \$new_master_user,
    'new_master_password' => \$new_master_password
 
);
 
exit &main();
 
sub main {
    $ssh_user = defined $ssh_user ? $ssh_user : 'root';
    print "\n\nIN SCRIPT TEST====$ssh_user|$ssh_stop_vip==$ssh_user|$ssh_start_vip===\n\n";
 
    if ( $command eq "stop" || $command eq "stopssh" ) {
 
        my $exit_code = 1;
        eval {
            print "Disabling the VIP on old master: $orig_master_host \n";
            &stop_vip();
            $exit_code = 0;
        };
        if ($@) {
            warn "Got Error: $@\n";
            exit $exit_code;
        }
        exit $exit_code;
    }
    elsif ( $command eq "start" ) {
 
        my $exit_code = 10;
        eval {
            print "Enabling the VIP - $vip on the new master - $new_master_host \n";
            &start_vip();
        &start_arp();
            $exit_code = 0;
        };
        if ($@) {
            warn $@;
            exit $exit_code;
        }
        exit $exit_code;
    }
    elsif ( $command eq "status" ) {
        print "Checking the Status of the script.. OK \n";
        exit 0;
    }
    else {
        &usage();
        exit 1;
    }
}
 
sub start_vip() {
    `ssh $ssh_user\@$new_master_host \" $ssh_start_vip \"`;
}
sub stop_vip() {
    `ssh $ssh_user\@$orig_master_host \" $ssh_stop_vip \"`;
}
 
sub start_arp() {
    `ssh $ssh_user\@$new_master_host \" $ssh_Bcast_arp \"`;
}
sub usage {
    print
    "Usage: master_ip_failover --command=start|stop|stopssh|status --ssh_user=user --orig_master_host=host --orig_master_ip=ip --orig_master_port=port --new_master_host=host --new_master_ip=ip --new_master_port=port\n";
}

(4) Crie o diretório do software MHA e copie o arquivo de configuração, aqui use o arquivo de configuração app1.cnf para gerenciar o servidor do nó mysql

Criado no servidor do gerenciador

 mkdir -p /opt/mysql-mha/mha

Criado em todos os servidores

 mkdir -p /opt/mysql-mha/mha-node

Crie um arquivo no servidor do gerenciador

vim /opt/mysql-mha/mysql-mha.cnf
[server default]
manager_log=/opt/mysql-mha/manager.log
manager_workdir=/opt/mysql-mha/mha
master_binlog_dir=/usr/local/mysql/data
master_ip_failover_script=/usr/local/bin/master_ip_failover
master_ip_online_change_script=/usr/local/bin/master_ip_online_change
user=manager
password=mha123
port=3306
ping_interval=1
remote_workdir=/opt/mysql-mha/mha-node
repl_user=myslave
repl_password=123456
secondary_check_script=/usr/local/bin/masterha_secondary_check -s 192.168.44.102 -s 192.168.44.103
shutdown_script=""
ssh_user=root

[server1]
hostname=192.168.44.101
port=3306

[server2]
candidate_master=1
check_repl_delay=0
hostname=192.168.44.102
port=3306

[server3]
hostname=192.168.44.103
port=3306

[padrão do servidor]
manager_log=/opt/mysql-mha/manager.log #Especificar o caminho de log do gerenciador
manager_workdir=/opt/mysql-mha/mha #Especificar o diretório de trabalho do gerenciador
master_binlog_dir=/usr/local/mysql/data #Especificar o mestre para salvar A localização do binlog, o caminho aqui deve ser consistente com o caminho do binlog configurado no mestre, para que o MHA possa encontrar
master_ip_failover_script=/usr/local/bin/master_ip_failover #Configurando o script de comutação para failover automático , que é o script acima
master_ip_online_change_script=/usr/local/bin/master_ip_online_change #Defina o script de troca para troca manual
user=manager #Defina a senha da conta para mha acessar o banco de dados
password=mha123 #Defina a senha da conta para mha acessar the database
ping_interval=1 #Defina o tempo para monitorar a biblioteca principal e enviar pacotes de ping Intervalo, o padrão é 3 segundos, e o failover será executado automaticamente quando não houver resposta após três tentativas remote_workdir=/opt/mysql-mha/
mha -node #Especifica o diretório de trabalho de mha no nó remoto
repl_user=myslave #Define o usuário para replicação mestre-escravo
repl_password= 123456 #Define a senha do usuário para replicação mestre-escravo
report_script=/usr/local/send_report #Configuração para enviar um lembrete por e-mail quando ocorrer um failover
second_check_script=/usr/local/bin/masterha_secondary_check -s 192.168.44.102 -s 192.168.44.103 #Especificar o endereço IP do servidor escravo para verificar
shutdown_script= "" #Defina o script para fechar o host com falha após a ocorrência da falha (a principal função do script é desligar o host para evitar divisão do cérebro, que não é usado aqui) ssh_user=root #Defina o nome de usuário de login de
ssh
[server1]
hostname=192.168.44.101
port=3306
[server2]
hostname=192.168.44.102
port=3306
candidate_master=1
#Set as a candidate master. Depois de configurar este parâmetro, a biblioteca slave será promovida à master library após a master -interrupção do escravo ocorre, mesmo se a biblioteca do escravo não for o escravo mais recente no cluster
check_repl_delay =0
#Por padrão, se um escravo ficar atrás do mestre em mais de 100 milhões de logs de retransmissão, o MHA não selecionará o escravo como um novo mestre, pois demora muito para restaurar o slave; configurando check_repl_delay=0, o MHA Trigger switchover irá ignorar o atraso de replicação ao selecionar um novo master. Este parâmetro é muito útil para hosts com candidate_master=1, pois o master candidato deve ser o novo mestre durante o processo de transição
[servidor3]
hostname=192.168.44.103
porta=3306

10. Adicione vip ao servidor principal

ifconfig ens33:1 192.168.44.150/24

11,10. Teste a autenticação sem senha ssh no nó do gerenciador. Se estiver normal, a saída será bem-sucedida, conforme mostrado abaixo.

masterha_check_ssh -conf=/opt/mysql-mha/mysql-mha.cnf

12. Teste a conexão mestre-escravo do mysql no nó gerenciador e as palavras MySQL Replication Health is OK aparecerão no final, indicando que está normal. Do seguinte modo.

masterha_check_repl -conf=/opt/mysql-mha/mysql-mha.cnf

13, 12. Inicie o MHA no nó gerenciador

nohup masterha_manager \
--conf=/opt/mysql-mha/mysql-mha.cnf \
--remove_dead_master_conf \
--ignore_last_failover < /dev/null > /var/log/mha_manager.log 2>&1 &

–remove_dead_master_conf: Este parâmetro significa que quando ocorrer a troca mestre-escravo, o ip da antiga biblioteca mestre será removido do arquivo de configuração.
–ignore_last_failover: Por padrão, se o MHA detectar paradas contínuas e o intervalo entre duas paradas for menor que 8 horas, o Failover não será executado. O motivo dessa limitação é evitar o efeito ping-pong. Este parâmetro significa ignorar o arquivo gerado pela última chave de disparo do MHA. Por padrão, após a troca do MHA ocorrer, ele será registrado no arquivo de log app1.failover.complete. Se o arquivo existir no diretório quando o switch for feito novamente na próxima vez, não será permitido Trigger switchover, a menos que o arquivo seja excluído após a primeira switchover, por conveniência, aqui é definido como –ignore_last_failover.
● Use e execute o programa em segundo plano: o resultado será enviado para o terminal; use Ctrl+C para enviar o sinal SIGINT, o programa é imune; feche a sessão e envie o sinal SIGHUP, o programa é fechado.
● Use nohup para executar o programa: o resultado será enviado para nohup.out por padrão; use Ctrl+C para enviar um sinal SIGINT e o programa será fechado; feche a sessão e envie um sinal SIGHUP e o programa será imune.
● Use nohup e & para iniciar o programa nohup ./test &: Simultaneamente imune aos sinais SIGINT e SIGHUP.

14. Verifique o status do MHA, você pode ver que o mestre atual é o nó mysql1.

masterha_check_status --conf=/opt/mysql-mha/mysql_mha.cnf

15. Verifique o log do MHA e você verá que o mestre atual é 192.168.80.10, conforme mostrado abaixo.

cat /opt/mysql-mha/manager.log | grep "current master"

16. Verifique se existe o endereço VIP 192.168.80.200 de mysql1.Este endereço VIP não desaparecerá porque o nó gerenciador interrompe o serviço MHA.
ifconfig

//Para fechar o serviço do gerenciador, você pode usar o seguinte comando.
masterha_stop --conf=/opt/mysql-mha/mysql_mha.cnf
ou pode ser fechado diretamente matando o ID do processo.

simulação de falha

1. Monitore e observe os registros de log no nó gerenciador

2. Pare o serviço mysql no nó mestre mysql1

systemctl stop mysqld

registro do gerente:

escravo1:

escravo2:

#Após uma troca automática normal, o processo MHA será encerrado. O HMA modificará automaticamente o conteúdo do arquivo app1.cnf e excluirá o nó mysql1 de tempo de inatividade. Verifique se mysql2 assume o Algoritmo do VIP
ifconfig
failover banco de dados principal alternativo:
1．Geralmente, a biblioteca escrava é julgada de (posição/GTID) para julgar se é boa ou ruim, e os dados são diferentes. O escravo mais próximo do mestre torna-se o mestre candidato.
2. Se os dados forem consistentes, selecione uma biblioteca principal alternativa de acordo com a ordem dos arquivos de configuração.
3. Defina o peso (candidate_master=1) e o candidato mestre é forçado a ser designado de acordo com o peso.
(1) Por padrão, se um escravo ficar 100M atrás dos logs de retransmissão do mestre, ele falhará mesmo se tiver peso.
(2) Se check_repl_delay=0, mesmo que haja muitos logs atrasados, ele é forçado a ser selecionado como mestre de backup.

Veja o arquivo /opt/mysql-mha/mysql-mha.cnf

Etapas de solução de problemas:

1. reparar mysql
systemctl reiniciar mysqld

2. Conserte o mestre-escravo # Visualize o arquivo binário e o ponto de sincronização mostre o status do mestre
no servidor de biblioteca mestre atual mysql2 ;

#Execute operação síncrona no servidor de banco de dados mestre original mysql1
altere master para master_host='192.168.44.101', master_user='myslave', master_password='123456', master_log_file='mysql-bin.000001', master_log_pos=2647;

iniciar escravo;