lunes, 15 de abril de 2019

Configuración sencilla de KeepaliveD

Así que keepalived ha existido por bastante tiempo ahora ... sin embargo, todavía es un misterio para muchos.
Este es un ejemplo muy simple de cómo keepalived puede trabajar con MySQL. Con suerte, esto puede ayudar a aquellos con preguntas.

Tendremos un maestro simple para configurar esclavos. Es decir, escribimos en uno a menos que tengamos conmutación por error al segundo para algún evento.

1º - instalar keepalived


# yum search keepalived
keepalived .x86_64: equilibrador de carga y servicio de alta disponibilidad

  Solo coincidencias de nombre y resumen, use "buscar todo" para todo.
# yum -y install keepalived

Ahora debería tener un archivo de configuración

# ls -ltr /etc/keepalived/keepalived.conf  

Guarde el original como siempre hace una copia de seguridad ... correcto ....
# cp /etc/keepalived/keepalived.conf /etc/keepalived/keepalived.conf.orig

Por lo tanto, debe averiguar una dirección IP que pueda usar para su IP virtual. Escogí 192.168.0.123 para este ejemplo.

A continuación, configuraremos un script para usarlo en nuestro nuevo archivo de configuración.

Algunas cosas que hice aqui ..
Dejé un archivo .cnf para keepalived y un registro en el / etc / keepalived.
Esto facilita el ejemplo para que pueda hacer esto o usar sus propios archivos cnf.

Un guión:

cat /etc/keepalived/keepalived_check.sh  
#! / bin / bash

# monitorear el estado de mysql

# si este nodo mysql está muerto

# y su esclavo está vivo, entonces deja de mantenerlo vivo. El otro nodo enlazará la IP.



exportar MYSQL_HOME = / etc / keepalived /

export PATH = $ MYSQL_HOME / bin: $ PATH



mysql = "/ usr / bin / mysql"

mysqladmin = "/ usr / bin / mysqladmin"

delay_file = "$ MYSQL_HOME / slave_delay_second.log"

slave_host = $ 1





ALIVE = $ ($ mysqladmin --defaults-file = $ MYSQL_HOME / .my.localhost.cnf   ping grep vivo | wc -l);

REMOTEALIVE = $ ($ mysqladmin --defaults-file = $ MYSQL_HOME / .my.remotehost.cnf   ping grep vivo | wc -l);



si [[$ ALIVE -ne 1]]

entonces

#echo "MySQL está caído"

        si [[$ REMOTEALIVE -eq 1]]

        entonces

#         echo "Shutdown mantener vivo"

            systemctl dejar de mantener vivo  

#       echo "keepalived stop"

        fi

#más

#echo "MySQL está arriba"

#fecha

fi



salida 0 # todo hecho

Nuevo archivo de configuración

cat /etc/keepalived/keepalived.conf
global_defs {



      notification_email {

        anothermysqldba@gmail.com  

      }



      notification_email_from anothermysqldba@gmail.com  

      smtp_server localhost

      smtp_connect_timeout 30



      }







vrrp_script check_mysql {

   script "/etc/keepalived/keepalived_check.sh"

   intervalo 2

   peso 2

}







vrrp_instance VI_1 {



      estado maestro

      interfaz enp0s8   # <--- QUE NOMBRE DE LA INTERFAZ CUMPLE TU REAL IP / sbin / ifconfig

        # encontrado con ip link show

      virtual_router_id 51

      prioridad 101

      advert_int 1

      imperdonable   # solo es necesario en el nodo de mayor prioridad

      autenticación {

        auth_type PASS

        auth_pass 1111

      }





      track_script {

        check_mysql

      }



      virtual_ipaddress {

        192.168.0.123  

      }




}



Todo esto es genial, pero funciona ...

Así que tenemos 2 hosts

[root @ centosa keepalived] # nombre de host

centosa

[root @ centosb keepalived] # nombre de host
centosb

Empezar a mantener vivo

[root @ centosa keepalived] # systemctl status keepalived
● keepalived.service - LVS y VRRP High Availability Monitor
   Cargado: cargado (/usr/lib/systemd/system/keepalived.service; desactivado; valor predeterminado del proveedor: desactivado)
   Activo: inactivo (muerto)
[root @ centosa keepalived] # systemctl restart keepalived
[root @ centosa keepalived] # systemctl status keepalived
keepalived.service - LVS y VRRP High Availability Monitor
   Cargado: cargado (/usr/lib/systemd/system/keepalived.service; desactivado; valor predeterminado del proveedor: desactivado)
    Activo: activo (en ejecución)

[root @ centosa keepalived] # ssh 192.168.0.123 'nombre de host'
Contraseña de root@192.168.0.123:  

centosa

Demuestra que las conexiones ya funcionan

[root @ centosa keepalived] # mysql --defaults-file = .my.remotehost.cnf --host = 192.168.0.101   -e "seleccione @@ hostname"
+ ------------ +
| @@ hostname |
+ ------------ +
| centosb     |
+ ------------ +
[root @ centosa keepalived] # mysql --defaults-file = .my.remotehost.cnf --host = 192.168.0.102   -e "seleccione @@ hostname"
+ ------------ +
| @@ hostname |
+ ------------ +
| centosa     |
+ ------------ +

Compruebe que se está ejecutando ...

[root @ centosa keepalived] # systemctl status keepalived | grep activo
    Activo: activo  

[root @ centosb keepalived] # systemctl status keepalived | grep activo
    Activo: activo  

Probar el VIP actual. Detener mysql y ver los mismos hosts de cambio VIP ...

[root @ centosa keepalived] # mysql --defaults-file = .my.remotehost.cnf --host = 192.168.0.123   -e "seleccione @@ hostname"
+ ------------ +
| @@ hostname |
+ ------------ +
| centosa     |
+ ------------ +
[root @ centosa keepalived] # systemctl stop mysqld  
[root @ centosa keepalived] # mysql --defaults-file = .my.remotehost.cnf --host = 192.168.0.123   -e "seleccione @@ hostname"
+ ------------ +
| @@ hostname |
+ ------------ +
| centosb     |
+ ------------ +

martes, 9 de abril de 2019

A veces la base de datos lenta ... no es la base de datos ...

Hace poco me pidieron que viera por qué el MySQL 5 actualizado, .6 era más lento que el 5.5 anterior.

Así que empecé a hojear las variables y los cachés estándar, etc.

El caso de prueba era una rutina simple que tardó aproximadamente el doble de tiempo en ejecutarse en 5.6 que en 5.5.

Para agregar a la mezcla ... la versión 5.6 tenía el doble de Innodb_buffer_pool_size y, por supuesto, más RAM en general.

Así que empecé algunas pruebas con MySQLslap ...

Las pruebas Mysqlslap lo muestran más lento en 5.6

5.6:
mysqlslap --defaults-file =. /. my.cnf --concurrency = 150 --iterations = 130 -query = / test.sql --create-schema = applicationdata --verbose
Punto de referencia
Número promedio de segundos para ejecutar todas las consultas: 0.028 segundos
Número mínimo de segundos para ejecutar todas las consultas: 0.019 segundos
Número máximo de segundos para ejecutar todas las consultas: 0.071 segundos
Número de clientes ejecutando consultas: 150
Número medio de consultas por cliente: 1

5.5:
mysqlslap --defaults-file =. /. my.cnf --concurrency = 150 --iterations = 130 --query = / test.sql --create-schema = applicationdata --verbose
Punto de referencia
Número promedio de segundos para ejecutar todas las consultas: 0.015 segundos
Número mínimo de segundos para ejecutar todas las consultas: 0.011 segundos
Número máximo de segundos para ejecutar todas las consultas: 0.024 segundos
Número de clientes ejecutando consultas: 150
Número medio de consultas por cliente: 1


Todo esto va en contra de los puntos de referencia públicos.
http://dimitrik.free.fr/blog/archives/2013/02/mysql-performance-mysql-56-ga-vs-mysql-55-32cores.html

Así que revisé el nivel del disco -

5.6:
# dd if = / dev / zero of = test bs = 1048576 count = 2048
2048 + 0 registros en
2048 + 0 registros
2147483648 bytes (2.1 GB) copiados, 25.7401 s, 83.4 MB / s

# dd if = prueba de = / dev / null bs = 1048576
2048 + 0 registros en
2048 + 0 registros
2147483648 bytes (2.1 GB) copiados, 29.1527 s, 73.7 MB / s

5.5:
# dd if = / dev / zero of = test bs = 1048576 count = 2048
2048 + 0 registros en
2048 + 0 registros
2147483648 bytes (2.1 GB) copiados, 19.9214 segundos, 108 MB / s

# dd if = prueba de = / dev / null bs = 1048576
2048 + 0 registros en
2048 + 0 registros
2147483648 bytes (2.1 GB) copiados, 20.0243 segundos, 107 MB / s



Aquí los discos con 5.5 son más lentos, independientemente de MySQL. Entonces, en este caso ... Mire para arreglar la velocidad del disco ... MySQL estaba funcionando bien y funcionará.