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

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»

Publicado el

RAID1 vs RAID0 en replicación MySQL

MySQL RAIDHoy vamos a intentar mejorar la replicación de un slave MySQL, cuyo master recibe demasiadas modificaciones como para que el slave sea capaz de seguirle el ritmo. El problema que tienen los slaves, es que con versiones anteriores a MySQL 5.6, la replicación usa un único thread, y por tanto, las sentencias a replicar se ejecutan de forma secuencial. En realidad, si usamos una única base de datos, con MySQL 5.6 y su replicación con múltiples threads, no ganamos nada, puesto que MySQL 5.6 aporta un thread por base de datos.

El testeo se ha realizado con servidores CentOS 6.3 a 64 bits, con dos discos SATA 7200rpm.

Identificando el problema

En cualquier caso, el primer paso es identificar el problema, lo cual de forma natural haríamos con un «top». A continuación veremos como el único proceso del server consumiendo algo de recursos es el proceso mysqld, que a pesar de eso, no llega ni mucho menos a provocar un problema de CPU ni de RAM. Sin embargo, si que vemos un 9.6% de %iowait lo cual indica que podríamos tener ahí el cuello de botella.

[root@slave]$ top
top – 12:28:38 up 23:10,  1 user,  load average: 2.76, 2.72, 2.69
Tasks: 211 total,   3 running, 208 sleeping,   0 stopped,   0 zombie
Cpu(s):  2.7%us,  1.6%sy,  0.0%ni, 85.8%id,  9.6%wa,  0.0%hi,  0.2%si,  0.0%st
Mem:  32776052k total, 32519856k used,   256196k free,   156192k buffers
Swap: 16777136k total,   122344k used, 16654792k free,  9163420k cached

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
4450 mysql     20   0 29.0g  21g 4628 S 37.7 68.0 394:26.55 mysqld 
584 root      20   0     0    0    0 S  6.0  0.0  70:17.46 md4_raid1

Continuar leyendo «RAID1 vs RAID0 en replicación MySQL»

Publicado el

Resetear un Slave en Replicación MySQL

resetHoy toca escribir sobre otra situación que se puede dar en entornos MySQL con Replicación. Este ejemplo está sacado de un entorno Percona 5.5 con un master y tres slaves, pero debería servir para MySQL 5.5.

Es posible que nos encontremos con la necesidad de reiniciar por completo el estado de los slaves (de todos o de alguno de ellos), incluyendo el substituir la base de datos por una más actual del master. Ésta es una situación bastante drástica, pero afortunadamente existen métodos que nos permite realizar este proceso sin detener el servicio y sin que impacte de forma drástica en el rendimiento.

El proceso está sacado de la web de Percona, y es el siguiente:

Redirigir las lecturas

El servidor Master es el server más crítico. Seguramente esté en producción, y no querremos afectar a la aplicación que esté usando esta base de datos. Lo que tendremos que hacer es modificar nuestra aplicación para que las lecturas que antes iban a los slaves, pasen al master de forma temporal, antes de iniciar este proceso.

Continuar leyendo «Resetear un Slave en Replicación MySQL»

Publicado el

Seconds_Behind_Master no para de crecer

timeYa hemos hablado de replicación Master-Slave (o replicación) con anterioridad, pero, ¿cómo saber en qué estado están los slaves? ¿Está todo funcionando?

Hay un comando sumamente útil (y necesario) que nos muestra una serie de información, que nos puede venir muy bien para saber cómo están nuestros slaves. El comando lo ejecutaríamos en el cliente MySQL de cada servidor slave:

mysql> show slave status\G;

Entre la información que devuelve, destacan dos variables que han de estar a «Yes» para asegurar que la replicación está funcionando:

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

El parámetro «Seconds_Behind_Master» también nos ayudará a ver cómo de sincronizado va ese slave, respecto al master, en segundos, pero no es un valor muy exacto.

Continuar leyendo «Seconds_Behind_Master no para de crecer»

Publicado el

Configuración MySQL Master Slave

Cloud ComputingÉste es un post que he tenido en borrador durante varios meses, por la pereza de acabar de pulirlo. Por fín, me ha coincidido otra configuración de MySQL Máster-Slave (esta vez basada en un entorno CentOS 6.3 con Percona Server 5.5), y he aprovechado para, a la vez que seguía los pasos, acabar de documentar el proceso.

Una de las posibilidades que nos ofrece MySQL (o Percona), es la de montar un entorno en el que se tienen varios servidores, cada uno con una réplica de las bases de datos. De esta manera, el servidor con el rol de máster, es el único que permite lecturas y escrituras, mientras que el resto de servidores, con el rol de slaves, únicamente permiten lecturas, y se encargan de actualizar sus datos con las modificaciones que reciben del master.

Está claro que este tipo de entornos mejora el rendimiento de cualquier aplicación, al repartir la carga de trabajo de la base de datos entre varios servidores. Además, se puede usar un balanceador de carga para los slaves, de manera que podamos incluir más slaves según lo necesitemos.

Partimos de un entorno con MySQL Server instalado en nuestros servidores (vamos a usar un servidor como Master y otro como Slave, a modo de ejemplo). Los MySQL Servers se han iniciado (creando así las tablas de sistema) y pueden tener tuneadas o no, sus configuraciones. Sin embargo, en el ejemplo, no hay bases de datos adicionales, más allá de las que genera el propio sistema al iniciar el servidor. NOTA: No pasaría nada si el master tuviera otras bases de datos, pero lo importante es que los slaves no tengan otras bases de datos, a ser posible, puesto que si algún slave ya tuviera una base de datos también existente en el master, tendríamos problemas si los datos difirieran.

Continuar leyendo «Configuración MySQL Master Slave»

Publicado el

Instalación y configuración de Percona

Percona MySQL ServerPercona es un conocido fork de MySQL que promete aumentar rendimiento y fiabilidad, además de añadir funcionalidades adicionales interesantísimas.

Tenemos varias opciones de instalación de Percona, según nuestras necesidades, pero yo he probado a instalar Percona Server, para montar replicación tipo Master-Slave. Para ello he usado un Centos 6.3 i386, como PC de tests, donde le he instalado un Percona Server 5.5. Dejaré Percona XtraDB-Cluster para otra ocasión.

Requisitos de Percona Server

Desde ya, recomendaría deshabilitar selinux (o configurarlo convenientemente) antes de iniciar este proceso. También deberemos asegurarnos de que la máquina pueda resolver su hostname, revisando el fichero de hosts.

Continuar leyendo «Instalación y configuración de Percona»