Publicado el

Añadir un nuevo nodo a un Cluster Galera

clusterEn este post veremos cómo añadir un nuevo nodo a un cluster MySQL en producción. Las pruebas se han hecho con este escenario:

Lo primero que haremos será situarnos sobre el que será el nuevo nodo y seguir los pasos descritos a continuación:

1. Si no lo tiene ya, deberemos instalar Percona-XtraDB Cluster, para posteriormente poder restaurar el backup. Recuerda:

Continuar leyendo «Añadir un nuevo nodo a un Cluster Galera»

Publicado el

Backups en un Cluster MySQL (PXC 5.6)

datacenterDespués de montar un clúster PXC o Galera Cluster (versión 5.6 en servidores CentOS 6.5), igualmente querremos hacer backups de nuestros datos. Para ello, bastará con realizar un backup de uno de los nodos, puesto que todos los nodos contendrán exactamente la misma información. Aunque en realidad no es tan fácil…

Problemas con los backups en un cluster Galera

Hemos de tener en cuenta que los backups, en algún punto, realizarán un FLUSH TABLES WITH READ LOCK, que hará que ese nodo no permita escrituras y por tanto, no se podrán realizar escrituras en el cluster durante ese tiempo [Fuente 1 y Fuente 2]. La explicación es que una escritura al cluster devolverá ok cuando se haya replicado a todos los nodos del mismo. Por tanto, si un nodo no puede escribir, todo el cluster no podrá escribir.

A ésto hay que sumarle que por defecto un backup en PXC/Galera no guardará los «Global Transaction ID«, necesarios para poder dar de alta nuevos nodos de forma rápida (ahorrándonos el SST inicial) a raíz de ese backup. [Fuente, transp. 44]

Continuar leyendo «Backups en un Cluster MySQL (PXC 5.6)»

Publicado el

Instalar Percona XtraDB Cluster 5.6

percona

Hace un tiempo, escribí sobre cómo instalar Percona XtraDB Cluster 5.5, de cara a tener una solución tipo cluster para MySQL basada en Galera. Los últimos días, he estado testeando la nueva versión de Percona XtraDB Cluster 5.6, y me he encontrado con algunas diferencias respecto a la instalación/configuración de la versión 5.5.

Requisitos

Para empezar, de cara a instalar Percona XtraDB Cluster 5.6, es necesario contar con socat instalado en todos los nodos del cluster antes de empezar a instalar Percona. En mi caso, en un Centos 6.5, me ha dado problemas la instalación desde sources, y finalmente lo he instalado desde un repositorio externo.

[root@myServer1]# cd /etc/yum.repos.d
[root@myServer1]# wget --no-cache http://www.convirture.com/repos/definitions/rhel/6.x/convirt.repo

Fuente: http://www.convirture.com/wiki/index.php?title=C2_fedora_installation

Tras contar con socat, he podido instalar el cluster, igual que en la versión 5.5.

Continuar leyendo «Instalar Percona XtraDB Cluster 5.6»

Publicado el

Instalar y configurar MySQL Percona XtraDB Clúster

clusterPercona XtraDB Clúster, es la solución de alta disponibilidad y balanceo de carga multi-máster del fork de MySQL «Percona». La solución recomendada para un cluster necesita un mínimo de 3 nodos, pero siempre un número impar de nodos. En este post, sin embargo, montaremos un cluster Percona con 2 nodos y un árbitro -todo con Percona XtraDB Cluster 5.5 y wsrep_provider_version 2.6(r152)- puesto que supondremos que únicamente disponemos de dos servidores dedicados para el clúster. Más adelante se explicará qué es y para qué sirve un árbitro.

Percona Master-Slave vs XtraDB Clúster

Master-slave consta de un único servidor que permite escrituras, mientras que resto de nodos (slaves) únicamente permiten lecturas. Los slaves replicarán los datos del único master, y se mantendrá así los mismos datos en todos los nodos de la solución. En este caso, si se dispone de un balanceador para los slaves, tendremos un balanceo de carga para las lecturas, lo cual hace de esta solución una solución ideal para entornos con un alto volumen de lecturas. Además, se conseguirá un entorno de alta disponibilidad para las lecturas, pero no así para las escrituras.

Con XtraDB Clúster tendremos múltiples servidores corriendo varios MySQL (basados en Percona) con los mismos datos, permitiendo a los clientes escribir en cualquiera de los servidores, y replicando los datos al resto de nodos del clúster. Ésto es ideal para entornos donde hay un gran volumen de escrituras, pero también de lecturas, o donde necesitemos tener alta disponibilidad, también de los nodos «master» (que permiten escrituras).

Limitaciones

Percona XtraDB Cluster, está basado en Galera Cluster (igual que MariaDB Cluster), y por tanto, a día de hoy, tiene un seguido de limitaciones  de entre las que destacan:

  • La replicación sólo funcionará con las tablas InnoDB. Puede haber otras tablas pero no se replicarán, lo cual significa que no se encontrarán en todo el clúster, únicamente existirán en ese nodo.
  • La velocidad de escritura de todo el clúster, viene delimitado por el nodo más lento. Si un nodo tiene problemas y se vuelve lento, el clúster entero será lento.
  • Puede darse el caso de que dos clientes estén modificando la misma celda al mismo tiempo. Si ésto ocurriera, únicamente uno de los dos tendría éxito, mientras que el otro recibiría un error de MySQL.
  • Se recomienda un mínimo de 3 nodos, aunque en la documentación oficial también confirman que se puede montar con 2 nodos. En entornos con dos nodos es altamente recomendable montar un árbitro (que es lo que haremos).
  • Ver listado completo.

Continuar leyendo «Instalar y configurar MySQL Percona XtraDB Clúster»

Publicado el

MongoDB: Recuperar un config server

mongodbHoy me he encontrado, que tras una caída de un servidor que alojaba un config server de mi cluster MongoDB 2.2.0 (sobre un entorno Red Hat), el config server no era capaz de arrancar. Concretamente, al intentar iniciar el config server, podría ver los siguientes logs en el fichero de error:

Thu Sep 12 11:47:37 [initandlisten] dbexception during recovery: 15874 couldn’t uncompress journal section
Thu Sep 12 11:47:37 [initandlisten] exception in initAndListen: 15874 couldn’t uncompress journal section, terminating
Thu Sep 12 11:47:37 dbexit:
Thu Sep 12 11:47:37 [initandlisten] shutdown: going to close listening sockets…
Thu Sep 12 11:47:37 [initandlisten] shutdown: going to flush diaglog…
Thu Sep 12 11:47:37 [initandlisten] shutdown: going to close sockets…
Thu Sep 12 11:47:37 [initandlisten] shutdown: waiting for fs preallocator…
Thu Sep 12 11:47:37 [initandlisten] shutdown: lock for final commit…
Thu Sep 12 11:47:37 [initandlisten] shutdown: final commit…
Thu Sep 12 11:47:37 [initandlisten] shutdown: closing all files…
Thu Sep 12 11:47:37 [initandlisten] closeAllFiles() finished
Thu Sep 12 11:47:37 [initandlisten] shutdown: removing fs lock…
Thu Sep 12 11:47:37 dbexit: really exiting now

Al parecer, el fichero de journal se ha corrompido con la caída del server y ni si quiera es capaz de solucionarse con un «–repair». Aprovechando que mi cluster tiene 3 config servers, he pasado a parar uno de los dos config servers que aun funcionaban, para copiar los datos del dbpath al config server corrompido, con tal de recuperarlo.

El proceso ha sido el siguiente, descrito en la documentación oficial de MongoDB (v2.2): Continuar leyendo «MongoDB: Recuperar un config server»

Publicado el

Limpieza y rotación del slow-query-logs

cleanupYa hablamos de cómo limpiar de forma segura el error-log de MySQL. Otro fichero de logs que puede dar problemas, si lo tenemos activado, es el slow_query_log, que se encarga de almacenar las queries que se han ejecutado sin índices, o que han tardado más de determinados segundos en ejecutarse. Este fichero, por tanto, nos debería servir para identificar puntos de mejora en nuestras queries, pero si tenemos mucho que mejorar, se llenará rápidamente. En mysqlperformanceblog explican cómo crear un script para uso de logrotate para limpiar de forma automática este log de forma periodica, y evitar así problemas mayores.

Primero, crearemos el script de rotación, cogido directamente de mysqlperformanceblog:

[root@myserver]# vi /etc/logrotate.d/mysql-slow

/var/lib/mysql/mysql-slow.log {
nocompress
create 660 mysql mysql
size 1G
dateext
missingok
notifempty
sharedscripts
postrotate
/usr/bin/mysql -u logrotate -pmipassword -e ‘select @@global.long_query_time into @lqt_save; set global long_query_time=2000; select sleep(2); FLUSH SLOW LOGS; select sleep(2); set global long_query_time=@lqt_save;’
endscript
rotate 5
}

Se ha de tener en cuenta, que en la instrucción de postrotate, necesitaremos añadir el usuario y password de acceso al mysql para poder ejecutar esas consultas. También se deberá indicar la ruta al fichero del slow-log en la primera instrucción (marcado en negrita).

Continuar leyendo «Limpieza y rotación del slow-query-logs»

Publicado el

Instalar y configurar REDIS desde source

91018527El título es bastante identificativo. Este post explica cómo instalar y configurar Redis (la base de datos/caché key-value) en CentOS 6 desde source, si por alguna razón no pudiéramos o no quisiéramos instalar mediante yum.

Descarga e instalación

Podemos descargar la última versión estable de Redis directamente desde la web oficial. Bastará con extraer el tarball y ejecutar «make«:

[root@myserver]# wget http://redis.googlecode.com/files/redis-2.6.13.tar.gz
[root@myserver]# tar xzf redis-2.6.13.tar.gz
[root@myserver]# cd redis-2.6.13
[root@myserver]# make

Si todo ha ido bien, ya tendremos Redis listo. Como seguramente habremos descomprimido el tarball en un directorio temporal, en mi caso he preferido cubrirme las espaldas y mover el directorio extraido (y posteriormente recompilado con make) a /etc/redis/installation_files.

[root@myserver]# cd ..
[root@myserver]# mv redis-2.6.13 installation_files
[root@myserver]# mkdir /etc/redis
[root@myserver]# mv installation_files /etc/redis/

Continuar leyendo «Instalar y configurar REDIS desde source»

Publicado el

Vaciar el error.log de MySQL

Un tema que me ha preocupado siempre, son los logs de MySQL, y más concretamente el error.log. En entornos de replicación, el error.log puede llegar a ser gigante cuando se usan sentencias que el sistema detecta como «advertencias». Por ejemplo:

[Warning] Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. The statement is unsafe because it uses a LIMIT clause. This is unsafe because the set of rows included cannot be predicted.

¿Cómo podemos vaciar el error.log de forma segura, sin que tenga impacto en el servicio de MySQL? Pues vamos a verlo.

Continuar leyendo «Vaciar el error.log de MySQL»

Publicado el

Balanceador de carga MySQL con HAProxy

balanceadorHace unas semanas, vimos cómo configurar un balanceador de carga con la aplicación de balanceo en entornos Red Hat por antonomasia: LVS, (y Piranha). LVS es la aplicación nativa de balanceo, muy bien documentada en la documentación oficial de Red Hat, e incluso vendida como balanceador en forma de addons.

Este tipo de configuraciones, funcionan muy bien, pero tienen una serie de requisitos, pues se ha de reconfigurar la red de los servidores implicados para compartir una IP Virtual, o para cambiar el default gateway (en el caso de LVS-NAT). Ésto no siempre nos es posible hacerlo, puesto que quizá estemos trabajando con un proveedor de servidores dedicados, como en mi caso Hetzner, que no permite hacer cambios en las interfaces de red que vienen configuradas en el equipo, y que además parece que no lleva bien lo de las IPs compartidas.

En cualquier caso, hay otras soluciones de balanceo, como HA Proxy, que en el siguiente ejemplo usaré para balancear las peticiones MySQL entre dos servidores con IPs públicas situados bajo el mismo switch, en Hetzner. Todos los servidores son CentOS 6.3 x64.

Continuar leyendo «Balanceador de carga MySQL con HAProxy»

Publicado el

Duplicar un slave MySQL con Rsync

Fotor0427201142Ya hemos hablado de cómo crear un entorno con varios slaves mediante XtraBackup, pero también existe la posibildad (mucho más drástica) de copiar los datos de un slave a otro, mediante rsync. Normalmente, siempre usaremos la opción de XtraBackup, pues con XtraBackup se puede hacer un backup en caliente (sin necesidad de parar MySQL) y por tanto no se necesita ninguna interrupción en el servicio.

Sin embargo, también existe la opción de usar rsync, que en mi caso, he testeado bajo en siguiente entorno:

  • Slave1 (origen): CentOS 6.3 con Percona 5.5 Release rel29.3, Revision 388
  • Slave2 (destino): CentOS 6.3 con Percona 5.5 Release rel29.4, Revision 401

NOTA: Sí, he hecho el test con dos versiones ligeramente diferentes de Percona, ya que estoy en un entorno de test.

En mi caso, he seguido el siguiente proceso para realizar la copia:

Continuar leyendo «Duplicar un slave MySQL con Rsync»