Tag mysql - Userlinux.net

Al hilo del anterior post donde intentamos salvar la prematura muerte de MySQL en manos de Oracle, la respuesta ha sido -creo yo- rotunda y en forma de comunicado de prensa. Oracle afirma:

• Asegurar la disponibilidad de las APIs de las máquinas de almacenamiento.
• Continuar mejorando MySQL en el futuro bajo la GPL, incluyendo a su versión 6.
• Invertir más en el desarrollo de MySQL de lo que lo hizo Sun en el último año fiscal (U$S 24 Millones).
• No requerir que los clientes contraten los servicios de soporte de Oracle para obtener una licencia comercial de MySQL.
• Fundar un Consejo Asesor constituído por clientes y usuarios para que ayuden a dirigir las prioridades del desarrollo de MySQL.

Espero que sea suficiente, que quede constancia del comunicado y que jamás tengamos que volver a leerlo ;). (Gracias a David por el comentario).

Michael "Monty" Widenius, el creador de MySQL está pidiendo ayuda para salvar MySQL de las garras de Oracle. El 20 de abril del 2009 Oracle se ha hecho con Sun Microsystems, el actual propietario de MySQL.

Obviamente, el mercado de Oracle se centra en su sistema gestor de bases de datos y no está muy claro el futuro de MySQL en manos de la misma compañía. Las autoridades americanas ya han dado el visto bueno a la operación sin embargo la Comisión Europea todavía está estudiando el más que posible monopolio.

Comando del día. Hace nada me pidieron un backup de una tabla de MySQL y sentí la necesidad de hacerlo en una linea (obviamente, tras 3 pruebas). Si, sé que es una tontería pero tuvo su gracia. Vamos al lío.

Para empezar no sabía si se podía hacer un dumpeo con mysqldump de una tabla en concreto, siempre lo había usado para bases de datos completas pero man me lo dejó muy claro: si después de la base de datos especificas una tabla lo haré encantado.

Imagino que hablar de controlar se me antoja demasiado duro, pero bueno, una máquina que nos trae fritos con la carga de MySQL y todavía no hemos localizado el motivo, así que dejo esto en el cron:

#!/bin/bash
LOG_FILE='/var/log/compruebamysql.log'
MYSQL_PID=`pidof mysqld`
CPU_LOAD=`ps up $MYSQL_PID | tail -1 | awk '{ print $3 }'`
CPU_LOAD2=`echo $CPU_LOAD | sed "s/\./\,/g"`
CPU_INT=`printf "%.0f" $CPU_LOAD2`

if [ "$CPU_INT" -gt "80" ]; then
        echo "[ `date +'%d-%B-%G %H:%M:%S'` ] - Se ha reiniciado MySQL por sobrecarga" >> $LOG_FILE
        /etc/init.d/mysqld restart
fi

Tan simple como comprobar que la carga de CPU no excede un porcentaje concreto (el 80% en este caso) para hacer un restart y escurrir el problema. Sé que no es óptimo pero espero que me cubra algunos días.

Por exigencia del guión, cuando conectas con Sphinx para hacer una búsqueda, éste devuelve los id's de los resultados coincidentes ordenados por relevancia (al menos en nuestro caso, que usamos el método SetFieldWeights).

[matches] => Array
(
 [100] => Array ( [weight] => 100 )
 [50]  => Array ( [weight] => 70 )
 [200] => Array ( [weight] => 30 )
 [30]  => Array ( [weight] => 30 )
)

La pregunta es, ¿cómo hacer que MySQL respete ese mismo orden?. Vamos, que si tenemos un "SELECT * FROM productos WHERE id IN (100, 50, 200, 30)" y queremos los resultados justamente en ese orden (100, 50, 200 y 30) tendremos que indicarlo en MySQL de alguna forma, puesto que por defecto (al menos en nuestras pruebas / instalaciones) ordena por la primary key...

David explains us how to trace SQL queries in a very interesting post. Recommended.

Every so often I run into situation when I need to kill a lot of connections on MySQL server - for example hundreds of instances of some bad query is running making server unusable. Many people have special scripts which can take the user, source host or query as a parameter and perform the action. There is also a way to do it just using MySQL with a few commands:

mysql> SELECT concat('KILL ',id,';') FROM information_schema.processlist WHERE user='root';
+------------------------+
| concat('KILL ',id,';') 
+------------------------+
| KILL 3101;			 
| KILL 2946;			 
+------------------------+
2 rows IN SET (0.00 sec)
mysql> SELECT concat('KILL ',id,';') FROM information_schema.processlist WHERE user='root' INTO OUTFILE '/tmp/a.txt';
Query OK, 2 rows affected (0.00 sec)
mysql> source /tmp/a.txt;
Query OK, 0 rows affected (0.00 sec)

Fully copypasted from MySQL Performance Blog.

No digo nada nuevo con la noticia de que Oracle ha comprado a Sun. Todo el mundo sabe que van a correr -ya están corriendo- ríos de tinta sobre éste asunto.

¿Qué pasará con MySQL?, obviamente no lo sé, pero cuando el pez grande se come al pequeño lo normal es que éste último muera y caiga en el olvido. A no ser que haya dejado descendencia que lo pueda vengar.

Esperemos que si algo así pasa, haya gente capaz de crear un fork y mantener el open source y a este gran sistema gestor de bases de datos por encima de todo. ¡Amén!.

Para almacenar una cadena en MySQL podemos utilizar varios tipos de campo, como nunca recuerdo la diferencia entre los normales, los medium y los long, ahí queda la nota mental:

• Char: 0-255 caracteres.
• Varchar: 0-255 caracteres.
• Tinytext: 0-255 caracteres.
• Text: 65.535 caracteres.
• Mediumtext: 16.777.215 caracteres.
• Longtext: 4.294.967.295 caracteres.

Si, nos ha extrañado, pero los campos de tipo mediumtext albergan más cantidad de datos que los text. Fin de la nota mental.

Update: A raíz del comentario de Wu me gustaría aclarar que la diferencia entre CHAR y VARCHAR es la forma en la que se almacenan los datos en MySQL. Por ejemplo entre un CHAR(4) y un VARCHAR(4) guardando el dato "ab" tendríamos que:

CHAR(4)	"ab  "
VARCHAR(4)	"ab"

Como vemos en los campos de tipo CHAR siempre se reserva el espacio que hemos designado para su uso, mientras que en los VARCHAR la asignación es dinámica siempre y cuando no se sobrepase el límite impuesto.

El TINYTEXT, junto a sus hermanos TEXT, MEDIUMTEXT y LONGTEXT son de tipo BLOB (binary large object) y su almacenamiento es distinto a CHAR ó VARCHAR.

Gracias a dmnet descubro estos scripts para MySQL que pueden ser de gran ayuda.