A veces es necesario almacenar una gran cantidad de datos en MySQL, por ejemplo las típicas tablas con los logs del sistema, fichajes de empleados, estadísticas de correo, resultados de encuestas, etc.. Son tablas que aumentan constantemente y que nunca dejarán de hacerlo. Por otro lado son tablas que a pesar de almacenar tantos datos y ocupar tanto espacio no podremos eliminar, ya sea porque son necesarios o porque nuestro jefe sufre el Síndrome de Diógenes. En esos casos, cuya única función es el almacenamiento constante y la consulta esporádica, cosas como integridad referencial o transacciones nos importa bien poco. Lo que nos tiene que preocupar es el tamaño de la tabla y el espacio libre en disco duro.

Para este tipo de almacenamiento existe un engine que nos puede ayudar, Archive:

• Compresión de datos al vuelo según se van introduciendo
• Bloqueo a nivel de fila
• Autoincrementales …

El problema más grave de la replicación en MySQL es su funcionamiento asíncrono. Cuando se añade o modifica algún dato en el master, este commitea los datos en local sin esperar a que los slaves lo hagan. Esto normalmente no supone un gran problema, ya que la replicación, si no hay ningún problema con índices o con la red, es casi instantanea. Pero aún así se pueden dar algunos problemas:

• El master commitea los datos sin esperar. Durante un tiempo, aunque pequeño, master y slave tendrán datos diferentes. Contra mas alto sea el valor seconds behind master, mayor será el problema.

• El master no comprueba que los esclavos hayan recibido los binlogs con los cambios.

• El master no comprueba que los esclavos hayan hecho efectivos los cambios en sus bases de datos.

Este es un problema solucionado en …

Gracias a information_schema es posible saber el tamaño que ocupan las tablas de nuestras bases de datos.

Toda la información que nos ofrece information_schema en relación con las tablas es la siguiente:

mysql> desc tables;
+-----------------+--------------+------+-----+---------+-------+
| Field           | Type         | Null | Key | Default | Extra |
+-----------------+--------------+------+-----+---------+-------+
| TABLE_CATALOG   | varchar(512) | YES  |     | NULL    |       |
| TABLE_SCHEMA    | varchar(64)  | NO   |     |         |       |
| TABLE_NAME      | varchar(64)  | NO   |     |         |       |
| TABLE_TYPE      | varchar(64)  | NO   |     |         |       |
| ENGINE          | varchar(64)  | YES  |     | NULL    |       |
| VERSION         | bigint(21)   | YES  |     | NULL    |       |
| ROW_FORMAT      | varchar(10)  | YES  |     | NULL    |       |
| TABLE_ROWS      | bigint(21)   | YES  |     | NULL    |       |
| …

Os informamos de los cursos públicos JAVA y MySQL, que se van a impartir en el primer semestre de 2010, en 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. FORMACIÓN JAVA EN ZARAGOZA: Desarrollo de aplicaciones con [...]

Para las prácticas haremos uso de una BBDD de prueba que podemos descargar aquí:

Sample database with test suite

Lo bueno de esta BBDD es que ya viene repletita de datos, por ejemplo la tabla salaries tiene en torno a dos millones de registros. La particionaremos de forma que logremos mejorar el rendimiento. Hay que tener en cuenta que las pruebas se van a hacer sobre un Netbook, por lo que los resultados no son 100% fiables. Nunca pongáis un netbook como servidor de bases de datos en producción u os quedareis ciegos.

El particionado se puede hacer por rangos, listas, hashes y keys:

RANGO

CREATE TABLE employees (
    id INT NOT NULL,
    fname VARCHAR(30),
    lname VARCHAR(30),
    hired DATE NOT NULL DEFAULT '1970-01-01',
    separated DATE NOT NULL DEFAULT '9999-12-31',
    job_code INT NOT NULL,
    store_id INT NOT NULL
)
PARTITION BY RANGE …

Desde la versión 5.1 existe la posibilidad de particionar nuestras tablas de forma horizontal (en líneas), algo que nos puede ayudar en casos puntuales a mejorar el rendimiento de nuestra base de datos. Resumiendo, este sistema nos permite dividir lógicamente una tabla muy grande en otras más pequeñas, dentro de un rango de valores que nosotros indiquemos, de forma que la consulta de datos sea más rápida. Su uso es muy sencillo pero... ¿cuando debemos utilizarlo?

• Cuando la tabla sea tan grande que los índices no entren en RAM.
• Cuando tengamos una tabla realmente grande (no hablo de megas).
• Cuando almacenamos datos históricos.
• Cuando queremos rotar datos.
• Cuando los datos no paran de crecer y crecer...

Hay que tener en cuenta que este particionado es totalmente transparente para el usuario (y por lógica también para nuestra aplicación) por lo que en el …

Os presento las transparencias del curso de Replicación de MySQL que acabo de terminar y subir a Slideshare.

Contenido:

Maestro/Esclavo Maestro/Maestro Circular MMM MySQL Proxy

Replicación MysqlView more documents from Miguel Angel Nieto Salazar.

Montar un sistema de replicación es sencillo y rápido. Nos ofrece muchas ventajas, siempre y cuando funcione correctamente y no fallen los equipos. Ahora imagina con las siguientes características:

• Dos equipos en maestro-maestro.
• 50 equipos esclavos, 25 colgando del maestro 1 y otros 25 del maestro 2.

Ahora imagina que el maestro 1 se cae. Bien, recuerda que todo esto está en tu imaginación, no te intentes suicidar, aunque he de admitir que sería la solución mas razonable. Con la caida de ese Master, 25 equipos esclavos se han quedado desincronizados. Tenemos usuarios que ni pueden escribir y lo que leen está posiblemente anticuado. Cuando pones de nuevo el servidor en marcha compruebas que no se replican correctamente ya que alguna transacción quedó a medías. Tienes 26 ordenadores desincronizados y tienes que entrar uno a uno parando el proceso Slave, ejecutando el change_master, arranco de …

La arquitectura Maestro/Maestro es muy sencilla tanto de entender como implementar. Cuando vimos anteriormente Maestro/Esclavo, vimos que el Maestro se utilizaba para escrituras, mientras que en lecturas teníamos N servidores. En ese caso la lectura no es problema, hay suficiente hardware procesando peticiones, pero ¿qué pasa con la escritura?. Según el número de usuarios aumente y la carga de escrituras sea mayor, dicho servidor terminará por no dar a basto ralentizando el buen funcionamiento de nuestras aplicaciones. Maestro/Maestro viene a solucionarnos este problema.

En este caso, H1 y H2 reciben las peticiones de escritura. Los dos deben tener los datos sincronizados, para ello se sigue el siguiente esquema:

• H1 es maestro de H2 (por lo tanto H2 esclavo de H1)
• H2 es maestro de H1 (por lo tanto H1 es esclavo de H2)

De esta forma, todo lo escrito en H1 se replicará a H2 y viceversa. …

La cosa se pone interesante :P

The regulators see a major conflict of interest in the world's largest commercial database company owning its largest open source competitor.

A lo que Oracle responde:

It is well understood by those knowledgeable about open source software that because MySQL is open source, it cannot be controlled by anyone.

MySQL se esta convirtiendo en un problema para Oracle, retrasando infinitamente la fusión que Sun parece necesitar a gritos.

Lo que no deben saber, es que estas cosas se solucionan con un duelo de bailes.

Fuente con más información (que yo estoy vago)