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: …

Toda migración acaba obteniendo una cierta complejidad si queremos minimizar el tiempo de corte y poder garantizar haya una “vuelta atrás” en caso de problemas. Vamos a ver una forma de migrar un MySQL master de un disco de una cabina a otro disco de otra cabina minimizando el tiempo de corte gracias a un slave que transformamos en master y volvemos a transformar en slave.

Suponiendo que tenemos un MySQL con un slave y queremos migrar de un disco en una cabina antigua a otro disco de una cabina nueva: Mientras se traspasan los datos podemos usar el slave como master y cuando acabe podemos sincronizar los dos MySQL y volver a dejar el MySQL con su rol habitual.

La hora de ruta sería la siguiente:

Previo a la intervención:

• Apagar procesos batch …

Como ya comenté anteriormente ahora mis esfuerzos de blogging se centran más en generar contenido para MySQL High Performance ? Para los que quieran un rápido listado de mis últimos posts, aquí lo tenéis:

• Avoiding auto-increment holes on InnoDB with INSERT IGNORE
  
• Statement based replication with Stored Functions, Triggers and Events
  
• Actively monitoring replication connectivity …