La gente de Sun ha publicado una guía muy interesante sobre escalamiento y replicación para MySQL. Se trata de un PDF que nos explica qué es el escalamiento, la replicación en MySQL, los tipos de escalamiento, el Linux Heartbeat y los cluster, entre otras cosas.
Guía: Escalamiento de MySQL para negocios de alto crecimiento
Gracias David por el aviso
MONyog es un monitor web de MySQL, que nos permite identificar problemas MySQL de forma rápida y sencilla. Se trata de una aplicación que monitoriza el servidor MySQL y lo muestra con servidor web independiente que nos muestra muchos datos de nuestra, localizado en el puerto 9999, sin poder seleccionar el que queramos.
Entre las opciones que nos ofrece encontramos información general de la BD, historial de conexiones, caché Innodb, logs Innodb, caché de querys, tablas y threats, querys lentas, tráfico de red y muchas cosas más.
MONyog
Muy buen truco para crear un túnel SSH a un servidor MySQL y asà poder usar el administrador de MySQL como si fuera en localhost, permitiendo asà las opciones que añade para conexiones en local.
Para realizarlo es necesaria la aplicación PuTTY, un cliente Telnet/SSH gratuito, y el MySQL Administrator, aunque por lo que he entendido es válido para cualquier acceso a la BD.
Lo que conseguimos con el túnel SSH es acceder a una dirección, en este caso la 127.0.0.1:3306 (el puerto por defecto de MySQL en la máquina a la que accedemos), mediante un nuevo puerto (en el ejemplo el 8600). AsÃ, cuando queramos acceder como si fuera localhost pero en un servidor remoto, tan solo deberemos acceder a 127.0.0.1:8600 desde el MySQL Administrator.
Securing the connection between MySQL and MySQL Administrator using an SSH tunnel
VÃa / Digg
Buena noticia de rendimiento en la futura versión de MySQL. En este caso se trata de las consultas anidadas dentro de MySQL, pongamos un ejemplo.
Si tenemos esta consulta:
select title, from_date, to_date
from titles
where emp_no in
(select emp_no
from employees
where first_name = 'Mary'
and last_name = 'Sluis'
)En MySQL5 (usando estos datos) obtendríamos el resultado (1 fila) en 7.88 segundos, mientras que en MySQL6 tardaría 0.13 segundos.
El motivo parece ser que MySQL transforma la subconsulta en un join.
Un truco que no conocía y que me puede venir muy bien (y espero que a vosotros). Se trata de ejecutar scripts de MySQL muy extensos (provenientes de un dump, por ejemplo) sin que nos dé el problema del tamaño máximo del fichero a subir.
El truco es sencillo, nos creamos una carpeta donde subimos el fichero con los scripts, y a la hora de importar, seleccionamos el “Web server upload directory”, para lo que habrá que modificar el fichero de configuración (config.inc.php) para indicar el directorio de uploads (UploadDir).
Execute large MySQL scripts through phpMyAdmin
MAMP es un instalador de Apache, MySQL y PHP para Mac OS X sencillo y que con unos pocos clicks ya tenemos instaladas las aplicaciones más habituales para desarrollo web.
La versión está realizado bajo licencia GNU General Public License, aunque existe una versión PRO, con licencia, que dispone de funcionalidades extra.
MAMP
Unas opciones no muy usadas cuando se trabaja con MySQL son los triggers y los procedimientos almacenados (stored procedures), supongo que a que es algo nuevo en MySQL y la gente no está acostumbrada a estas dos funcionalidades.
Vamos a mostrar un ejemplo de uso de triggers y procedimientos almacenados paso a paso. Quizás el ejemplo no sea el más correcto, o simplemente sea poco útil, pero lo importante es el uso en sÃ, no el ejemplo.
Nuestro sistema tendrá dos tablas, una con ventas y la otra con comisiones. En la primera se almacenarán cada venta que se realiza en un comercio, y en la segunda las comisiones que le corresponden a cada vendedor en el momento.
CREATE TABLE `ventas` ( `vendedor` int(11), `producto` int(11), `importe` float ) CREATE TABLE `comisiones` ( `vendedor` int(11), `comision` float )
Las comisiones se calcula de una forma especial, le corresponde un porcentaje de las ventas según el tipo de producto, y es importante para los vendedores el que se sepa en cada momento qué comisiones lleva ganadas (esto es una justificación para no usar un cron o algo parecido).
Para calcular qué comisión le corresponde a un vendedor, calcularemos los porcentajes para cada tipo de producto vendido y luego lo añadiremos/actualizaremos en la tabla de comisiones. Todo se realizará en un procedimiento almacenado.
DELIMITER $$ DROP PROCEDURE IF EXISTS `test`.`sp_comisiones`$$ CREATE PROCEDURE `test`.`sp_comisiones` (IN mivendedor INT) BEGIN DECLARE micomision INT DEFAULT 0; DECLARE suma INT; DECLARE existe BOOL; select IFNULL(sum(importe),0) into suma from ventas where producto = 1 and vendedor = mivendedor; SET micomision = micomision + (suma * 0.15); select IFNULL(sum(importe),0) into suma from ventas where producto = 2 and vendedor = mivendedor; SET micomision = micomision + (suma * 0.1); select IFNULL(sum(importe),0) into suma from ventas where producto = 3 and vendedor = mivendedor; SET micomision = micomision + (suma * 0.2); select count(1)>0 into existe from comisiones where vendedor = mivendedor; if existe then UPDATE comisiones set comision = comision+micomision where vendedor = mivendedor; else insert into comisiones (vendedor, comision) values (mivendedor, micomision); end if; END$$ DELIMITER ;
Ahora, para actualizar los datos de las comisiones usaremos un trigguer, asà cuando se haga una venta (insert en la tabla ventas), se llamará al procedimiento almacenado (sp_comisiones), que recalculará la comisión para ese vendedor.
DELIMITER $$ DROP TRIGGER `test`.`tr_ventas_insert`$$ CREATE TRIGGER `test`.`tr_ventas_insert` AFTER INSERT on `test`.`ventas` FOR EACH ROW BEGIN call sp_comisiones(new.vendedor); END$$ DELIMITER ;