Hoy 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 cachedPID 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
