[MHA] Verificación MHA del clúster de alta disponibilidad de Mysql

Tabla de contenido

concepto

desplegar

Instalar MHA

Configurar la verificación del par de claves SSH

instalar mysql

Detección

fracaso de la prueba

reparar


concepto


MHA (Master High Availability) es actualmente una solución relativamente madura para la alta disponibilidad de MysaL. Fue desarrollada por empleados de Voushimaton de la compañía japonesa DeNA (que ahora trabaja en Facebook). Es un excelente conjunto de soluciones de conmutación por error para entornos de alta disponibilidad de MysaL. Software de disponibilidad con roles maestro-esclavo mejorados. Durante el proceso de conmutación por error de MysaL, MHA puede completar automáticamente la operación de conmutación por error maestro-esclavo de la base de datos en un plazo de 0 a 30 segundos, y durante el proceso de conmutación por error, MHA puede garantizar la coherencia de los datos en la mayor medida posible para garantizar una verdadera alta disponibilidad.


MHA consta de dos partes: MHA Manager (nodo de gestión) y MHA Node (nodo de datos). MHA Manager
se puede implementar en una máquina independiente para administrar múltiples clústeres maestro-esclavo, o se puede implementar en un nodo esclavo. El nodo MHA se ejecuta en cada servidor MysaL y servidor Manager. MHA Manager detectará periódicamente el nodo maestro en el clúster. Cuando el maestro falla, puede promover automáticamente el esclavo con los datos más recientes al nuevo maestro, y luego todos los demás esclavos redireccionan al maestro recién ascendido. Todo el proceso de conmutación por error es completamente transparente al nivel de la aplicación.
931 Examen de Escritura Oral Zhema · Calificación de contenido oral


Durante el proceso de conmutación por error automática de MHA, MHA intentará guardar el registro binario del servidor principal de la máquina contenedora para garantizar que no se pierdan datos en gran medida, pero esta operación es probabilística. Por ejemplo, si el hardware del servidor principal falla o no se puede acceder a él a través de ssh, MHA no puede guardar los registros binarios y solo realiza una conmutación por error, perdiendo así los datos más recientes.
Al utilizar la replicación semisincrónica de MvSaL 5.5, puede reducir el riesgo de pérdida de datos. MHA se puede combinar con replicación semisincrónica. Si solo un esclavo ha recibido el último registro binario, MHA puede aplicar el último registro binario a todos los demás servidores esclavos, garantizando así la coherencia de los datos en todos los nodos.


Actualmente, MHA admite principalmente una arquitectura de un maestro y múltiples esclavos. Para construir MHA, un clúster de replicación MysaL debe tener
al menos tres servidores de bases de datos, un maestro y dos esclavos, es decir, uno actúa como maestro, el otro actúa como maestro de respaldo y el otro actúa como La base de datos esclava requiere al menos tres servidores. Debido a consideraciones de costo de la máquina, Taobao también la ha modificado sobre esta base. Actualmente, Taobao TMHA admite un maestro y un esclavo. Además, para aquellos que quieran realizar una configuración rápida, pueden consultar: Configuración rápida de MHA. De hecho, también podemos usar 1 maestro y 1 esclavo para nuestro propio uso, pero el host maestro no se puede cambiar una vez que está inactivo. y el binlog
no se puede completar .
Después de que el proceso mysgld del maestro falla, el cambio aún puede realizarse exitosamente y se puede completar el binlog.

Flujo de trabajo
(1) Intente guardar eventos de registro binario del maestro bloqueado
(2) Identifique el servidor esclavo con la última actualización:
(3) Aplique el registro de retransmisión de diferencia a otros esclavos;
(4) Aplique eventos de registro binario (eventos binlog) guardados desde el maestro;
(5) Promocionar un esclavo al nuevo servidor maestro:
(6) Apuntar otras conexiones esclavas al nuevo maestro para la replicación maestro-esclavo:

El software MHA consta de dos partes, el kit de herramientas Manager y el kit de herramientas Node. Las instrucciones específicas son las siguientes


El kit de herramientas de Manager incluye principalmente las siguientes herramientas:

masterha_check_ssh Verificar el estado de configuración SSH de MHA
masterha_check_rep Verificar el estado de replicación de MysQL
masterha_manger Iniciar MHA
masterha_check_status Verificar el estado de ejecución actual de MHA
masterha_master_monitor Verificar si el maestro está inactivo
masterha_master_switch Controlar la conmutación por error (automática o manual)
masterha_conf_host Agregar o eliminar información del servidor configurado

El kit de herramientas de Node (estas herramientas generalmente se activan mediante scripts de MHA Manager y no requieren operación humana) incluye principalmente las siguientes herramientas:

guardar binario_logs Guardar y copiar el registro binario del maestro
aplicar registros de retransmisión diferencial Identificar eventos de registro de retransmisión diferencial y aplicar los eventos diferenciales a otros
esclavos
filter_mysqlbinlog Eliminar eventos ROLLBACK innecesarios (MHA ya no usa esta herramienta)
purgar registros de retransmisión Borrar registro de retransmisión (no bloquea SQL hilo)

desplegar


Instalar MHA


Preparar el ambiente

5 máquinas virtuales

Se cambió el nombre de cinco máquinas virtuales para dividirlas mejor.

Instrucción: hostnamectl set-hostname server

Actualizar: bash

Gerente                       

Servidor principal                   

Del servidor 1                 

Del servidor 2                 

Del servidor 3                 

Instalación de toda la máquina.

Desactivar el cortafuegos

Ver yum, ver montaje de CD

Descargar fuente de liberación de epel

Puedes introducirlo directamente en la máquina virtual.

Luego use rpm -ivh para instalar

rpm -ivh epel-lanzamiento-último-7.noarch.rpm

La instalación de los archivos fuente de Alibaba también se realiza directamente en la máquina virtual.

También puedes instalarlo usando el siguiente comando.

wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo

Luego instale MHA
 

yum install -y perl-DBD-MySQL.x86_64 perl-DBI.x86_64 perl-CPAN perl-ExtUtils-CBuilder perl-ExtUtils-MakeMaker

Instalar el nodo MHA

Si hay un problema con la transmisión rz, puede introducirlo directamente en la máquina virtual.

cd para encontrar el paquete de software del nodo y simplemente descomprímalo en el directorio actual (es necesario operar las cinco máquinas virtuales)

tar xf mha4mysql-nodo-0.56.tar.gz

Ingrese al directorio descomprimido para ejecutar

Configuración a través de fuente perl

Perl Makefile.PL

Luego compila e instala

hacer && hacer instalar

Después de instalar MHA Node, los siguientes scripts (4 archivos de script) se generarán en /usr/local/bin
 

ls -l /usr/local/bin/

Instalar MHA Manager

Sólo es necesario instalar una máquina (servidor1)

Instale el módulo perl del que depende MHA Manger

yum install -y perl perl-Log-Dispatch perl-Parallel-ForkManager perl-DBD-MySQL perl-DBI perl-Time-HiRes

Luego necesita instalar el paquete perl para introducirlo en la máquina virtual.

O abra una ventana con rz e introdúzcala en la máquina virtual.

perl-Config-Tiny-2.14-7.el7.noarch.rpm

esta vista

 Instalar usando rpm -ivh

perl-Config-Tiny-2.14-7.el7.noarch.rpm

Instalar el paquete MHA Manager

rz abre la ventana y accede a la máquina virtual.

mha4mysql-manager-0.56.tar.gz 

Luego opere el siguiente comando

tar xf mha4mysql-manager-0.56.tar.gz descomprimir

cd mha4mysql-manager-0.56/ ingrese al directorio

perl Makefile.PL compila archivos en lenguaje perl

make && make install compilar e instalar

Una vez completada la instalación, habrá los siguientes archivos de secuencia de comandos (13 archivos de secuencia de comandos)

ls -l /usr/local/bin/

Configurar la verificación del par de claves SSH


[Tenga en cuenta que cada máquina virtual debe implementar un inicio de sesión sin contraseña] ! !

Primero analice la configuración de cada máquina virtual.

vim/etc/hosts

Generar clave

ssh-keygen

Se puede generar 4 veces seguidas en un bucle.

para i en 115 116 117 126; hacer ssh-copy-id 192.168.1.$i; hecho

Verificar inicio de sesión sin contraseña

servidor ssh1...5


instalar mysql


servidor2....5

Es necesario instalar cuatro hosts.

yum -y instalar mariadb servidor-mariadb

Luego inicia el sistema

systemctl iniciar mariadb

Después de reiniciar

Ingrese el comando para ver el puerto

netstat-lnpt | agarre: 3306

ingrese el comando

mysqladmin -u root contraseña 123456 establece la contraseña inicial para la base de datos

Establecer el archivo de configuración de replicación maestro-esclavo

vim /etc/mi.cnf

【servidor2】Maestro

ID del servidor = 1
log-bin = master-bin
log-slave-updates = verdadero
relé_log_purge = 0 

【servidor3】maestro auxiliar

ID del servidor = 2
log-bin = master-bin
log-slave-updates = verdadero
relé_log_purge = 0 

 【servidor4】de

server-id=3
log-bin=mysql-bin
relé-log=esclavo-relé-bin
log-slave-updates=true
relé_log_purge=0

【servidor5】de

server-id=4
log-bin=mysql-bin
relé-log=esclavo-relé-bin
log-slave-updates=true
relé_log_purge=0

Reiniciar el servidor

systemctl reiniciar mariadb

Autorizar

Todas las bases de datos del servidor 2...4 requieren autorización

Crear usuarios autorizados

4 máquinas virtuales inician sesión en mysql

mysql-uroot-p123456

luego autorizar

otorgar esclavo de replicación en *.* a 'repl'@'192.168.1.%' identificado por '123456';

Actualizar autorización

privilegios de descarga;

Verificar el estado de la biblioteca principal

 mostrar estado maestro;

Luego, tres servidores esclavos designan al servidor maestro.

Apague el servidor esclavo primero

detener esclavo;

Introduzca la siguiente

CAMBIAR MAESTRO A

  MASTER_HOST='192.168.1.115',

  MASTER_USER='responder',

  MASTER_PASSWORD='123456',

  MASTER_LOG_FILE='mastar-binlog.000001',

  MASTER_LOG_POS=472;

 Ingrese el siguiente comando para ver el estado de replicación en la base de datos MySQL

mostrar estado de esclavo\G 

【! ¡Aviso! ! ! Si algo sale mal, prueba este comando para solucionar el problema]

detener esclavo;
restablecer esclavo;
establecer global sql_slave_skip_counter =1;
empezar esclavo

Establecer estado de solo lectura desde el servidor

Después de hacer esto, el servidor esclavo ya no podrá escribir nada.

Escribir fuera de la biblioteca

mysql -uroot -p123456 -e 'establecer global read_only=1;'

Cómo escribir curry

establecer global read_only=1;

Cree el usuario de monitoreo server2....5  para servir al nodo de monitoreo con permisos más altos

otorgar todos los privilegios en *.* a 'root'@'192.168.1.%' identificado por '123456';

Actualizar permisos

privilegios de descarga;

El siguiente paso es autorizar su propio nombre de host.

Ellos son:

otorgar todos los privilegios en *.* a 'root'@'server2' identificado por '123456';

otorgar todos los privilegios en *.* a 'root'@'server3' identificado por '123456';

otorgar todos los privilegios en *.* a 'root'@'server4' identificado por '123456';

otorgar todos los privilegios en *.* a 'root'@'server5' identificado por '123456';

Volver al servidor1

Crear directorio /etc/masterha Crear directorio de configuración Copiar archivos de plantilla

mkdir /etc/masterha

Luego copie mha4mysql-manager-0.56 en la raíz al directorio que acaba de crear.

cp mha4mysql-manager-0.56/samples/conf/app1.cnf /etc/masterha

Modificar la configuración del archivo recién copiado.

vim /etc/masterha/app1.cnf

[valor predeterminado del servidor]
manager_workdir=/var/log/masterha/app1
manager_log=/var/log/masterha/app1/manager.log
master_binlog_dir=/var/lib/mysql
master_ip_failover_script= /usr/local/bin/master_ip_failover

contraseña=123456
usuario=root
ping_interval=1
remote_workdir=/tmp
reql_password=123456
reql_user=repl


[servidor1]
nombre de host =
puerto del servidor2 = 3306


[servidor2]
nombre de host=servidor3
candidato_master=1
puerto=3306
check_repl_delay=0


[servidor3]
nombre de host =
puerto del servidor4 = 3306

[servidor4]
nombre de host =
puerto del servidor5 = 3306
 

Configurar script de conmutación por error

Después de abrir, copie el contenido del script para modificar el VIP y modificar el nombre de la tarjeta de red.

vim /usr/local/bin/master_ip_failover

#!/usr/bin/env perl 

utilizar estricto; 
utilizar advertencias FATAL => 'todos'; 
utilizar Getopt::Long; 
mi ( 
$comando, $ssh_user, $orig_master_host, $orig_master_ip, 
$orig_master_port, $new_master_host, $new_master_ip, $new_master_port, 
); 
mi $vip = '192.168.200.100';              
mi clave $ = "1";     
mi $ssh_start_vip = "/sbin/ifconfig ens32:$key $vip";
mi $ssh_stop_vip = "/sbin/ifconfig ens32:$tecla abajo"; 
$ssh_user = "raíz"; 
GetOptions( 
'command=s' => \$command, 
'ssh_user=s' => \$ssh_user, 
'orig_master_host=s' => \$orig_master_host, 
'orig_master_ip=s' => \$orig_master_ip, 

'new_master_host=s' => \$new_master_host, 
'new_master_ip=s' => \$new_master_ip, 
'new_master_port=i' => \$new_master_port, 
); 
salir &main(); 
sub main { 
print "\n\nPRUEBA DE SCRIPT EN ====$ssh_stop_vip==$ssh_start_vip===\n\n"; 
if ($command eq "stop" || $command eq "stopssh" ) { 
# Se pasan $orig_master_host, $orig_master_ip, $orig_master_port. 
# Si administra la dirección IP maestra en la base de datos del catálogo global, 
# invalide orig_master_ip aquí. 
mi $código_salida = 1; 
#eval { 
# print "Desactivando el VIP en el maestro antiguo: 




print "Desactivando el VIP en el maestro antiguo: $orig_master_host \n"; 
#mi $ping=`ping -c 1 10.0.0.13 | grep "pérdida de paquetes" | awk -F',' '{imprimir $3}' | awk '{imprimir $1}'`; 
#if ($ping le "90.0%"&& $ping gt "0.0%" ){ 
#$exit_code = 0; 
#} 
#else { 
&stop_vip(); 
# actualizando el catálogo global, etc. 
$exit_code = 0; 
#} 
}; 

if ($@) { 
advertencia "Error: $@\n"; 
salir $código_salida; 

salir $código_salida; 

elsif ($command eq "start") { # se pasan todos los argumentos. # Si administra la dirección IP maestra en la base de datos del catálogo global,  # active new_master_ip aquí. # También puedes otorgar acceso de escritura (crear usuario, configurar read_only=0, etc.) aquí. mi $código_salida = 10; eval {  print "Habilitando VIP - $vip en el nuevo maestro - $new_master_host \n"; &start_vip(); $código_salida = 0; }; si ($@) {  advertir $@; salir $código_salida; salir $código_salida; 
















elsif ($command eq "status" ) { 
print "Comprobando el estado del script... OK \n"; 
`ssh $ssh_user\@$orig_master_ip \" $ssh_start_vip \"`; 
salir 0; 

más { 
&usage(); 
salida 1; 


# Una llamada simple al sistema que habilita el VIP en el nuevo 
sub maestro start_vip() { 
`ssh $ssh_user\@$new_master_host \" $ssh_start_vip \"`; 

# Una llamada simple al sistema que deshabilita el VIP en el 
sub old_master stop_vip() { 
`ssh $ssh_user\@$orig_master_host \" $ssh_stop_vip \"`; 

subuso { 
imprimir 
"Uso: master_ip_failover --command=start|stop|stopssh|status --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"; }

Una vez completada la configuración, otorgue x permisos de ejecución.

chmod +x /usr/local/bin/master_ip_failover

Detección


Compruebe si el estado de comunicación MHA ssh es normal

masterha_check_ssh --conf=/etc/masterha/app1.cnf

Regresar exitosamente significa que no hay problema

Verificar el estado de todo el cluster

 masterha_check_repl --conf=/etc/masterha/app1.cnf

[Si aparece 'NET OK', puede seguir los pasos anteriores para comprobar si los comandos se han escrito correctamente o si las letras se han escrito incorrectamente]

Verificar el estado del administrador

masterha_check_status --conf=/etc/masterha/app1.cnf

Si es normal, se mostrará "PING_OK".

NOT_RUNNING", que indica que la monitorización MHA no está habilitada.

Active el monitoreo y verifique si está activado.

Habilitar la supervisión del administrador

nohup masterha_manager --conf=/etc/masterha/app1.cnf --remove_dead_master_conf --ignore_last_failover< /dev/null >/var/log/masterha/app1/manager.log 2>&1 &

--remove_dead_master_conf     Cuando se produce un cambio maestro-esclavo, la dirección IP de la antigua biblioteca maestra se eliminará del archivo de configuración.

--manger_log        ubicación de almacenamiento de registros

--ignore_last_failover

De forma predeterminada, si MHA detecta un tiempo de inactividad continuo y el intervalo entre dos tiempos de inactividad es inferior a 8 horas, no se realizará la conmutación por error. El motivo de esta restricción es evitar el efecto ping-pong. Este parámetro significa ignorar los archivos generados por el último interruptor de activación de MHA. De forma predeterminada, después de que se produce el cambio de MHA, se generará el archivo app1.failover.complete en el directorio de registro, que es el /data que configuré anteriormente. Si se encuentra al cambiar nuevamente la próxima vez. La existencia de este archivo en este directorio no permitirá que se active el cambio a menos que el archivo se elimine después del primer cambio. Para mayor comodidad, esto se establece en --ignore_last_failover.

Desactivar el monitoreo

masterha_stop --conf=/etc/masterha/app1.cnf

fracaso de la prueba


Una vez que el host de monitoreo completa la configuración, puede verificar la tarjeta de red de la base de datos principal para obtener VIP

ip un | grep ens33

Simular falla de la base de datos principal

systemctl stop mariadb desactiva el servicio

Comprueba qué hace cada máquina y qué papel desempeña

 cola -f /etc/masterha/app1/manger

Después de completar el paso anterior, ingrese mysql desde la biblioteca

mostrar estado de esclavo\G 

Encontrará que la IP especificada en la biblioteca ha cambiado.

reparar


Simplemente reinicie

systemctl reiniciar mariadb

Pero la IP original no volverá

Utilice el comando para ver

ip un | grep ens33

Supongo que te gusta

Origin blog.csdn.net/2302_77750172/article/details/131456748
Recomendado
Clasificación