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 …

El error “Unknown table engine InnoDB” puede ser que tengamos el engine deshabilitado en el my.cnf con skip-innodb pero también puede ser que nos enfrentemos a problemas de memoria:

En el caso que en el my.cnf no tengamos el skip-innodb, deberemos comprobar el log del MySQL ya que nos podemos encontrar con:

120413 19:40:18  InnoDB: Error: cannot allocate 157302784 bytes of
InnoDB: memory with malloc! Total allocated memory
InnoDB: by InnoDB 7994352 bytes. Operating system errno: 12
InnoDB: Check if you should increase the swap file or
InnoDB: ulimits of your operating system.
InnoDB: On FreeBSD check you have compiled the OS with
InnoDB: a big enough maximum process size.
InnoDB: Note that in most 32-bit computers the process
InnoDB: memory space is limited to 2 GB or 4 GB.
InnoDB: We keep retrying the allocation for 60 seconds...
InnoDB: …