Difference between revisions of "Pandora: Documentation es: MySQL Replica"
Mario pulido (talk | contribs) (→Paso de antiguo Master a Slave) |
(→Modelo de replicacion binario MySQL para HA) |
||
Line 5: | Line 5: | ||
== Introducción== | == 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. | + | 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. | |
− | |||
Line 14: | Line 13: | ||
192.168.10.202 (master) -> Servidor maestro. | 192.168.10.202 (master) -> Servidor maestro. | ||
− | |||
192.168.10.203 (slave) -> Servidor esclavo | 192.168.10.203 (slave) -> Servidor esclavo | ||
Revision as of 10:09, 16 January 2018
Volver a Indice de Documentacion Pandora FMS
Contents
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 [email protected] 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