Pandora: Documentation es: MySQL Replica

From Pandora FMS Wiki
Jump to: navigation, search

Volver a Indice de Documentacion Pandora FMS

1 Modelo de replicacion binario MySQL para HA

1.1 Introducción

Se propone esta configuración para tener un entorno HA completo en Pandora FMS que esté basado en un modelo activo/pasivo. El MySQL estandar (No el cluster de MySQL), permite tener un único MASTER (que permita las operaciones INSERT/UPDATE) y varios SLAVES, a los que sólo les está permitido leer operaciones. La replicación se utiliza también para tener una "copia" de nuestra base de datos principal, con lo que si hay algún fallo, se pueda "Levantar" el SLAVE para que se convierta en el MASTER de la base de datos, produciéndose así un switch-over.

Después de detectar un fallo, necesitará reiniciar (manualmente, ya que se trata de un proceso muy delicado), el sistema Maestro y transferir todos los datos desde el Slave al Master de nuevo.


1.2 Entorno Inicial

192.168.10.202 (master) -> Servidor maestro. 192.168.10.203 (slave) -> Servidor esclavo

192.168.10.206 (pandora) -> Pandora Server


1.3 Configurando el Servidor de Mysql Server

1.3.1 Instalación y configuración del clúster

Para el correcto funcionamiento del clúster hay que instalar los siguientes paquetes en ambos nodos del clúster de mysql. En este caso se ha optado por un clúster Percona en su versión 5.7. (Realizada instalación sobre Centos 7, realizar instalación en ambos nodos Master y Slave)


a) Instalar el repositorio de Percona

Para instalar el siguiente repositorio de Percona se necesita instalar el siguiente paquete siempre y cuando tengamos acceso a internet desde la máquina, con el usuario root.

Master & Slave# yum install http://www.percona.com/downloads/percona-release/redhat/0.1-4/percona-release-0.1-4.noarch.rpm
Retrieving http://www.percona.com/downloads/percona-release/redhat/0.1-4/percona-release-0.1-4.noarch.rpm
  Preparing...                ########################################### [100%]
  1:percona-release        ########################################### [100%]

b) Instalar servidor Percona v5.7 y todos los componentes necesarios para su correcto funcionamiento. Aparte del servidor, cliente y librerías, instalaremos también percona xtrabackup que utilizaremos para realizar la replicación entre ambos nodos:

Master & Slave# yum install Percona-Server-shared-compat-57 Percona-Server-client-57 Percona-Server-server-57 Percona-Server-shared-57 percona-xtrabackup

1.3.2 Configuración e inicio del servidor master

Una vez instalado el servidor en ambos nodos procedemos a realizar la configuración del fichero /etc/my.cnf en el nodo master:

[mysqld]
#Parámetros de configuración básicos
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
symbolic-links=0

#Parámetros de Optimización (para un servidor con 4Gb RAM)
max_allowed_packet = 64M
innodb_buffer_pool_size = 256M
innodb_lock_wait_timeout = 90
innodb_file_per_table
innodb_flush_method = O_DIRECT
innodb_log_file_size = 64M
innodb_log_buffer_size = 16M
innodb_io_capacity = 100
thread_cache_size = 8
max_connections = 100
key_buffer_size=4M
read_buffer_size=128K
read_rnd_buffer_size=128K
sort_buffer_size=128K
join_buffer_size=4M
query_cache_type = 1
query_cache_size = 4M
query_cache_limit = 8M
sql_mode=""
innodb_flush_log_at_trx_commit=1

#Parámetros para el correcto funcionamiento de la replicación binaria.
# Borrado de logs binarios
expire_logs_days = 3
# Activación de Logs binarios para su replicación
log-bin=mysql-bin
sync_binlog=1
# Tamaño máximo tamaño de los logs binarios. Cuanto más pequeños sean mejor se realizará el proceso de sincronización y menor 
lag habrá. 
max_binlog_size = 100M 
# ID del servidor maestro
server_id=1

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

[client]
# Se puede definir aqui la password por defecto del cliente para simplificar los siguientes pasos
user=root
password=pandora

Una vez esté configurado el servidor master con esta configuración podemos iniciar el servidor mysql en el servidor master

Master#service mysql start

En la versión 5.7 de Percona al iniciar el servicio de mysql por primera vez se crea una contraseña de root temporal que podemos encontrarla en el log de mysql /var/log/mysqld.log. Una vez accedamos al servidor mysql con esta contraseña podemos modificarla por otra que nos resulte más cómoda.

Para poder permitir la replicación en el nodo esclavo hay que añadir los grants apropiados al servidor.

Master|mysql> GRANT REPLICATION SLAVE ON *.*  TO 'repl'@'slave' IDENTIFIED BY ‘password’;

1.3.3 Replicación de la base de datos del maestro al esclavo mediante xtrabackup

Primero de todo tenemos que realizar el backup en el maestro. Al no tener apenas información el tamaño con el que trabajaremos para este punto de la replicación será bastante pequeño.

Para la realización del backup usaremos la herramienta xtrabackup en el que le tendremos que indicar el parámetro backup para la realización del mismo, el usuario y password de la base de datos ( si están correctamente añadidos a la base de datos podemos omitir esta información) y el directorio donde vamos a almacenar el backup mediante el parámetro –target-dir ( en el ejemplo /home/backup)

Master# xtrabackup --backup --user=root --password=password --target-dir=/home/backup/   
xtrabackup: completed OK!

Al completarse se creará un directorio dentro del indicado con el dato de la fecha de creación, en el ejemplo /home/backup/2017-11-29_13-11-41

Para que el backup sea consistente hay que lanzar la siguiente ejecución:

Master#xtrabackup --user=root --password=password --prepare --target-dir=/home/backup/2017-11-29_13-11-41 

Cuando esté preparado el backup el siguiente paso es copiar toda la información al servidor Slave (el backup y /etc/my.cnf ) Para copiar el backup al servidor esclavo realizaremos la siguiente ejecución, sabiendo que el directorio datadir (en el ejemplo /var/lib/mysql ) del servidor slave tiene que estar vacio

Master# rsync -avpP -e ssh /home/backup/2017-11-29_13-11-41 Slave:/home/backup/

Slave#mv /home/backup/2017-11-29_13-11-41/* /var/lib/mysql/

Nos aseguramos de que los permisos del directorio mysql son los correctos:

Slave#chown –R mysql:mysql /var/lib/mysql/

1.3.4 Configuración del servidor esclavo

Lo primero de todo es configurar el fichero de configuración del mysql /etc/my.cnf. Éste va a ser una copia directa del fichero de configuración del servidor maestro con la diferencia que en este caso el parámetro server_id=2.

[mysqld]
#Parámetros de configuración básicos
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
symbolic-links=0

#Parámetros de Optimización (para un servidor con 4Gb RAM)
max_allowed_packet = 64M
innodb_buffer_pool_size = 256M
innodb_lock_wait_timeout = 90
innodb_file_per_table
innodb_flush_method = O_DIRECT
innodb_log_file_size = 64M
innodb_log_buffer_size = 16M
innodb_io_capacity = 100
thread_cache_size = 8
max_connections = 100
key_buffer_size=4M
read_buffer_size=128K
read_rnd_buffer_size=128K
sort_buffer_size=128K
join_buffer_size=4M
query_cache_type = 1
query_cache_size = 4M
query_cache_limit = 8M
sql_mode=""
innodb_flush_log_at_trx_commit=1

#Parámetros para el correcto funcionamiento de la replicación binaria.
# Borrado de logs binarios
expire_logs_days = 3
# Activación de Logs binarios para su replicación
log-bin=mysql-bin
sync_binlog=1
# Tamaño máximo tamaño de los logs binarios. Cuanto más pequeños sean mejor se realizará el proceso de sincronización y menor 
lag habrá. 
max_binlog_size = 100M 
# ID del servidor maestro
server_id=2

[mysqld_safe]
log-error=/var/log/mysqld.log 
pid-file=/var/run/mysqld/mysqld.pid

[client]
# Se puede definir aqui la password por defecto del cliente para simplificar los siguientes pasos
user=root
password=pandora
Arrancamos el servidor de mysql en el nodo slave: 
Slave#service mysql start


Para iniciar la replicación del clúster lo primero de todo es ver el contenido del fichero xtrabackup_binlog_info que lo podremos encontrar en el directorio datadir del servidor slave.


Slave#cat /var/lib/mysql/xtrabackup_binlog_info
Master-bin.000001	380


Nos conectamos al mysql del servidor slave e introducimos las siguientes queries que nos permitirá indicar quien es el servidor master e iniciamos el slave. Deberá aplicarse el parámetro read_only a 1 en el slave para que no se añada información adicional por error en el nodo slave.

Slave|mysql> 'CHANGE MASTER TO MASTER_HOST='master', 
MASTER_USER='repl',MASTER_PASSWORD='password',MASTER_LOG_FILE='TheMaster-bin.000001',MASTER_LOG_POS=380;
Slave|mysql> START SLAVE;
Slave|mysql>SET GLOBAL read_only = 1;


Si se ha iniciado la replicación correctamente aparecerá esta información en el servidor slave:


Slave|mysql> SHOW SLAVE STATUS \G
         ...
         Slave_IO_Running: Yes
         Slave_SQL_Running: Yes
         ...
         Seconds_Behind_Master: 8
         ...


Slave_IO_Running y Slave_SQL_Running nos muestran el estado del clúster, mientras que el valor Seconds_Behind_Master los segundos de lag que hay entre la información ubicada en el master y en el slave.


1.4 Instalación de BD de pandora

Cree una nueva desde los ficheros de instalación .sql o lanze la actual sobre el master node (Castor).

Lógese en el master server:

mysql> create database pandora;
mysql> use pandora;
mysql> source /tmp/pandoradb.sql;
mysql> source /tmp/pandoradb_data.sql;

1.4.1 Configurando el servidor SQL para su uso en el servidor de Pandora

En ambos servidores:

mysql> grant all privileges on pandora.* to pandora@192.168.10.1 identified by 'pandora';
mysql> flush privileges;

Una vez aplicado estos permisos deberíamos poder ver la consola de Pandora FMS e iniciar el servidor de Pandora FMS cuando se haya aplicado la licencia correctamente.

En los servidores slave y master compruebe los procesos que se están ejecutando con el siguiente comando SQL:


mysql> show processlist;


Debería mostrar algo como:

+----+-------------+-----------+------+---------+------+----------------------------------------------------------
| Id | User        | Host      | db   | Command | Time | State                                                                 | Info             |
+----+-------------+-----------+------+---------+------+----------------------------------------------------------
| 32 | root        | localhost | NULL | Sleep   |   72 |                                                                       | NULL             | 
| 36 | system user |           | NULL | Connect |  906 | Waiting for master to send event                                      | NULL             | 
| 37 | system user |           | NULL | Connect |    4 | Has read all relay log; waiting for the slave I/O thread to update it | NULL             | 
| 39 | root        | localhost | NULL | Query   |    0 | NULL                                                                  | show processlist | 
+----+-------------+-----------+------+---------+------+----------------------------------------------------------

1.5 Switchover

1.5.1 Paso de Slave a Master

En este caso el servidor MASTER está caído y el SLAVE sigue activo pero en modo slave y con la protección contra escrituras activada. Para realizar el paso de Slave a Master hay que lanzar los siguientes comandos SQL en el servidor Slave.

Slave|mysql>  STOP SLAVE; 
Slave|mysql> RESET MASTER;


Su servidor SLAVE está ahora trabajando como MASTER. El SLAVE no utiliza el log de replicación del MASTER y el MASTER esta ahora "out of sync", que significa que si su PANDORA FMS señala al antiguo servidor master, usted obtendrá información obsoleta. Este es uno de los aspectos más problemáticos y la mayoría de los problemas proceden de ahí.

El primer "Switchover", que significa, que cuando el MASTER oficial se cae, y el SLAVE oficial se convierte en el NUEVO master, no constituye un problema, es algo completamente automático puesto que los sistemas hacen las consultas contra el SLAVE/ servidor del nuevo master.

1.5.2 Switchover de antiguo Master a Slave

El problema es el "segundo" switchover, cuando usted quiere que el antiguo master se convierta de nuevo en el master oficial.

En este paso, necesitará volver a realizar el proceso completo para sincronizar todo el modelo HA, esto significa:

1. Detener servicio Pandora Server.

2. Parar el servicio mysql del nodo master y eliminar todo el directorio datadir.

3. Replicar la base de datos del nodo slave al nodo master. (Punto 1.3.1.3.)

4. Detener servicio mysql en nodo slave

5. Iniciar mysql nodo master

6. Iniciar replicación slave en nodo slave. (Punto 1.3.1.4)

7. Comprobar que replica correctamente



Volver a Indice de Documentacion Pandora FMS