Mover la base de datos MySQL a otro disco duro
Publicado el Domingo 21 de Enero del 2007 @ 23:22 por Armonth.
Acabo de terminar un pequeño experimento con un conocido el cual tiene un servidor GNU/Linux para sus páginas web bastante saturado y nos hemos encontrado con que las páginas se sirven muy bien pero el acceso a la base de datos MySQL es muy lento.
La causa no era ni CPU, ni memoria, era un nivel alto de lecturas y escrituras I/O al disco duro. Así que casi al mismo tiempo hemos hecho la pregunta ¿y si ponemos MySQL en otro disco duro? dicho y hecho. Le digo que ponga otro disco duro en otro canal que no sea el ya usado y se ríe (presuponía que usaba IDE, como se nota que ando desactualizado habiendo SATA hoy en día).
/etc/init.d/mysql stop
mount /dev/sda3 /mnt/hd3 # Nuevo disco duro
mv /var/lib/mysql /mnt/hd3 -rf
ln -s /mnt/hd3/mysql /var/lib/mysql
/etc/init.d/mysql start
Y listo, datos “migrados” al otro disco duro, nada difícil. Recomendar además usar vmstat que te da en la columna bo la cantidad de operaciones I/O. La mejora se ha notado en más de un 300% :).
10 Comentarios (feed)
-
InKiLiNo nos comenta:
La verdad no acabo de entender que ventajas tienes el poner la BD en otro disco duro, yo lo tengo todo en el mismo y va bien, lo unico que hay que tener espacio libre :P
-
guillem nos comenta:
=:-O
-
Armonth nos comenta:
Inkilino si lo dice el artículo, las operaciones de lectura/escritura y I/O (entrada/salida) de datos por un canal IDE o SATA están limitados… tú puedes tener 200GB de disco duro pero no podrás acceder a ellos “de golpe” por la limitación de buffer/velocidad de acceso…
Imaginate que tienes una conexión a Internet de 1 gigabyte (1024 megabytes) por segundo (y no hablamos de bits, si no de bytes) y una tarjeta de red capaz de soportar ese tráfico (lo cual es muy exagerado, el Gigaethernet son 1000mbps osea bits).
Con esa conexión y encima que el servidor la soportará, ¿podrías descargar a 1024 megabytes/s? NO. Por que tú disco no sería capaz de mover tantos datos por segundo.
Un disco duro a 7200RPM (y los mejores SATA/SCSI llegan a 10.000/15000) de media mueve 400-450MB/s de lecturas cacheadas pero en buffer apenas llegan a los 50MB/s.
Teniendo en cuenta estos datos y que aparte de lecturas también hay modificaciones y otros tipos de datos… si tenemos mucha carga I/O (se mueven muchos datos entre el HD y la CPU) el acceso a las BBDD pueden resentirse bastante.
Mover las BBDDs a otro disco duro es una operación “barata” (lo más óptimo sería tener un servidor sólo para esta acción) para que MySQL tenga todo “un canuto” I/O para si solo.
Guillem: ¿?…
-
Reboot nos comenta:
Es posible que no tenga nada que ver con vuestra problemática, pero, en mi experiencia, Mysql es muy perro con los índices y si haces queries con el orden incorrecto, el puto My hace full search en vez de tirar del índice.
Recuerdo una vez que un servidor empezó a usar CPU como un poseso en las consultas a medida que una base de datos empezó a engordar y no encontrábamos el porqué. Teóricamente todas las consultas ‘deberían’ tirar de índices, porque siempre se pedían datos de ellos y no del resto de la tabla.
Tras dar muchas vueltas, cambiar de partición, de disco, recompilar y toda la movida, al final se me ocurrió hacer Describe de todas las queries que lanzábamos a la base de datos.
Imagináos la cara de capullos que se nos puso cuando descubrimos que My no estaba usando casi ninguno.
Os pongo un ejemplo
Tabla Nombres.
IDNombre
Nombre
Apellido
Dirección
Teléfono
Etc…Donde:
IDNombre es PK
Y tenemos un índice con Nombre y Apellido.Pues bien:
“Where IDNombre=xxxx”
Usa la PK
“Where Nombre=’xxxxx’”
Usa parcialmente el índice
PERO
“Where Apellido=’xxxx’ and Nombre=’xxxx’”
ó
“Where Apellido=’xxxx’”
La hija de puta hace full seach. -
Bad_CRC nos comenta:
Yo el otro día tuve que moverlo de particion en frozen pq se quedó sin disco duro en la que estaba, en vez del enlace (que nunca sabes cuando puede llevarte a confusiones) lo qu ehice fué decirle al MySQL en su configuracion (my.cnf) que la db estaba en otro lado y listo:
1 - paras el mysql
2 - mv /var/lib/mysql /home
3 - editar /etc/my.cnf: datadir = /home/mysql
4 - ???
5 - Arrancar mysql y Profit XD -
Armonth nos comenta:
No deja de ser otro método Bad_CRC :)
-
InKiLiNo nos comenta:
Buena lección la que me has dado, lo tendré en cuenta, o sea que si le meto otro disco duro para la BBDD, aunque sea uno pequeño, por ejemplo tengo alguno de 2,5 Gb(para la BBDD no necsito más), me ira más rápido, ¿no?
Pues te haré caso y lo probaré :P
-
Reboot nos comenta:
Hombre, si es un disco de 2′5GB seguramente tiene más de 6 ó 7 años. Yo me lo pensaría dos veces antes de meter información sensible y sin backup en un disco al que le quedan dos telediarios. Y por supuesto, irá mucho más lento.
-
Moncho nos comenta:
Exlente maestrin, yo hicelo lo mismo, en un servidor que tenia, use la misma tecnica que tu con mi amigo en un servidor plolait HP, le pusimos dos discos duros scaci y uno estaba dedicado al DB, si efectivamente un link de simbolico funca a la perfección =) saludos
-
Rómulo nos comenta:
me interesa mucho el tema…. ¿podrías tener la gentileza de aclararme si este procedimiento es válido para MySQL bajo Windows?…. otra consulta, tengo una base de datos alojada en un servidor y la administro con phpMySQL el cual tiene la opción de exportar tablas y demás. ¿Es buena ese medio para poder exportar y luego importar data o recomiendas otro administrador para MySQL que puediera utilizar?
Muchas gracias por tu tiempo y respuesta.
Un saludo desde Lima, Perú
