Difference between revisions of "Pandora: Documentation es: MySQL Replica"

From Pandora FMS Wiki
Jump to: navigation, search
(Switchover)
 
(Modelo de replicacion binario MySQL para HA)
Line 7: Line 7:
 
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. Esto se utiliza en diversos entornos para tener un modelo de bases de datos distribuido. En Pandora todas las operaciones de Lectura/escritura se hacen contra el mismo servidor de la BD, así que este modelo no se puede utilizar. De cualquier modo,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 sea el master de la base de datos y la use.
 
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. Esto se utiliza en diversos entornos para tener un modelo de bases de datos distribuido. En Pandora todas las operaciones de Lectura/escritura se hacen contra el mismo servidor de la BD, así que este modelo no se puede utilizar. De cualquier modo,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 sea el master de la base de datos y la use.
  
Empleamos la aplicación UCARP para proporcionar el mecanismo de IP (VIP) virtual para tener un tiempo real H/A. El el modelo más sencillo, con dos demonios UCARP corriendo, si el master falla, el secundario cogerá el VIP y procederá con la operación de manera normal. Un slave reanudará las operaciones MySQL en el Servidor/Consola de Pandora FMS, y el usuario no notará nada.
 
  
 
Despues del failover, 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.
 
Despues del failover, 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.
  
== Comparación con otros modelos de MySQL HA  ==
 
  
Existen muchas maneras de implementar MySQL HA, aquí hemos explorado tres de ellas:
+
== Entorno Inicial==
  
* MySQL Cluster: muy compleja y con una penalización de rendimiento. Es el único modo de tener un entorno de cluster real activo/ inactivo. Está descrito en profundidad en nuestra documentación.
+
192.168.10.202 (master) -> Servidor maestro.
 
* MySQL Binary Replica / ucarp: Sencillo, rápido y estandar, pero con multitud de scripts y complejo para recuperar el master en el sistema.Ver documentación.
 
  
* DRBD / heartbeat: Sencillo, rápido y basado en dispositivos de sistema de bloques. También aparece descrito en nuestra documentación. Es la manera oficial de implementar HA en Pandora FMS.
+
192.168.10.203 (slave) -> Servidor esclavo
  
 +
192.168.10.206 (pandora) -> Pandora Server
  
En nuestra opinión, la mejor manera de implementar el HA es tener la configuración más sencilla posible, porque cuando algo falla, cualquier complejidad extra llevará a la confusión y a la pérdida de datos si los procedimientos no están extremadamente testados y escritos. La mayoría de las veces, los operadores sólo siguen los procedimientos y no pueden reaccionar ante las cosas que ocurren fuera de los procedimientos, y en el HA puede ser muy dificil tener los procedimientos exactos en la mayoria de los casos.
 
 
== Entorno Inicial==
 
 
Este es un vistazo a nuestro escenario de pruebas
 
  
 +
=== Configurando el Servidor de Mysql Server ===
  
192.168.10.101 (castor) -> Master
+
==== Instalación y configuración del clúster ====
  
192.168.10.102 (pollux) -> Slave
+
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)
  
192.168.10.100 virtual-ip
 
  
192.168.10.1  pandora -> mysql app
+
'''a)  Instalar el repositorio de Percona'''
  
=== Configurando el Servidor de Mysql Server ===
+
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 node (Castor) ====
+
'''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%]
  
Edite my.cnf file (sistemas debian):
+
'''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:
  
  [mysqld]
+
  '''Master & Slave#''' yum install Percona-Server-shared-compat-57 Percona-Server-client-57 Percona-Server-server-57 Percona-Server-shared-57 percona-xtrabackup
bind-address=0.0.0.0
 
log_bin=/var/log/mysql/mysql-bin.log
 
server-id=1
 
innodb_flush_log_at_trx_commit=1
 
sync_binlog=1
 
binlog_do_db=pandora
 
binlog_ignore_db=mysql
 
  
==== Slave node (Pollux) ====
+
==== Configuración e inicio del servidor master ====  
  
Edite el fichero my.cnf:
+
Una vez instalado el servidor en ambos nodos procedemos a realizar la configuración del fichero /etc/my.cnf en el nodo master:
  
 
  [mysqld]
 
  [mysqld]
  bind-address=0.0.0.0
+
  #Parámetros de configuración básicos
  server-id=2
+
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
 
  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
 
  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
  
==== Crear un Usuario para Replicación ====
+
Una vez esté configurado el servidor master con esta configuración podemos iniciar el servidor mysql en el servidor master
 
 
Cada esclavo debe conectarse con el master utilizando un nombre y contraseña MySQL, así pues, debe existir una cuenta de usuario en el master que el slave pueda utilizar para conectarse. Se puede utilizar cualquier cuenta para realizar esta operación, en tanto el privilegio de REPLICATION SLAVE sea garantizado.
 
 
 
mysql> CREATE USER 'replica'@'192.168.10.102' IDENTIFIED BY 'slayer72';
 
mysql> GRANT REPLICATION SLAVE ON *.* TO 'replica'@'192.168.10.102';
 
mysql> FLUSH PRIVILEGES;
 
 
 
==== Instalación de su 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;
+
  '''Master#'''service mysql start
mysql> use pandora;
 
mysql> source /tmp/pandoradb.sql;
 
mysql> source /tmp/pandoradb_data.sql;
 
  
==== Configuración de la Replicación con los datos existentes. ====
+
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.
  
Ahora queremos replicar el estado inicial de la base de datos cargada en el MASTER node (castor). Este es el punto de "arranque" para replicar toda la información al esclavo,y se asume que tiene su base de datos "FROZEN" en el momento en que hace la "foto", despues de hacer la foto se dan las "coordenadas" y se escriben en el dump de SQL, si la base de datos master continua escribiendo datos, no se preocupe, la replicación continuará replicando todos los datos desde las coordenadas iniciales. Piense en ello como una ruta lineal, y "freeze" un punto inicial para el esclavo para que empieze a replicar la información. Siga estos pasos:
+
Para poder permitir la replicación en el nodo esclavo hay que añadir los grants apropiados al servidor.
  
1. Inicie una sesion en el master conectadose a él con el cliente de la linea de comandos y haga salir todas las tablas y bloquee los write statements ejecutando los FLUSH TABLES WITH READ LOCK statement:
+
'''Master|mysql>''' GRANT REPLICATION SLAVE ON *.*  TO 'repl'@'slave' IDENTIFIED BY ‘password’;
  
mysql> FLUSH TABLES WITH READ LOCK;
+
==== Replicación de la base de datos del maestro al esclavo mediante xtrabackup ====
  
2. Las bases de datos escritas están ahora bloqueadas. Utilize el SHOW MASTER STATUS para determinar el nombre y la posición del fichero binario log actual.
+
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.
  
mysql > SHOW MASTER STATUS;
+
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)
+------------------+----------+--------------+------------------+
 
| File            | Position | Binlog_Do_DB | Binlog_Ignore_DB |
 
+------------------+----------+--------------+------------------+
 
| mysql-bin.000003 | 98      | pandora      | mysql            |
 
+------------------+----------+--------------+------------------+
 
  
La columna File muestra el nombre del fichero log y la de Position muestra la posición con el fichero. En este ejemplo el fichero del log binario es mysql-bin.000003 y la posición es 98. Los necesitarás después cuando estés configurando el slave. Representan las coordenadas de replicación en las que el esclavo debería empezar a procesar las nuevas actualizaciones del master.
+
'''Master#''' xtrabackup --backup --user=root --password=password --target-dir=/home/backup/ 
 +
xtrabackup: completed OK!
  
3. Abra un shell haga un comando mysqldump :
+
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
  
$ mysqldump -u root -pnone pandora -B --master-data > /tmp/dbdump.sql
+
Para que el backup sea consistente hay que lanzar la siguiente ejecución:
  
Este dump es "especial" y contiene las cordenadas para el servidor esclavo(--master-data),y también crea la base de datos y la utiliza sobre el dump del .SQL creado.
+
'''Master#'''xtrabackup --user=root --password=password --prepare --target-dir=/home/backup/2017-11-29_13-11-41
  
4. Abra si servodor primario de Mysql
+
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
  
  mysql> unlock tables;
+
  '''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/
  
5. Copie el fichero SQL al servidor SLAVE (ftp. ssh...)
+
Nos aseguramos de que los permisos del directorio mysql son los correctos:
  
6. Conectese a la consola mysql,y detenga su servidor SLAVE.
+
'''Slave#'''chown –R mysql:mysql /var/lib/mysql/
  
mysql> SLAVE STOP;
+
===Configuración del servidor esclavo===
  
7. Vuelque su base de datos actual de pandora en el servidor SLAVE (si existe).
 
  
mysql> drop database pandora;
+
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.
  
8. Introduzca la siguiente sentencia SQL para preparar las credenciales y establecer comunicación con el 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=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
  
mysql> CHANGE MASTER TO MASTER_HOST='192.168.10.101', MASTER_USER='replica', MASTER_PASSWORD='slayer72';
 
  
Tenga en cuenta que se esta dirigiendo al servidor actual del MASTER (192.168.10.101).
+
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.  
  
9. Importe el sql vertido sacado del servidor Master actual:
 
  
  mysql> SOURCE /tmp/dbdump.sql;
+
  '''Slave#'''cat /var/lib/mysql/xtrabackup_binlog_info
 +
Master-bin.000001 380
  
10. Inicie SLAVE
 
  
mysql> SLAVE START;
+
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.
  
11. Vigile el status de la sincronización.
+
''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;
  
mysql> SHOW SLAVE STATUS;
 
  
12. Debería ver: "Waiting for master to send events" para confirmar que todo está correcto.
+
Si se ha iniciado la replicación correctamente aparecerá esta información en el servidor slave:  
  
== Configurando el servidor SQL para su uso en el servidor de Pandora ==
 
  
En ambos servidores:
+
'''Slave|mysql>''' SHOW SLAVE STATUS \G
 +
          ...
 +
          Slave_IO_Running: Yes
 +
          Slave_SQL_Running: Yes
 +
          ...
 +
          Seconds_Behind_Master: 8
 +
          ...
  
mysql> grant all privileges on pandora.* to [email protected] identified by 'pandora';
 
mysql> flush privileges;
 
  
=== Iniciar el Servidor de Pandora ===
+
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.
  
Todo debería ir correctamente.
 
Compruebe si todo va bien:
 
  
En los servidores slave y master compruebe los procesos que se están ejecutando con el siguiente comando SQL:
+
=== Instalación de su BD de pandora  ===
  
mysql> show processlist;
+
Cree una nueva desde los ficheros de instalación .sql o lanze la actual sobre el master node (Castor).
  
Debería mostrar algo como:
+
Lógese en el master server:
  
<pre>
+
  mysql> create database pandora;
 
+
  mysql> use pandora;
+----+-------------+-----------+------+---------+------+----------------------------------------------------------
+
  mysql> source /tmp/pandoradb.sql;
| Id | User        | Host      | db  | Command | Time | State                                                                | Info            |
+
  mysql> source /tmp/pandoradb_data.sql;
+----+-------------+-----------+------+---------+------+----------------------------------------------------------
 
| 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 |
 
+----+-------------+-----------+------+---------+------+----------------------------------------------------------
 
 
 
</pre>
 
 
 
== Switchover ==
 
 
 
Esto implica: haga que el slave se convierta en master. En el evento el servidor MASTER está caído, o por alguna razón los puntos VIP al servidor SLAVE, debe asegurarse de que el servidor SLAVE ejecute los siguientes comandos SQL:
 
 
 
  mysql> STOP 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 vieja. 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. 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 todos los pandoras.
 
 
 
2. Volcar la base de datos desde el viejo slave (Pollux) a un SQL limpio:
 
 
 
$ mysqldump -B -u root -pnone pandora > /tmp/pandoradump.sql
 
 
 
3. Copiar el sql vertido al master oficial(Castor)
 
 
 
4. Restaurar el SQL y volcar toda la información antigua.
 
 
 
mysql> drop database pandora;
 
  mysql> source /tmp/pandoradump.sql;
 
 
 
5. En este punto, ambas bases de datos son iguales. Sólo tendrá que obtener las coordenadas para hacer que el esclavo vuelva a "replicar" y se degrade hasta SLAVE. Obtenga las coordenadas desde el MASTER oficial:
 
 
 
  mysql> SHOW MASTER STATUS;
 
+------------------+----------+--------------+------------------+
 
| File            | Position | Binlog_Do_DB | Binlog_Ignore_DB |
 
+------------------+----------+--------------+------------------+
 
| mysql-bin.000003 | 234234  | pandora      | mysql            |
 
+------------------+----------+--------------+------------------+
 
 
 
(Las coordenadas son File y Position)
 
 
 
6. Utilize este SQL en el SLAVE:
 
 
 
mysql> SLAVE STOP;
 
myqsl> CHANGE MASTER TO MASTER_HOST='192.168.10.101', MASTER_USER='replica', MASTER_PASSWORD='slayer72', MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=234234;
 
mysql> SLAVE START;
 
 
 
7. Todo debería ir bien. Ahora puede reiniciar su proceso VIP para asignar el VIP al master oficial (Castor) y dejar a Pollux otra vez con el rol de slave.
 
 
 
 
 
{{tip|Existe otra manera de implementar failover, lo que supone que el rol de MASTER/SLAVE no está fijado, pero significa que este rol "relativo" debería ser implementado en el modelo VIP, utilizando UCARP, lo que significa cambiar la prioridad en vhid. Otro modo de resolver este problema es utilizar el dispositivo Heartbeat VIP (lea nuestra documentación acerca de DRBD)}}
 
 
 
== Instalar el dispositivo balanceador de carga ==
 
 
 
Estamos utilizando UCARP, que usa el protocolo CARP (http://en.wikipedia.org/wiki/Common_Address_Redundancy_Protoco). Ver más información en: http://ucarp.org/
 
 
 
Obtenga el paquete e instálelo. Configurarlo es muy sencillo. Necesita tener un proceso ucarp corriendo en cada servidor mysql.
 
 
 
=== Castor / Master ===
 
 
 
ucarp --interface=eth1 --srcip=192.168.10.101 --vhid=1 --pass=pandora  --addr=192.168.10.100 --upscript=/etc/vip-up.sh --downscript=/etc/vip-down.sh &
 
 
 
=== Pollux / Slave ===
 
 
 
ucarp --interface=eth1 --srcip=192.168.10.102 --vhid=2 --pass=pandora  --addr=192.168.10.100 --upscript=/etc/vip-up.sh --downscript=/etc/vip-down.sh &
 
 
 
==== Contenido de los scripts====
 
 
 
[/etc/vip-up.sh]
 
 
 
#!/bin/bash
 
/sbin/ifconfig "$1":254 "$2" netmask 255.255.255.0
 
 
 
[/etc/vip-down.sh]
 
 
 
#!/bin/bash
 
/sbin/ifconfig "$1":254 down
 
 
 
==== Algunos scripts que proponemos====
 
 
 
[/etc/mysql-create-full-replica.sh]
 
 
 
#!/bin/bash
 
echo "FLUSH TABLES WITH READ LOCK;" | mysql -u root -pnone -D pandora
 
mysqldump -u root -pnone pandora -B --master-data > /tmp/dbdump.sql
 
echo "UNLOCK TABLES;" | mysql -u root -pnone -D pandora
 
 
 
[/etc/mysql-restore-replica.sh]
 
 
 
scp [email protected]:/tmp/dbdump.sql .
 
echo "SLAVE STOP; drop database pandora; SOURCE /tmp/dbdump.sql;" | mysql -u root -pnone -D pandora
 
 
 
[/etc/mysql-become-slave.sh]
 
 
 
echo "CHANGE MASTER TO MASTER_HOST='192.168.10.101', MASTER_USER='replica', MASTER_PASSWORD='slayer72'; SLAVE  START;" | mysql -u root -pnone
 
  
[/etc/mysql-become-master.sh]
 
  
echo "STOP SLAVE; RESET MASTER;" | mysql -u root -pnone
 
  
 
[[Pandora:Documentation|Volver a Indice de Documentacion Pandora FMS]]
 
[[Pandora:Documentation|Volver a Indice de Documentacion Pandora FMS]]
  
 
[[Category:Pandora FMS]]
 
[[Category:Pandora FMS]]

Revision as of 15:42, 26 December 2017

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. Esto se utiliza en diversos entornos para tener un modelo de bases de datos distribuido. En Pandora todas las operaciones de Lectura/escritura se hacen contra el mismo servidor de la BD, así que este modelo no se puede utilizar. De cualquier modo,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 sea el master de la base de datos y la use.


Despues del failover, 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.2.1 Configurando el Servidor de Mysql Server

1.2.1.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.2.1.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.2.1.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.2.2 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.2.3 Instalación de su 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;


Volver a Indice de Documentacion Pandora FMS