Errores típicos al configurar un servidor MySQL
Con la versión 5.8 de MySQL, se pueden optimizar casi 460 variables de la configuración. Esto, que para bases de datos de pocos MB no tiene mayor misterio (y es algo que no deberías tocar), se complica cuando los órdenes de magnitud de datos almacenados son de cientos de GB.
¿Por qué usar (la última versión) de MySQL?
Antes de meternos en materia, me gustaría recomendarte que siempre que sea posible, trabajes con la última versión estable de MySQL. En la versión 5.8 los cambios son notables.
Como se puede leer en la web oficial, desde la última versión de MySQL, estos han sido los cambios más importantes que han incorparado.
- InnoDB buffer pool instances
- InnoDB full text search
- JSON support
- Group Replication
- Multi-threaded replication
- Online buffer pool resize
- Native InnoDB partitions
¿Tan importante es optimizar la base de datos?
Sí, vale. Puedes usar MySQL sin tocar ningún parámetro de la configuración por defecto. Pero conforme tu carga de trabajo aumente (y sobre todo el volumen de datos que procesas), tu base de datos se volverá más y más lenta.
Por ello, hay que prestar especial cuidado a la hora de elegir ciertos parámetros en el fichero my.cnf que harán nuestra base de datos vaya como un tiro.
Revisemos algunos de estos parámetros.
Errores típicos al configurar un servidor MySQL
Antes de que en otro post te hable de las variables clave de configuración de MySQL, me gustaría repasar rápidamente los errores más importantes errores que he visto que se cometen al configurar y optimizar un servidor MySQL.
Usar el método de prueba y error
He visto a muchos clientes que cambian algunas cosas y comprueban si algo ha mejorado. Y este es el principal error que se está comete cuando hay cientos de variables en juego.
El problema es que para el momento en que mides si algo ha mejorado (o empeorado), es posible que en función de cómo esté desarrollada la aplicación, la situación ya haya cambiado. Además, hay que tener en cuenta el tiempo de inicio (cache, enrutado, etc).
En lugar de eso, entiende exactamente qué es lo que estás cambiando y cámbialo sólo cuando sepas que eso es lo que necesitas. A menudo, ejecutar un micro-benchmark en un entorno controlado para verificar dicho cambio es una muy buena idea.
Usar Google para asesorarte sobre el rendimiento
Nunca confíes en la primera respuesta que encuentres en Google cuando busques un consejo de rendimiento, ni en el valor de tu variable específica. Muchos de los consejos en Internet son muy genéricos y a menudo carecen de contexto.
Por ejemplo, puedes encontrar muchos hilos en StackOverflow que se usaron como puntos de referencia. Sin embargo, los puntos de referencia a menudo hacen intencionalmente ciertas cosas que no deberían hacerse en un servidor de producción, como deshabilitar el búfer de doble escritura, configurar innodb_thread_concurrency a 0 y similares.
Además, muchas de las configuraciones dependen del hardware, por lo que es aún más importante entender qué es lo que está haciendo exactamente una variable específica.
Obsesionarse con parámetros exactos del my.cnf
No te obsesiones con el "fine-tuning". Usualmente 10-15 variables te darán el mayor impacto, y es probable que más allá de estas variables, la mejora sea residual (si es que la hay).
Si sigues teniendo un problema de rendimiento, incluso después de haber aplicado todas las recomendaciones (y haberse deshecho de todo lo que no deberías haber tocado en un primer lugar), es probable que el problema esté en otro lugar: malas consultas, falta de recursos, datos no cacheados, etc.
Cambiar muchas cosas a la vez
Cuando trabajas con cualquier programa que tenga un fichero de configuración, cambia sólo una cosa a la vez. De lo contrario, cuando las cosas van mal, puede que sea muy difícil o incluso imposible averiguar qué configuración podría haber causado el problema, por lo que tendrás que deshacer todos los cambios y, empezar uno por uno.
Si se trata de una nueva configuración, o si hasta ahora se estaba ejecutando con la configuración predeterminada, sin embargo, puedes hacer todos los cambios recomendados.
Edita el fichero my.cnf
No es ningún secreto que muchas variables pueden ser cambiadas "en caliente" sin tocar my.cnf. Variables como el tamaño del buffer pool de innodb puede ser cambiado online en MySQL 5.7.
Eso es muy conveniente en algunos casos para no tener que reiniciar el servidor, pero, asegúrate de actualizar el my.cnf después de que hayas terminado con los cambios o perderás todos estos cambios cuando se reinicie MySQL y tendrás que empezar de nuevo.
Entradas redundantes en my.cnf
Si utiliza la misma variable dos veces, MySQL no se quejará de ello. En la mayoría de los casos, sólo usará el último valor encontrado para la misma variable, así que asegúrate de no añadir la misma variable dos veces.
Ten en cuenta también que un guión "-" y un guión bajo "_" se pueden utilizar indistintamente, por lo que el tamaño de archivo innodb-log-log- y innodb_log_file_size se refieren a la misma configuración de servidor.
Multiplicando los tamaños de buffer
Cuando añadas más memoria RAM al servidor, no te limites a multiplicar el tamaño de todos los búferes en efecto. Algunos búferes son locales, otros globales. Algunos están relacionados con el motor de almacenamiento, otros con el servidor.
De hecho, hay muy pocas variables que necesitarás aumentar de tamaño a medida que agregas más memoria.
Conclusión: ¿cúando optimizar? ¿Merece la pena?
En resumen, como hemos mencionado en líneas anteriores, no en todos los proyectos requerirás un exhaustivo análisis y evaluación de cada una de las variables.
En los proyectos que hemos realizado en Global Decibel, nos hemos encontrado multitud de casos. Unos muy sencillos, donde intentar ajustar una base de datos de apenas unos MB es prácticamente perder el tiempo, y en otros, donde analizamos TB de datos de forma diaria de miles de tiendas de afiliación.
Finalmente mencionar, aunque parezca una obviedad, que salvo casos muy concretos, el cuello de botella para cualquier desarrollo que involucre una base de datos casi siempre estará en la propia aplicación, y no en MySQL, con multitud de años rendiendo al máximo nivel.