• Esta version en desarrollo tiene un error que conforme al uso le hace consumir ingentes cantidades de memoria al punto de esperar segundos solo para mover una tabla dentro del diagrama (en diagramas con muchas tablas).
• No puedes abrir tu proyecto con la version estable lo que te obliga a continuar con la version beta.
• No puedes imprimir ni exportar diagramas como PDF, PNG o JPG (error que se espera corregir en la siguiente version).

Entonces estas como yo.

Para el problema del abuso de memoria RAM tendremos que esperar a que encuentren y corrigan este problema (o conseguirte una buena tarjeta grafica si cuentas con una desktop).

Pero para exportar tus diagramas si hay un metodo que puedes utilizar hasta que llegue la siguiente version.

Una vez que tengas en diagrama abierto, en la barra de menu entra al menu Scripting > Scripting Shell. Luego, elige la ficha Modules y veras lo siguiente:

Exportando a PNG utilizando Scripting Shell

Esta herramienta tan util de MySQL Workbench nos permite ejecutar sentencias desde la linea de comandos. Desde aqui podemos hacer todo (o casi todo).

Una vez alli ejecutamos el siguiente comando para volcar nuestro diagrama visible a un archivo PNG:

Workbench:exportPNG(ruta de la imagen a crear entre comillas)

Puedes indagar y ejecutar otros comandos. Lamentablemente no he encontrado documentacion sobre la funcion y los argumentos de estos metodos. La funcion se puede adivinar con el nombre pero la descripcion de argumentos es muy vaga (string en el caso de exportPNG podria ser cualquier cosa, en su caso se trata de la ubicacion de la imagen a crear).

Encontre esta solucion gracias al comentario de Roland Firmont en http://bugs.mysql.com/bug.php?id=52909.

Actualizacion

Este problema ya se ha corregido con el lanzamiento de la version 5.2.20.

Entradas posiblemente relacionadas con este post:

1. Mejoras en Google

Pues al parecer el problema surge al momento de instatar mysql-server (sudo apt-get install mysql-server usando ubuntu) que al crear los archivos ibdata# e ib_logfile# estos se crean con los permisos erroneos. Lo mas intrigante es que mysql no informa de este problema al iniciarse.

Entonces, el problema se resuelve asi:

Primero, debes detener mysql y lo haces con el siguiente comando:

sudo service mysql stop

Luego, dirigete al siguiente directorio:

cd /var/lib/mysql

Ejecuta ls para ver los archivos del directorio:

Resultado de ls en /var/lib/mysql/

Ahora saca una copia de los archivos ibdata# e ib_logfile#. El signo # es porque pueden haber mas de uno. La copia la realizas de la siguiente forma:

//cp _archivo_original archivo_copia
cp ibdata0 ibdata0.bak
cp ib_logfile0 ib_logfile0.bak

Luego borra los archivos ibdata# e ib_logfile# originales. Lo haces de esta manera:

//rm _archivo1 archivo2 archivo3
rm ibdata0 ibdata1 ibdata2 ib_logfile0 ib_logfile1 ib_logfile2

Ahora arrancas mysql:

sudo service mysql start

Puedes verificar que InnoDB esta activado desde phpMyAdmin o conectandote a MySQL desde la terminar:

mysql -u root -h localhost -p
password: *********
show engines;

Esta es una extensión a la explicación del siguiente post How To Fix: InnoDB has been disabled for this MySQL server.

Entradas posiblemente relacionadas con este post:

1. Configurando un gateway de red con Ubuntu
2. Como exportar diagramas con MySQL Workbench 5.2.19b

Esto sucedía porque la configuración de fábrica que usa MySQL esta diseñada para un uso general. Si vamos a usar esa base de datos en producción debemos reducir sus restricciones.

Para esto es de suponer que el servidor cuenta con unos 4Gb de RAM y un procesador decente (preferible procesadores).

Como no puedo apagar mi servidor hago los cambios en caliente simplemente ejecutando una par de sentencias.

SET GLOBAL max_connections = 800;
SET GLOBAL innodb_thread_concurrency = 500;

Donde max_connections es el numero maximo de conexiones simultaneas que el servidor va a permitir y innodb_thread_concurrency las concurrencias (para las tablas innodb). Yo coloque estos numeros sin un analisis previo, pero me resultaron. Siempre monitoreo el consumo de recursos en mi base de datos. La consecuencia de subir estos los límites es que el servidor va a aceptar y procesar mas consultas.
Debes encontrar un balance entre la cantidad de peticiones que puedes recibir y la velocidad de respuesta. Para ello ten en cuenta la capacidad de tu hardware y el grado de uso de tu servidor. Es diferente si solo vas a almacenar nombres de paises o realizar una mineria de datos. Para el primer caso la concurrencia de tu servidor podria ser grande pero las consultas muy simples y por tanto el tiempo de respuesta para estas consultas simples seria muy corto.

Son cientos los parametros que puedes usar para tunear tu base de datos. Tienes aqui una lista de los parametros (comentados) que puedes modificar en MySQL. Ten mucho cuidado con las modificaciónes que realizas.

Entradas posiblemente relacionadas con este post:

1. Como exportar diagramas con MySQL Workbench 5.2.19b