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. 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.

1.2 Comparación con otros modelos de MySQL HA

Existen muchas maneras de implementar MySQL HA, aquí hemos explorado tres de ellas:

  • 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.
  • 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.


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.

1.3 Entorno Inicial

Este es un vistazo a nuestro escenario de pruebas


192.168.10.101 (castor) -> Master

192.168.10.102 (pollux) -> Slave

192.168.10.100 virtual-ip

192.168.10.1 pandora -> mysql app

1.3.1 Configurando el Servidor de Mysql Server

1.3.1.1 Master node (Castor)

Edite my.cnf file (sistemas debian):

[mysqld]
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

1.3.1.2 Slave node (Pollux)

Edite el fichero my.cnf:

[mysqld]
bind-address=0.0.0.0
server-id=2
innodb_flush_log_at_trx_commit=1
sync_binlog=1

1.3.1.3 Crear un Usuario para Replicación

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;

1.3.1.4 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;

1.3.1.5 Configuración de la Replicación con los datos existentes.

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:

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:

mysql> FLUSH TABLES WITH READ LOCK;

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.

mysql > SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| 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.

3. Abra un shell haga un comando mysqldump :

$ mysqldump -u root -pnone pandora -B --master-data > /tmp/dbdump.sql

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.

4. Abra si servodor primario de Mysql

mysql> unlock tables;

5. Copie el fichero SQL al servidor SLAVE (ftp. ssh...)

6. Conectese a la consola mysql,y detenga su servidor SLAVE.

mysql> SLAVE STOP;

7. Vuelque su base de datos actual de pandora en el servidor SLAVE (si existe).

mysql> drop database pandora;

8. Introduzca la siguiente sentencia SQL para preparar las credenciales y establecer comunicación con el master:

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).

9. Importe el sql vertido sacado del servidor Master actual:

mysql> SOURCE /tmp/dbdump.sql;

10. Inicie SLAVE

mysql> SLAVE START;

11. Vigile el status de la sincronización.

mysql> SHOW SLAVE STATUS;

12. Debería ver: "Waiting for master to send events" para confirmar que todo está correcto.

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

En ambos servidores:

mysql> grant all privileges on pandora.* to [email protected] identified by 'pandora';
mysql> flush privileges;

1.4.1 Iniciar el Servidor de Pandora

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:

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

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.


Info.png

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)

 


1.6 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.

1.6.1 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 &

1.6.2 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 &

1.6.2.1 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

1.6.2.2 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

Volver a Indice de Documentacion Pandora FMS