Uno de los grandes problemas del log de slow queries de MySQL es la gran cantidad de ruido que se acaba introduciendo limitando mucho la utilidad de revisar dicho log, especialmente si se revisa cada mucho tiempo. Una opción para reducir dicho ruido es min_examined_row_limit

La variable min_examined_row_limit permite indicar un valor mínimo de filas examinadas para que una query (aunque tarde más que el tiempo que tengamos definido en long_query_time) sea incluida en el log o no. Dicho valor por defecto esta a 0.

mysql> show variables like 'min_examined_row_limit';
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| min_examined_row_limit | 0     |
+------------------------+-------+
1 row in set (0.00 sec)

Aumentando el valor evitaremos que se incluyan en el log queries que …

Teniendo uno o varios MySQL slave, lo lógico es repartir las lecturas entre los varios servidores, por lo que necesitamos un SELECT que nos identifique el servidor con el fin de verificar que realmente estamos repartiendo las lecturas entre servidores.

A partir de la versión 5 de MySQL se introdujo la base de datos information_schema dónde podemos encontrar mediante tablas mucha información sobre el estado del MySQL.

Mediante la tabla global_variables, podemos obtener el hostname del servidor que esta ejecutando la query, por lo que identificaremos el servidor que estamos usando:

mysql> select * from information_schema.global_variables where variable_name="HOSTNAME";
+---------------+----------------------+
| VARIABLE_NAME | VARIABLE_VALUE       |
+---------------+----------------------+
| HOSTNAME      | …

Anteriormente vimos cómo hacer backups de un MySQL con una clave simétrica que luego ciframos con una clave pública. Vamos a ver cómo hacer la operación inversa para descifrar el backup y recuperar los datos.

Primero de todo deberemos recuperar la clave simétrica del fichero cifrado, para ello deberemos usar la clave privada con la opción rsautl -decrypt:

openssl rsautl -decrypt \
        -in backup_key_20120704.secret \
        -out backup_key_20120704.key \
        -inkey privkey.pem 

Este comando nos genera el fichero backup_key_20120704.key que contiene la clave simetrica descrifrada. A continuación deberemos descifrar el backup con dicha clave. Para ello deberemos usar la opción enc pero con la opción -d para descifrar, el …

En el caso que intentemos cifrar unos datos directamente con una clave pública, obtendremos el siguiente mensaje de error:

RSA operation error
140654231455560:error:0406D06E:rsa routines:RSA_padding_add_PKCS1_type_2:data too large for key size:rsa_pk1.c:151:

Vamos a ver cómo cifrar unos backups con clave pública.

No podemos cifrar backups directamente con la clave pública, pero sí que podemos emular el intercambio de claves simétricas del protocolo TLS. Por lo tanto, para cifrar un backup podemos crear una clave aleatoria:

openssl rand 128 -out $BACKUP/backup_key_$(date +%Y%m%d)

Con dicha clave de 128 bytes ciframos los backups:

openssl enc -aes256 -in $BACKUP/backup_${db}_${taula}_$(date +%Y%m%d).sql.gz \
        -out $BACKUP/backup_${db}_${taula}_$(date +%Y%m%d).sql.gz.secret \
        -pass file:$BACKUP/backup_key_$(date +%Y%m%d)

Lanzando una query que necesite espacio temporal en un MySQL nos puede devolver el siguiente error:

General error: 126 Incorrect key file for table '/tmp/#sql_254c_0.MYI'; try to repair it

Esto se debe a que nos hemos quedado sin espacio en el sistema de ficheros mientras se creaba la tabla temporal. Podemos ver dónde se intentan crear dichas tablas temporales mediante la variable tmpdir:

mysql> show variables like 'tmpdir';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| tmpdir        | /tmp  |
+---------------+-------+
1 row in set (0.00 sec)

Deberemos:

• Ver si podemos simplificar la query, quizá esta mal construida y esta haciendo una join sin condición
• Augmentar el espacio en el sistema de ficheros o cambiarlo a otro con más espacio …

Mediante SET GLOBAL / SET SESSION podemos modificar ciertos valores de MySQL, pero no aceptan unidades:

mysql> set session max_allowed_packet=20M;
ERROR 1232 (42000): Incorrect argument type to variable 'max_allowed_packet'

En lugar de tener que calcularlo fuera del MySQL, podemos indicar la operación. Por ejemplo, para 20M podemos indicar 20*1024*1024:

mysql> show variables like 'max_allowed_packet';
+--------------------+----------+
| Variable_name      | Value    |
+--------------------+----------+
| max_allowed_packet | 10485760 | 
+--------------------+----------+
1 row in set (0.00 sec)

mysql> set session max_allowed_packet=20*1024*1024;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like 'max_allowed_packet';
+--------------------+----------+
| Variable_name      | Value    |
+--------------------+----------+
| …

Existe la creencia que mandar un SIGTERM a un mysqld no es la forma correcta de apagar un MySQL, en realidad es otra opción igual de válida.

En la documentación de MySQL referente al apagado del daemon podemos ver los pasos que se realizan:

• Ya sea mediante el mysqladmin shutdown o cuando el mysqld recibe un SIGTERM se inicia el proceso de apagado
• Si es un cliente que manda el shutdown (mysqldadmin shutdown) se crea un thread para gestionar el apagado del daemon. Si se manda el thread se puede crear o ser gestionado directamente por el handler del evento
• A continuación deja de aceptar nuevas conexiones
• Se matan todas las conexiones establecidas …

Al exportar una base de datos con mysqldump y quererla reimportar deberemos vigilar si nos añade el use database por si queremos importarla con otro nombre.

Las opciones de mysqldump al respecto son:

$ mysqldump
Usage: mysqldump [OPTIONS] database [tables]
OR     mysqldump [OPTIONS] --databases [OPTIONS] DB1 [DB2 DB3...]
OR     mysqldump [OPTIONS] --all-databases [OPTIONS]
For more options, use mysqldump --help

Para exportar una base de datos, podemos usar indistintamente mysqldump <db> o mysqldump –databases <db>, pero existe una pequeña diferencia:

Con la opción –databases podemos indicar más de una única base de datos, por lo que nos añadirá el comando use db antes de exportar cada base de datos. Por lo tanto, si luego queremos importar el dump en otra base de datos …

En un MySQL con replicación, todo lo que acaba en el binlog se consideran modificaciones que se traspasan a los slaves para que sean modificados igual que el master.

En el caso de los analyze y optimize, no se ve tan claro como un UPDATE:

• analyze: Actualiza la información que utiliza el optimizador sobre la distribución de las filas en la tabla
• optimize: Elimina el espacio que ya no se usa: Cuando un dato es eliminado es marcado como eliminado en lugar de eliminar-se, con este comando recreamos la tabla eliminando el espacio no utilizado

Estos comandos acaban en el binlog, por lo que no hace falta tener estas tareas programadas en los slaves. Mediante el comando mysqlbinlog lo podemos ver: …

En MySQL existen dos timeouts diferentes según si el cliente se identifica como una conexión interactiva o no. Las variables que definen estos timeouts son wait_timeout y interactive_timeout

Si definimos en el my.cnf los siguientes timeouts:

wait_timeout=60
interactive_timeout=90

Con el siguiente código PHP:

<?php
$link = mysql_connect('localhost', 'root', '');

print_r(mysql_fetch_assoc(mysql_query("show variables like 'wait%';")));

mysql_close($link);
?>

Obtendremos el valor de wait_timeout de la sessión no interactiva:

$ php wait.php 
Array
(
    [Variable_name] => wait_timeout
    [Value] => 60
)

Pero si nos conectamos con el cliente de consola el valor de wait_timeout tomará el …