Tamaño de Campos Blob en MySQL

Tenía la necesidad de poder saber cuanto pesaban los datos que se estaban guardando en un campo blobs para poder dimensionar y controlar el tamañao que iba a tener mi tabla en el futuro. 

Para esto encontré la siguiente consulta:

select length(NombreCampoBlob) as byte from Tabla;

Esta consulta me tira en bytes el tamaño de mi campo.

Table storage engine for "MiTabla" doesn't have this option... migrando MySQL

Estoy migrando una KB de GeneXus 9.0 a GeneXus 15 por lo que aproveche a realizar un rediseño de la aplicación y cambiando todo lo que se pueda. Aprovechando me instale una versión nueva de MySQL para dejar de usar la 5.1 que tenía funcionando en producción. Para esto hice un dump como lo hago siempre y al querer levantar el archivo me da el siguiente error: "Table storage engine for punc.examenodontologico doesn't have this option..."

Buscando en google encontré que el problema se debe al ROW_FORMAT que se estaba usando en la creación de las tablas.

"ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_general_cs ROW_FORMAT=FIXED;" 

La solución es cambiar el valor del ROW_FORMAT=DYNAMIC

"ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_general_cs ROW_FORMAT=FIXED;" 

Con esto pude levantar mi dump sin problemas, dado que el sistema tiene muchas tablas hice el replace usando el "VI" que es el editor que uso. La sentencia en VI es muy sencilla:

":%s/ROW_FORMAT=FIXED/ROW_FORMAT=DYNAMIC/g"

Dejo este pique por si les pasa ya que yo por distraído perdí un buen rato antes de poder resolverlo.

Respaldar Bases de datos en MySQL

Existen varias formas de realizar respaldos de bases de datos MySQL por lo que pueden existir mil sitios en donde se pueda encontrar información del estilo.

En lo personal estaba programando un backup y tuve que comenzar a hacer un script para que se encargara de respaldar las bases de datos aparte de mandar un mail en caso de fallo y otras cosas básicas de cualquier respaldo.

Lo que hice fue buscar en internet y encontré un Script llamado AutoMySQLBackup, el script se puede bajar del siguiente sitio: http://sourceforge.net/projects/automysqlbackup/

Algunas de las cosas interesantes:

- Respalda una o todas las bases de datos que se necesiten.
- Reporta por mail el resultado de ejecución del script
- Se pueden disparar otros scripts antes o después de ejecutar el respaldo.
- Ejecuta backups, diarios, semanales, mensuales, etc.

Lo principal es que nos ahorra un montón de trabajo y es muy sencillo de modificar para adaptarlo a nuestras necesidades.

Replicación en MySQL Parte I

Desde hace un tiempo vengo manejando servidores con Replica pero no los había tenido que configurar ya que el cliente tenía un DBA que se encargaba de esas cosas. Hace unos días tuve que configurar mi primer replica con mysql y comencé a meterme en el tema. La verdad que es mucho más sencillo de lo que pensaba, hay que tener en cuenta que esta es un replica sencilla en donde tengo un servidor master y otro slave. La necesidad de tener un servidor de replica se debe a que el cliente quiere tener alta disponibilidad y en caso de fallos una alternativa rápida para seguir operativos. Me toco configurar una réplica sencilla ya que toda transacción que se hace en el master se copia en el slave, esta es la réplica más sencilla que puede existir y nos provee de un servidor alternativo en caso de que falle el master.
A continuación hago un resumen muy pero muy breve de lo que hice para tener un servidor con Replica en MySQL.
Para poder configurar mi servidor de replica tengo que hacer lo siguiente:
Configuración servidor MASTER:
1) Editar el my.cnf
log-bin=/var/lib/mysql/mysql-bin.log
binlog-do-db=test
server-id = 1

2) Bajar y Subier el mysql

3) Entro en el shell de mysql para darle permisos al usuario que voy a utilizar para la réplica.
mysql> GRANT REPLICATION SLAVE ON *.* TO usr_replica@'%' IDENTIFIED BY 'password_replica';
mysql> FLUSH PRIVILEGES;

4) Entro en el shell de mysql para consultar el estado del Master
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 | 106 | test | |
+------------------+----------+--------------+------------------+
Estos datos son importantes para luego poder configurar el SLAVE.

5) mysqldump -u root -ppassword --opt test>test.sql

Configuración servidor SLAVE:
En el esclavo lo primero que tengo que hacer es copiar la estructura de la base de datos a replicar, existen varias formas de hacerlo pero para el ejemplo preferí hacerlo de la forma más sencilla. En el ejemplo estamos replicando solo la base de datos test por lo que usando un simple dump podemos preparar el servidor esclavo para la réplica.
1) Levanto el test.sql que generamos en el Master en el SLAVE, esto lo hago simplemente con un source o de la forma que se prefiera. Hay que tener en cuenta que la base debe existir o la tenemos que crear, en este ejemplo uso la test que viene con mysql y en el test.sql traigo la estructura que tiene el master que simplemente es una tabla para las pruebas.
2) Tengo que indicarle al servidor que es slave por lo que tengo que editar el my.cnf con los siguientes datos:
server-id=2
master-host=192.168.248.136
master-user=usr_replica
master-password=password_replica
master-connect-retry=106
replicate-do-db=test
Estos datos los saco del master tal cual se muestra arriba. Después de modificar el my.cnf debo hacer un stop y start del servicio mysql.

3) Entro en el shell de mysql y hago lo sigiuente:
mysql> CHANGE MASTER TO MASTER_HOST='192.168.248.136', MASTER_USER='usr_replica', MASTER_PASSWORD='password_replica', MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=106;

4) Dentro del shell lo que hago es inicializar el esclavo con el siguiente comando:
mysql> START SLAVE;

Con esta configuración todo dato que se modifique en la base de datos test del servidor master se replicara en la base de datos test del slave.

MySQL InnoDB y Raw Devices

Estamos trabajando en un proyecto bastante grande y uno de los principales temas a tratar son los de performance. Por un lado estamos teniendo mucho cuidado en tratar de que los programas queden óptimos aparte de prestar mucho cuidado a la utilización de índices y todo lo que ayude a que los programas tengan una buena performance.

Del punto de vista de GeneXus tenemos todo bajo control pero en ocasiones los proyectos son tan grandes que también hay que prestar mucha atención al hardware sobre el cual se va a montar la aplicación y también al “tunning” que se le haga al DBMS.

En la mayoría de los casos no tengo la oportunidad de dedicarme al “tunning” del DBMS pero en este caso quise hacerlo ya que vamos a utilizar MySQL y nos entregaron un servidor con la instalación por defecto.

Lo primero que hice fue actualizar la versión de MySQL ya que el servidor tenía MySQL 5.0 por lo que me baje el rpm para RedHat de la 5.1.28. Desinstale la versión 5.0 mediante rpm y levante la versión nueva.

Tenía un disco de 408 GB para el MySQL por lo que decidí utilizar raw devices para montar los innodb, la idea era crear un Tablespace de 408 GB para MySQL. Lamentablemente después de probar varias veces si creaba un solo archivo de 408 GB se me partía y no me levantaba el servicio, por cuestiones de tiempo no pude investigar mucho mas por lo que decidí crear 4 raw devices de 95 GB cada uno y tener 4 innodb.

Tuve que tocar el my.cnf con todos los parámetros que pongo habitualmente para trabajar con innodb solo que cambie la parte de innodb_data_file_path para montar los raw devices.


Actualmente el my.cnf lo tengo así:

innodb_data_file_path = /dev/raw/raw1:95Graw;/dev/raw/raw2:95Graw;/dev/raw/raw3:95Graw;/dev/raw/raw4:95Graw

Lo interesante fue que tuve que particionar el disco y crear los raw devices, a pesar de mi nick no soy experto en linux por lo que tuve que apoyarme en mi amigo “google” para poder cumplir esta tarea.

Las particiones las hice con fdisk y me quedo de la siguiente manera:
Device Boot Start End Blocks Id System
/dev/sdb1 1 12405 99643131 83 Linux
/dev/sdb2 12406 24808 99627097+ 83 Linux
/dev/sdb3 24809 37214 99651195 83 Linux
/dev/sdb4 37215 49605 99530707+ 83 Linux

Para crear los raw devices tuve que hacer lo siguiente:
Editar el /etc/udev/rules.d/60-raw.rules y escribir las siguientes líneas:

ACTION=="add", KERNEL=="sdb1", RUN+="/bin/raw /dev/raw/raw1 %N"
ACTION=="add", KERNEL=="sdb2", RUN+="/bin/raw /dev/raw/raw2 %N"
ACTION=="add", KERNEL=="sdb3", RUN+="/bin/raw /dev/raw/raw3 %N"
ACTION=="add", KERNEL=="sdb4", RUN+="/bin/raw /dev/raw/raw4 %N"

Editar el archivo /etc/udev/rules.d/ 41-local-permissions-rules y agregar las siguientes líneas:

KERNEL=="sdb1" GROUP="mysql"
KERNEL=="sdb2" GROUP="mysql"
KERNEL=="sdb3" GROUP="mysql"
KERNEL=="sdb4" GROUP="mysql"

El problema que tuve es que al re-iniciar el equipo los raw devices quedaban con el owner root por lo que MySQL no tenía permisos para usarlos. Después de unos minutos sin encontrar una solución elegante lo que hice fue emplear una solución desprolija pero que funciono. :-)

Edite el archivo /etc/init.d/mysql en donde agregue las siguientes líneas:

chown mysql /dev/raw/raw1
chown mysql /dev/raw/raw2
chown mysql /dev/raw/raw3
chown mysql /dev/raw/raw4

No se si la solución es la mas elegante pero quedo funcionando y pude seguir adelante.


Una vez que tuve los raw creados y con permisos para mysql lo que hice fue modificar el my.cnf de la siguiente manera:

innodb_data_file_path = /dev/raw/raw1:95Gnewraw;/dev/raw/raw2:95Gnewraw;/dev/raw/raw3:95Gnewraw;/dev/raw/raw4:95Gnewraw

El newraw le indica a mysql que tiene que crear el espacio de tablas por lo que una vez que tenemos el my.cnf configurado alcanza con bajar y subir el servicio mysql para que me cree el espacio de datos en los raw devices que se le indicarón.

Una vez que mysql termino hay que modificar el my.cnf para que quede de la siguiente manera:

innodb_data_file_path = /dev/raw/raw1:95Graw;/dev/raw/raw2:95Graw;/dev/raw/raw3:95Graw;/dev/raw/raw4:95Graw

Un consejo es que cuando mysql esta creando el espacio de tables nos da un Failed pero sigue trabajando por lo que una forma que tenemos de saber si todavía se encuentra trabajando es hacer un ls –l /dev/raw/ esto me tira lo siguiente:

crw------- 1 mysql root 162, 1 Oct 12 18:16 raw1
crw------- 1 mysql root 162, 2 Oct 13 11:12 raw2
crw------- 1 mysql root 162, 3 Oct 13 11:30 raw3
crw------- 1 mysql root 162, 4 Oct 13 11:49 raw4
En mi caso como el tamaño de los innodb era de 95 GB al levantar mysql después de 5 minutos me daba un Failed pero seguía trabajando y la forma que tuve de saber en que iba era haciendo el ls para consultar la hora de modificación. Un experto seguramente tenga otros métodos pero no es mi caso.

Con esto tenemos mysql utilizando particiones crudas como se dice habitualmente.