¡Acceso ilimitado 24/7 a todos nuestros libros y vídeos! Descubra la Biblioteca Online ENI. Pulse aquí
¡Acceso ilimitado 24/7 a todos nuestros libros y vídeos! Descubra la Biblioteca Online ENI. Pulse aquí

Configuración del servidor

Introducción

Configurar de forma correcta MySQL es esencial para garantizar tanto el rendimiento como la estabilidad del servidor. Hay varios cientos de opciones disponibles, lo que dificulta la elección de los parámetros. Por otra parte, en muchos casos, no existe un solo valor correcto que podamos aplicar con los ojos cerrados: con frecuencia, varios valores son válidos para una opción y la mejor configuración dependerá del uso del servidor.

Sin embargo, obtener una configuración correcta de nuestro servidor MySQL no es tan complicado en realidad. En primer lugar, tenga en cuenta que no hay ninguna configuración ideal: si sus peticiones se realizan sin lentitud especial y el servidor no muestra nunca signos de sobrecarga, esto significa que los parámetros esenciales están correctamente ajustados. Por otra parte, debe saber que no basta con modificar la configuración para solucionar todos los problemas de rendimiento: otros factores, como los recursos de hardware, el esquema de las tablas y los índices también tienen un impacto importante en el rendimiento. Por último, tenga en cuenta que, salvo una veintena de parámetros que es fundamental conocer y saber ajustar, la mayoría de las opciones solo son útiles en casos muy concretos que puede que no se le presenten nunca.

He aquí algunos consejos antes de entrar en el meollo del tema:

  • Cuando...

¿Cómo configurar el servidor?

Las opciones pueden definirse en diferentes niveles:

  • Durante la compilación de las fuentes ejecutando el script configure.

  • En el archivo de configuración my.cnf (my.ini en Microsoft Windows).

  • Como parámetros del programa mysqld.

  • De forma dinámica, es decir, durante la ejecución del servidor (en caliente), con el comando SET.

Si una opción se redefine en varios niveles, es su valor en el nivel más bajo de esta lista el que se tendrá en cuenta. Por ejemplo, si en el archivo de configuración la opción long-query-time es 10 y pasamos 2 al ejecutable mysqld, el valor para el servidor será 2.

El método más práctico, más seguro y que se recomienda para configurar el servidor es usar el archivo de configuración. Sin embargo, la modificación dinámica de las opciones se impone a veces.

1. Configuración durante la compilación

Una de las formas de instalar el servidor MySQL consiste en compilar sus fuentes. En Linux, al ejecutar el script configure, podemos personalizar la instalación pasando las opciones adecuadas. Esta solución se utiliza con frecuencia en las grandes empresas para que hacer que coincida la instalación del servidor con la norma en vigor en la empresa o bien por razones de rendimiento. Las directivas especificadas constituirán la configuración por defecto, salvo si se cambian los valores en uno de los otros niveles de configuración.

La compilación de MySQL sobre las diferentes plataformas se detalla en la documentación de MySQL: http://dev.mysql.com/doc/refman/5.7/en/source-installation.html

2. Configuración en el archivo de configuración

a. Ubicación del archivo de configuración

El archivo my.cnf (o my.ini en MS Windows) es el archivo de configuración del servidor MySQL. Los programas proporcionados por MySQL (mysqldmysql, mysqldump, myisamchk...) lo consultan para buscar sus directivas. En UNIX, buscan de forma automática el archivo my.cnf en los siguientes directorios: /etc/, /etc/mysql/, SYSCONFDIR/, $MYSQL_HOME/ y ~/. SYSCONFDIR es el directorio especificado por la opción syscondir al ejecutar el script configure (etc por defecto), y $MYSQL_HOME es la variable de entorno de la ruta del directorio que contiene el archivo my.cnf.

Esta variable, en general...

Visualización de la configuración

El Administrador tiene varias posibilidades para ver la configuración del servidor MySQL. La manera más obvia es pasar por el archivo de configuración. Sin embargo, es posible que algunas de las opciones que contiene sean redefinidas al pasarlas por parámetro a mysqld. También debemos pensar en mirar el estado del proceso mysqld; por ejemplo, con el comando ps -ef | grep mysqld en Linux.

Pero estos dos primeros métodos tienen algunas limitaciones. En un servidor mal administrado, puede haber varios archivos de configuración, que el servidor no utilice necesariamente, y que además no tienen por qué llamarse my.cnf (o my.ini). Es más, los parámetros no suelen aparecer todos en el archivo de configuración y los que sí aparecen pueden redefinirse en caliente, como sucede con el parámetro de mysqld.

Para estar seguro de ver la configuración actual del servidor, debemos utilizar el comando SHOW GLOBAL VARIABLES, es decir, las tablas GLOBAL_VARIABLES del esquema virtual INFORMATION_SCHEMA o el comando SELECT @@global.nombre_variable.


mysql> SELECT * FROM INFORMATION_SCHEMA.GLOBAL_VARIABLES WHERE 
VARIABLE_NAME = 'datadir'; 
+---------------+-----------------------+  
| VARIABLE_NAME | VARIABLE_VALUE        |  
+---------------+-----------------------+  ...

Configuración de InnoDB

1. Parámetros fundamentales

No es necesario modificar la configuración predeterminada de los parámetros que se mencionan en esta sección, pero sí que es importante pararse a pensar en cuál sería el valor adecuado para su aplicación.

  • Tamaño de la caché de memoria (innodb_buffer_pool_size): se trata de la caché principal de InnoDB (buffer pool), en la que se almacenan los datos e índices a los que se accede con frecuencia. Para un servidor dedicado de MySQL, es corriente que se asigne la mayor parte de la memoria del servidor (por ejemplo, alrededor de 25 GB en un servidor con 32 GB de memoria física). La idea principal es que la caché permita evitar el acceso al disco: el tamaño de la caché es más importante que la velocidad del disco.

    Si nuestra base de datos es pequeña (decenas de GB, por ejemplo), es bastante sencillo utilizar un servidor que tenga suficiente memoria para que todos los datos e índices InnoDB se mantengan en la caché. De lo contrario, hay que tratar de tener en caché la parte útil de los datos e índices, es decir, la parte de los datos e índices utilizada con frecuencia por la aplicación. Es bastante frecuente, en efecto, tener, por ejemplo, una base de 500 GB que contiene la historia de los datos sobre los últimos cinco años, pero solo se consultan a menudo los datos del último mes, lo que representa 10 GB. En este caso, es inútil tratar de asignar 500 GB al buffer pool; 10-15 GB serán suficientes.

  • Tamaño del registro de transacciones (innodb_log_file_size): el registro de transacciones (redo log) le permite a InnoDB ofrecer un buen rendimiento de escritura, garantizando la integridad de datos en caso de fallo inesperado (ver el capítulo Aspectos generales de MySQL). La idea principal es que InnoDB escriba de manera síncrona las modificaciones en su registro de transacciones (escrituras de bajo coste, ya que son secuenciales) y que un thread en segundo plano modifique los archivos de datos de forma asíncrona (escrituras más costosas al ser aleatorias). Sin embargo, el tamaño del registro de transacciones es limitado, así que si escribe más rápido en el registro de transacciones que espacio genera la purga en segundo plano en dicho...

El registro

El servidor MySQL utiliza cuatro tipos de registros, cada uno con sus especialidades: el registro binario (binary log o binlog), el registro de peticiones lentas (slow query log), el registro general (general query log) y el registro de errores (error log), el único de los cuatro que se activará por defecto.

El relay-log, otro tipo de registro, es creado por el servidor durante la replicación. Se aborda en el capítulo Replicación.

1. El registro binario

El registro binario o binlog se encarga de almacenar en un formato binario todas las peticiones que modifican los objetos de la base de datos (INSERT, UPDATE, DELETE, DROP, CREATE, ALTER...). Es el elemento central de la replicación MySQL (ver el capítulo Replicación). También es muy útil para la restauración de los datos (ver el capítulo Respaldo y restauración). Para activar el registro binario, use la opción log-bin, y para definir su archivo de índice, configure la opción log-bin-index. Este archivo, que contiene la lista de todos los registros binarios desde la última purga, le permite al servidor conocer el nombre del archivo actual que se obtiene con el comando SHOW MASTER STATUS y también mostrar la lista de todos los registros binarios presentes en el servidor con SHOW BINARY LOGS. El registro binario se puede desactivar en caliente, pero solo para la sesión de un cliente, con la opción SQL_LOG_BIN.

No confunda los registros binarios, que registran todas las escrituras, con los registros de transacción de InnoDB (redo logs), que solo registran las escrituras en las tablas InnoDB y cuyo único objetivo es garantizar la restauración automática de InnoDB en caso de fallo inesperado.

Una configuración básica podría ser:


[mysqld]   
log-bin = /var/lib/mysql/mysql-bin
 

Observe que log-bin-index no está definido. Por defecto, el archivo se creará en el mismo directorio que los registros binarios (/var/lib/mysql aquí).

Observe también que puede especificar una ruta relativa para la opción log-bin. En este caso, la ruta será relativa en relación con el directorio de datos. Para evitar confusiones, utilice siempre una ruta absoluta.

El formato utilizado para el registro es un formato binario; es significa que las entradas del registro no pueden...

El modo SQL

El comportamiento predeterminado del servidor MySQL es bastante permisivo, en especial en lo que respecta a la coherencia de los datos. La directiva es en cierto modo: «Los datos recibidos son coherentes; por lo tanto, no es necesario comprobar nada», lo que en realidad no es siempre el caso. Si su aplicación comprueba todos los datos, se dispensa al servidor de realizar esta tarea y se evita así que disminuya el rendimiento. Sin embargo, si este no es el caso o si hay otra manera de acceder a los datos que no sea a partir de la aplicación, se debe utilizar el servidor para hacer las comprobaciones. Por ejemplo, si una cadena de caracteres es demasiado larga para insertarse en una columna, el servidor ejecutará la inserción truncando la cadena de caracteres y devolviendo una advertencia (warning) al cliente en la que dirá que los datos han sido truncados para que la inserción tenga éxito. Esto plantea dos problemas principales para la mayoría de las aplicaciones. En primer lugar, el dato presente en la tabla no es el enviado por el cliente, la coherencia de datos no está garantizada. En segundo lugar, nuestra experiencia nos ha demostrado que muy pocos desarrolladores tratan los avisos enviados por el servidor, lo cual quiere decir, por último, que se ha insertado un dato incorrecto en la base y que nadie está al corriente. La opción sql_mode que apareció en la versión 4.1 permite, entre otras cosas, resolver este tipo de problema. Esta opción puede cambiar el comportamiento del servidor:

  • Reforzando la coherencia, impidiendo la inserción implícita de datos inválidos.

  • Haciendo que el código SQL sea portátil.

  • Y proporcionando un comportamiento del servidor similar al de otros SGBD.

1. Los modos habituales

En MySQL 5.6, el valor por defecto de la variable sql_mode es NO_ENGINE_SUBSTITUTION (el comportamiento de este modo se explica un poco más abajo).


mysql> SHOW SESSION VARIABLES LIKE 'sql_mode';  
+---------------+------------------------+  
| Variable_name | Value                  |  
+---------------+------------------------+  
| sql_mode      | NO_ENGINE_SUBSTITUTION |  
+---------------+------------------------+
 

La tabla char3tinyint contiene dos columnas:...

Otros parámetros

1. Parámetros MyISAM

El único verdadero parámetro importante para las tablas MyISAM es el tamaño de la caché de índice, comandado por la variable key_buffer_size.

Para encontrar un buen tamaño, deberá fijarse en los valores de tres de las variables de estado del resultado del comando:


mysql> SHOW GLOBAL STATUS LIKE 'Key_%';
 

Las dos primeras variables que se deben considerar son key_reads y Key_read_requests. Key_reads indica el número de peticiones de lecturas de índice que no han podido ser satisfechas por la caché, y Key_read_requests indica el número de lecturas en el índice. Si calculamos el porcentaje de utilización de la caché usando la fórmula (1 - Key_reads / Key_read_requests) x 100, su caché debería estar bien configurada si su nivel es cercano al 100 %. Si la tasa es baja, la caché es sin duda demasiado pequeña y podemos aumentar el valor de key_buffer_size.

La tercera variable que debe comprobarse es key_blocks_unused, que nos da el número de bloques disponibles en la caché. Si la tasa de utilización es baja y el número de bloques disponibles es también bajo, su caché es en realidad demasiado pequeña.

Debe saber que el hecho de prever una caché sobredimensionada no penaliza, ya que la memoria solo se adjudicará en caso de necesidad, a diferencia de la caché de peticiones.

No existe ninguna opción para almacenar en caché los datos de tablas MyISAM. Solo el sistema operativo pone en caché los datos, lo que es mucho menos eficaz que una caché especializada, como la que existe para los índices.

2. Caché de peticiones

a. Función de la caché

MySQL mantiene un conjunto de resultados de peticiones de tipo SELECT en una estructura en la memoria correspondiente llamada caché de peticiones. Cuando un SELECT se ejecuta, el servidor almacena el resultado en la caché, de modo que, si un cliente solicita la misma petición en un tiempo lo bastante corto para que las tablas no hayan cambiado, el servidor pueda remitir directamente el resultado que ha conservado en la memoria, en lugar de pasar por todas las fases de descomposición, optimización y ejecución de la petición....