Tag mysql - Userlinux.net

Posts sobre el tag mysql

Oracle garantiza continuidad a MySQL

r0sk 16.Dec.2009 4 Comentarios 395 Lecturas
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).
Categorías:
Tags:

Ayuda a salvar MySQL

r0sk 14.Dec.2009 5 Comentarios 511 Lecturas
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.
Categorías:
Tags:

Dumpeo de una tabla MySQL a correo

r0sk 04.Nov.2009 1 Comentarios 341 Lecturas
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.
Categorías:

Bash: Script que controla a MySQL

r0sk 13.Aug.2009 2 Comentarios 729 Lecturas
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.
Categorías:

MySQL: ordenando query del tipo id IN array

r0sk 23.Jun.2009 4 Comentarios 558 Lecturas
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...

SQL trace

r0sk 29.May.2009 1 Comentarios 911 Lecturas
Traceando consultas SQL
Rating
David explains us how to trace SQL queries in a very interesting post. Recommended.

MySQL: Killing connections massively

r0sk 26.May.2009 1 Comentarios 598 Lecturas
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.
Categorías:
Tags:

¿Ha muerto MySQL?

r0sk 21.Apr.2009 4 Comentarios 754 Lecturas
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!.
Categorías:

MySQL: Datos de cadena

r0sk 02.Feb.2009 4 Comentarios 898 Lecturas
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.
Categorías:

MySQL: Useful Stuff

r0sk 19.Sep.2008 0 Comentarios 572 Lecturas
MySQL 5.1: Full Text Search
Rating
Gracias a dmnet descubro estos scripts para MySQL que pueden ser de gran ayuda.
Categorías:

Buscar

Cargando...

Categorías

Últimos comentarios

  • BartlettLilly20
  • r0sk
  • coder
  • argordmel
  • uveic
  • MarcosBL
  • quemada
  • alexander
  • Hakky111
  • tramel
  • hoyadas
  • hoyadas
  • hoyadas
  • Anubys
  • Arturo

Tagcloud

lugo freebsd seguridad futbol iphone mysql champions userlinux alemania_2006 copa bsd cakephp rfilms deportes meme blogs conciertos bake debian macosx apple humor programación música games 2008 beers tip lucux cake sysadmin ssh ibook films cumpleaños bash league barça soccer mundial frases opinion felicidades hack php juegos cms personal 2007 ubuntu ds mac sidenotes openbsd linux blogsfera rsidenotes blog nintendo san_froilan

Archivo

Social

Twitter

Enlaces

Enlaces de interés