La Query Cache nos permite almacenar el resultado de las query SELECT en una cache, de forma que si se piden los mismos datos repetidamente, únicamente tendrá que ejecutarlo una vez, devolviendo el resto de veces el resultado desde la memoria. Esto, como os podeis imaginar, mejora en gran medida el rendimiento de nuestro servidor. Pero hay que tener una serie detalles en cuenta al hacer uso de esta cache :)

• Para mantener la consistencia en los resultados guarda una relación de las tablas a las cuales afectan la query, de forma que si una de esas tablas se ve modificada, la Query Cache se invalida.
• La query se guarda tal y como la hemos escrito, esto es, para la Cache no sería lo mismo "SELECT Nom,Ap from t where id=2" que "SELECT nom,ap from T where id=2".
• No se guardará el resultado de la query a no ser que esta no sera determinista. Por lo tanto, funciones como NOW(), CURRENT_DATE(), …

CALENDARIO DE CURSOS MAYO-JULIO 2010 – ZARAGOZA Warp Networks como partner oficial de Sun Microsystems, imparte formación certificada MySQL y JAVA. También puede proveer a los interesados de vouchers para certificaciones Sun. Los cursos se imparten de forma presencial en Zaragoza. Apúntate ahora, las plazas son limitadas! FORMACIÓN JAVA: Desarrollo de Aplicaciones Java EE (FJ-310-EE5): [...]

Si no me equivoco desde junio del año pasado Sun Microsystems ha pasado sus certificaciones de MySQL de PearsonVUE a Prometric. Justo antes de ese cambió aprobé la certificación de MySQL DBA. Y ahí comienza el infierno, como siempre protagonizada por los departamentos de atención al cliente.

Me cree una cuenta en Prometric para poder seguir con mi formación (MySQL Cluster) y me extrañé un poco al ver que no recibía ningún correo. Pero no me preocupé mucho, ya que podía entrar con mi cuenta y comprobar que funcionaba correctamente. Envié un correo a Prometric comentando que mi certificación estaba en el limbo, necesitaba que la moviesen a Prometric para poder hacer MySQL Cluster (MySQL DBA es un requisito). Pasaron los días y no recibí nada. Finalmente, después de días de espera, me dio por mirar los logs de mi servidor de correo y veo:

NOQUEUE: reject: RCPT from promailer.prometric.com[208.76.122.11]: 
450 4.7.1 …

Rocky prefiere la replicación en Access

La replicación de bases de datos síncronas siempre ha dado algún que otro quebradero de cabeza ya que no es tan facil de implementar como en un principio se puede pensar. Una de las técnicas más usadas para lograrlo es el conocido commit en dos fases. En este modo un nodo llamado el coordinador envía un mensaje con una consulta a un commit. Los participantes, en función de si pueden o no aplicar la transacción, mandan una respuesta de fallo o acierto al coordinador. Si alguno manda fallo, la transacción se cancela (rollback) pero si todos dan su visto bueno esta se aplica globalmente (commit).

Esto a simple vista ya nos muestra un problema de base, la gran cantidad de bloqueos que se tienen que aplicar a las tablas y/o filas mientras se hacen las comprobaciones, degradando en gran medida el …

Acepto comentarios, puedo estar equivocado :)

• El tipo datetime ocupa 8 bytes y no es timezone-aware. Timestamp ocupa la mitad (4 bytes) y es timezone-aware. Usa timestamp.
• El tipo varchar es más lento que char, pero generalmente ocupa menos espacio. Antes de definir la columna piensa que datos se van a guardar. Si son de tamaño fijo (o muy muy similares) usa char (por ejemplo para un md5).
• Si tu charset es UTF-8, es posible que el string ocupe hasta el tripe de espacio. Usa UTF-8 solamente donde sea necesario.
• Si en un campo varchar o char vas a guardar siempre los mismos strings, usa enum.
• Si no necesitas decimales exactos, usa tipos de coma flotante (float o double). El tipo decimal no lo calcula la CPU (no puede), lo hace MySQL, lo cual es muchisimo más lento.
• Todas las columnas deben ser NOT NULL. Procesar un NULL consume CPU y memoria. Si quieres que los campos se …

Abierta la inscripción para el curso MySQL 5.1 para administradores de bases de datos. En este curso un instructor autorizado MySQL te enseñará como instalar MySQL, crear y ejecutar estrategias de backup, crear procedimientos almacenados de forma segura, y mucho más. Además, el curso incluye la preparación para obtener el Certified MySQL 5.0 DBA. El [...]

Últimamente me ha dado por aprender Python o al menos intentarlo. Nunca me ha gustado la programación y cada vez que leía orientación a objetos terminaba dejándolo por puro aburrimiento. Espero que esta ocasión sea diferente :) Lo mejor que le veo a Python es su sintaxis sencilla y la cantidad brutal de módulos que podemos usar para hacernos la vida más facil.

En este simple ejemplo mostraré como acceder a MySQL y hacer querys, facil y para toda la familia. El primer requisito es tener MySQLdb instalado.

apt-get install python-mysqldb

El código es muy sencillo. Asociamos una conexión con un cursor y realizamos las querys contra el.

import MySQLdb
db=MySQLdb.connect(unix_socket="/tmp/mysql_sandbox5140.sock", user="root", 
passwd="msandbox",db="information_schema")
h=0
cursor=db.cursor()
sql="SELECT PLUGIN_NAME, PLUGIN_VERSION, PLUGIN_DESCRIPTION from plugins;"
cursor.execute(sql)
for n in cursor.fetchall(): …

Otro de los problemas que nos podemos encontrar en una replicación es la red. Si esta está congestionada o con desconexiones intermitentes podemos terminar teniendo graves como lag entre maestro y esclavos o la parada completa del esclavo. Últimamente me he encontrado con este problema en algunas instalaciones de replicación y los síntomas no ayudaban a conocer la causa. Conectándome al esclavo y ejecutando el típico show slave status no encontraba la razón por la cual la replicación se habia parado. Los dos procesos, IO y SQL estaban funcionando y Seconds Behind Master indicaba 0.

Cuando el esclavo pide los últimos logs al maestro, se queda esperando un tiempo para recibir la respuesta hasta que al final da timeout. Eso es un comportamiento normal, lo que ya no es normal es el valor por defecto de dicha espera, 3600 segundos, ¡una hora! El esclavo se quedará en el estado:

Slave_IO_State: Waiting for master …

Aquí os pongo unas nuevas transparencias de un curso que he dado recientemente. Abarca gran cantidad de temas relacionados con la administración de nuestra base de datos favorita :)

• Instalación
• Engines
• Optimización de consultas
• Optimización de tablas
• Optimización del servicio
• Usuarios y permisos
• Replicación
• Alta disponibilidad
• Backup
• etc. :)

Espero que os guste y os sea de utilidad. Cualquier sugerencia o crítica es bienvenida. Si hay algún fallo comentádmelo para solucionarlo lo antes posible.

¡Gracias a todos!

Mysql AdministracionView more presentations from …

A la hora de configurar una replicación, el punto más importante es aquel en el que decidimos que replicar. Y para ello debemos seleccionar que guardar en el log binario. Tenemos muchas opciones, pero hay algunas que debemos evitar:

• binlog-do-db
• binlog-ignore-db
• replicate-do-db
• replicate-ignore-db

Para ver la razón, nada mejor que un ejemplo practico de un sistema master-master.

El servidor A tiene dos bases de datos, VIDA y MUERTE. VIDA será la que se replicará al segundo maestro.

El servidor B solo tiene la base de datos VIDA.

Servidor A:

server-id=101
log-bin=mysql-bin
log-slave-updates
replicate-same-server-id=0
auto_increment_increment=2
auto_increment_offset=1
binlog-do-db=vida

Servidor B:

server-id=102
log-bin=mysql-bin
log-slave-updates
replicate-same-server-id=0
auto_increment_increment=2
auto_increment_offset=2 …