Menudo bugazo de MySQLos hemos encontrado hoy! Este bug porque sí, porque lo es ya que tiene toda la pinta de ser un bicho nos ha traído de cabeza durante dos días. Si ya pensaba yo que esto de que Oracle salga de compras no nos iba a traer nada pero nada bueno, en fin webmaster of the universe os ponemos en antecedentes:

Estamos ultimando la v.3.9 del sistema de tiendas online ecOOmmerce.com en ella hemos incorporado una función que realiza las actualizador de precios y de stock semiautomatizado donde el cliente en base a un fichero bajo formato .csv (parecido al excel, realmente es un txt con campos separados por un signo) puede desde el backoffice de la aplicación actualizar los precios de una tacada.

El servidor web alojado en Hispalab corre Linux con Mysql versión 5.0.90 instalada. Nosotros disponemos acceso al Cpanel para administrar, si bien no podemos acceder a consola por SSH ni a través de Cpanel.

Intentamos hacer un típico LOAD DATA LOCAL INFILE para cargar datos de un fichero .csv en una tabla temporal de la base de datos que posteriormente será analizada por nuestra nueva función y actualizará los precios.

La sentencia es la típica, reportada en cientos y cientos de foros de desarrollo tanto en español como en lengua sajona:

LOAD DATA LOCAL INFILE ”/home/dominios/test/public_html/tmp/tarifatest.csv” INTO TABLE table01 FIELDS TERMINATED BY “;” LINES TERMINATED BY “\n”

Y desde la aplicación no recibimos error alguno, para acotar el tema vamos al Phpmyadmin a través de Cpanel y copypasteamos el comando, automáticamente nos escupe el siguiente error:

#1148 – The used command is not allowed with this MySQL version

Repasamos la sentencia de SQL mil quinientas veces y es entonces cuando el ingeniero de sistemas de Hispalab nos dice que no utilicemos el “LOCAL”. Nos documentamos y si, una vez el archivo está en servidor no hace falta utilizar el argumento “LOCAL” ahora bien, al modificar esta función nos encontramos con otro nuevo error:

#1045 – Access denied for user ’wwwtest’@'localhost’ (using password: YES)

Así que comenzamos primero desde PHP y luego desde FTP (no tenemos acceso a consola) ha realizar todo tipo de CHMODS y CHOWN para cambiar los permisos y propietarios de el archivo y la carpeta subida. No conseguimos nada más que perder el tiempo.

Desolados reportamos a Hispalab y al final y tras casi dos días de darnos cabezazos contra el teclado alguien vio la luz en Hispalab, ese LOCAL, ese LOCAL, lo probó en minúsculas “local” y… como bien dijo el “zasss…. todo funcionó”.

Impresionante, ni en la propia documentación de MySQL figura ni una sóla vez en minúsculas, puedes verlo en:

http://dev.mysql.com/doc/refman/5.1/en/load-data.html

En fin, hay queda este post por si alguna vez oss encontráis con semejante problema.

Páginas relacionadas con este artículo:

1. Optimizar servidor MySQL
2. Aplicación web PHP para backup de mysql
3. Cambiar clave root a Mysql por línea de comandos Windows

Migración de grandes hacia Cassandra db

Por la red ha saltado la alarma ya que Twitter pretende migrar al sistema de base de datos Cassandra, hasta la fecha los de Twitter confiaban en la base de datos mysql con un complejo sistema de Twitter.

No es la primera compañía que migra hacia Cassandra tras la adquisición de MySQL por Oracle, un movimiento que no ha sido del agrado de prácticamente ningún desarrollador, además con estos movimientos tan sólo acrecentamos el temor de que Oracle acabe ahorcando el proyecto libre MySQL en favor de sus sistemas de bases de datos de pago.

La base de datos Cassandra fue liberada por Facebook en el año 2008, en la actualidad es usada por servicios web de alto tránsito y de alta actividad en cuanto a base de datos se refiere, nombres como Rackspace, Digg, Facebook, Cisco, etc son algunas de las compañías que ya trabajan bajo Cassandra el echo de que muchas redes sociales de gran renombre la utilicen es garantía de su funcionalidad pues bien es sabido que tanto Twitter como Facebook y Digg son las aplicaciones web que mueven un mayor volumen de registros de bases de datos.

Características destacadas de Cassandra

Cassandra DB dispone de algunas características muy interesantes entre las que destacamos:

Tolerancia a fallos

Los datos son replicados en múltiples nodos de forma que si falla uno el sistema es capaz de leer los datos desde cualquier otro nodo sin problema alguno sin ningún tipo de downtime o tiempo de espera, elevando así el tiempo de operatividad muy por encima de MySQL.

Descentralización de los datos

Todos los clusters que conforman una base de datos disponen de la misma información por lo que los datos están replicados y se encuentran en todos los puntos aportando toda la ventaja que implica la descentralización de los datos.

Modelo de datos avanzado

Cassandra dispone de lo que se denomina un Rich Data Model es decir un sistema eficiente y simple para la ejecución de consultas a la base e datos.

Elasticidad

Te permite leer y escribir simultáneamente sin interrupciones.

Requerimientos de Cassandra

Servidor Apache, 1Gb. de mínimo de memoria RAM bajo entornos virtualizados, si el hardware es dedicado debería ser superior a 4Gb. de todas formas es habitual encontrarse cluster con 16 y 32 Gb. de memoria RAM.

A nivel de CPU Cassandra trabaja de forma excelente con sistemas multi-núcleo así que a mayor número de cores, mayor rendimiento. Así pues si precisas de un gran rendimiento, no te cortes y tira por sistemas de cuatro u ocho núcleos.

Capacidad de disco, ideal 2 discos por cada cluster, en uno se almacena el llamado CommitLogDirectory o fichero de registro de activicidad (log) y en el otro los datos o DataFileDirectories.

Sistema operativo, lo mejor un sistema operativo de 64bits, a mayor estabilidad mejor rendimiento. Por supuesto, Unix o Linux, incluído Mac OSX.

Enlace: http://incubator.apache.org/cassandra/

Páginas relacionadas con este artículo:

1. Motor de base de datos MYSQL
2. Optimizar bases de datos Mysql
3. Cambiar clave root a Mysql por línea de comandos Windows

Hoy hemos recibido la noticia, triste noticia, de que Oracle ha obtenido la aprobación de la Unión Europea para la compra de Sun Microsystems por 7.000 millones de dólares, (4.930 millones de euros). Sun es el propietario del lenguaje de programación Java y  de MYSQL.

Mysql es el motor de base de datos libre por excelencia, libre en cuanto a que no se trata de un sistema propietario, uno puede descargarse el instalador determinado para su plataforma, existiendo para casi la totalidad de sistemas operativos y utilizarlo en sus proyectos sin tener que pagar ni rendir cuentas a nadie. Con una diferencia abrumadora es el sistema más utilizado en la red. Nosotros por ejemplo lo utilizamos en el 95% de los proyectos que desarrollamos para nuestros clientes.

Si bien hace ya algún tiempo Sun, propietaria del lenguajes de programación Java adquirió el sistema de base de datos MYSQL y lo potenció, es ahora el gigante Oracle uno de los líderes mundiales en cuanto a sistemas de bases de datos propietarias quien ha engullido a Sun.

El pez grande se comió al pequeño, y esta vez han saltado todas las alarmas en la comunidad internet pues la presencia de base de datos MYSQL es enorme y el estilo y saber hacer de Oracle es marcadamente comercial no muy dada a proyectos libres, motivo por el que se teme sobre la continuidad de nuestro preciado motor de base de datos libre.

Probablemente Oracle no realizará ningún movimiento brusco con MYSQL en fechas próximas, cuestión de imagen, pero a buen seguro de forma discreta ahorcará poco a poco los recursos dedicados a Mysql y el progreso de la misma se enlentecerá por si sóla hasta estancarse alejando a este sistema de las prestaciones de los sistemas mayores, sin duda esta compra ha sido una compra inteligente pues Oracle sabe que el futuro está en internet y con la compra de Mysql y el lenguaje Java entra por la puerta grande en mercados muchos más pequeños a los que acostumbra con sus sistemas de bases de datos mayores. Además consigue un arma nueva contra los otros grandes players, Microsoft con su SQL y Google quien seguro que también andaba interesado en MYSQL pues por todos es conocido su interés en comprar fama.

Acciones como la de helpmysql.org (http://helpmysql.org/en/petition) donde trataban de conseguir firmas para evitar la aprobación de la U.E. para la compra de MYSQL no han servido para frenar el poder del capital.

Hoy tan sólo nos queda esperar si bien ya existen nuevas propuestas libres como MariaDB un nuevo motor libre de bases de datos basado en MYSQL 5.1 que podría dar continuidad al proyecto MYSQL bajo un nuevo nombre y un nuevo estadio de libertad. Puedes recopilar información en:

http://askmonty.org/wiki/index.php/Main_Page

Y descargar (de momento sólo para Linux) el motor de la base de datos MariaDB en:

https://code.launchpad.net/maria

Si bien Oracle lo tiene fácil para enterrar a proyectos como MariaDB tan sólo deberá aguantar un poco más el desarrollo de MYSQL hasta que MariaDB muera, porque ¿quién va dar el salto de un sistema de base de datos a otro sin la extensísima documentación, seguridad e integridad de los datos que hoy ofrece Mysql mientres este siga coleteando?

ASí que sin más tras esta triste noticia sólo me pregunto, hasta cuando ofrecerán MYSQL gratis, es una incógnita. Snifff..

Páginas relacionadas con este artículo:

1. Base de datos Cassandra
2. Optimizar bases de datos Mysql
3. Mover grandes bases de datos MYSQL

Antes que acabe este año, vamos allá con un nuevo capítulo de… “Optimizando que es gerundio”

Optimizando que es gerundio

Aquí os copio una configuración del fichero my.cnf en el caso de que su destino sea Linux y my.ini para servidores bajo Windows, este fichero es el responsable de la configuración del servidor MYSQL y desde él podemos ajustar diversos parámetros relacionados con el rendimiento y consumo de recursos del servidor.

La configuración que proponemos deberá adaptarse a las características de cada servidor atendiendo a la capacidad de memoria RAM y al número de procesadores de que se dispone. En el ejemplo vamos a trabajar con un servidor web dedicado, es decir el 100% de su uso está destinado a servir páginas web, no existiendo en él ningún otro servicio activo a excepción del servidor FTP para que los usuarios puedan subir páginas web.

El servidor web objeto de la optimización

El equipo cuyo archivo my.cnf vamos a modificar cuenta con las siguientes características:

• 4Gb. de memoria RAM
• Dos CPUs Intel Xeon 64bits de un único núcleo pero con tecnología HT HyperThreading, es decir, disponemos de un total de 4 CPUs virtuales.
• 2x Discos duros configurados en RAID (Si bien este dato no influye directamente en nuestras modificaciones)

El ficherito my.cnf o my.ini

Para ello vamos a modificar los parámetros de la sección mysqld de este fichero de configuración dejándolo como sigue a continuación:

# The MySQL server
[mysqld]
port        = 3306
socket        = /tmp/mysql.sock
skip-locking
safe-show-database
query_cache_limit = 1M
query_cache_size=128M
#query_cache_size= 32Mb. por cada 1Gb de ram 32 x 4 =128Mb
query_cache_type=1
max_user_connections=400
max_connections=500
interactive_timeout=10
wait_timeout=20
connect_timeout=20
thread_cache_size = 128
key_buffer = 512M
#key_buffer= 128Mb. por cada 1Gb de ram 32 x 4 =512Mb.
join_buffer = 1M
max_connect_errors=20
max_allowed_packet = 16M
table_cache = 1024
record_buffer = 1M
sort_buffer_size = 4M
#sort_buffer_size= 1Mb. por cada 1Gb de ram 32 x 4 =512
read_buffer_size = 4M
#read_buffer_size= 1Mb. por cada 1Gb de ram 32 x 4 =512
read_rnd_buffer_size = 8M
#read_rnd_buffer_size2Mb. por cada 1Gb de ram 32 x 4 =512
thread_concurrency = 2
#numero de CPUs x 2 (si la CPU es de nucleo múltiple multiplica x el número de cores disponibles, ej:1 CPU XEON = 2)
myisam_sort_buffer_size = 64M

Páginas relacionadas con este artículo:

1. Optimizar bases de datos Mysql
2. Instalar Apache 2 PHP 5 MYSQL 5 y Webmin 1.5
3. Error con LOAD DATA LOCAL INFILE en MySql