Depuración de MySQL Triggers

Question

Me encantan los factores desencadenantes por una razón: simplemente funcionan. Odio los desencadenantes por una razón: cuando no funcionan, olvídate de intentar depurar. Oh la dulce frustración

Básicamente, quiero ver LA consulta de actualización, eliminación, inserción, etc. que se ejecutó. Quiero ver esa consulta ... en algún lugar, en mi terminal o en un registro, exactamente cómo y cuándo MySQL lo ejecuta, y posiblemente cualquier salida/error correspondiente. Pensamientos/hacks?

Estoy intentando depurar una consulta de actualización con algunas combinaciones y lo que no. Mis consultas son mucho más complejas, pero para abreviar, he aquí un ejemplo.

DELIMITER | 
CREATE TRIGGER ireallyhateyourightnow AFTER UPDATE ON watch_this_table 
FOR EACH ROW BEGIN 
IF (OLD.my_value != NEW.my_value) THEN 
    update 
    my_table 
    set 
    my_column = NEW.my_value; 
END IF; 
END| 
DELIMITER ; 

Aquí hay un contexto adicional que puede ayudar a influir en una sugerencia o respuesta. Una vez más, estoy menos interesado en la semántica/sintaxis y más interesado en ver a MySQL ejecutar la consulta, pero, por supuesto, estoy abierto a cualquier cosa en este momento.

• Strace no funciona/muestra la consulta.
• Entorno no replicado PERO si los registros de bin muestran declaraciones de desencadenante, ciertamente voy a configurar esto.
• ¿Muestra "show full processlist" muestra la ejecución del disparador y/o las sentencias ejecutadas dentro (nunca las veo después de ejecutar show full processlist tan rápido como perl puede ejecutarlo pero me podría estar perdiendo)?
• El registro de consulta general no muestra estas consultas (ciertamente no el registro de errores).
• No estoy usando alias (nunca más).
• Sin errores de sintaxis al crear el desencadenador.
• La instrucción IF funciona.
• Cuando inserto los NUEVOS valores en una tabla "prueba/temperatura" y ejecuto manualmente la consulta de actualización, funciona (incluso llegué a insertar toda la consulta de actualización)
• No puedo mostrar usted la consulta, pero como acabo de mencionar, funciona cuando corro manualmente si eso ayuda.
• He eliminado todos los caracteres erróneos, pestañas, retornos de carro, nuevas líneas, etc.
• El socket de MySQL solo mostraría conexión/datos locales, pero no el funcionamiento interno de MySQL, creo.
• Los registros de MyISAM so INNODB no son una opción
• Parece que lsof no mostró ninguna otra utilidad.
• Estoy usando MySQL 5.0.77 en CentOS 5.5.

Answer 1

Puede debug triggers usando dbForge Studio for MySQL. Prueba la versión de prueba.

Hay una descripción detallada del proceso de depuración de desencadenantes en la documentación: Depuración \ Depuración de rutinas almacenadas \ Cómo: Iniciar la depuración de desencadenadores.

Answer 2

MYSQL PROCEDURE => incron => tail -f 'mysql_dynamic.log'

un procedimiento almacenado se puede invocar dentro de un gatillo, pero no debe devolver ningún

CREATE PROCEDURE `DYN_LOG` (IN s VARCHAR(500)) 
BEGIN 
SELECT s into outfile '/var/spool/incron/mysql_dynamic_spool/foo_file'; 
DO SLEEP(.1); // create a gap beetween multiple shuts 
END 

Ahora en cualquier lugar de un disparador puede invocar

CREATE TRIGGER `trig_name` BEFORE UPDATE ON `tb_name` 
FOR EACH ROW 
BEGIN 
CALL DYN_LOG(concat_ws('\t',NEW.col1,NEW.col2)); 
... 
// rest of the code 
END 

para máquinas Linux apt-get install incron(debian incron tutorial)

Crea la carpeta en la que mysql inyectará foo_file

mkdir -m 777 /var/spool/incron/mysql_dynamic_spool 
incrontab -e 

y añadir siguiente trabajo incron

/var/spool/incron/mysql_dynamic_spool IN_CREATE /path/foo_file_procesor $@/$# 

crear un script ejecutable "/ ruta/foo_file_procesor"

#!/bin/sh 
# // $1 is the foo_file absolute addres 
body="$(cat $1)" // read file content 
rm $1 
log=/var/log/mysql_dynamic.log // message collector 
echo "`date "+%y%m%d %H:%M:%S"`\t== dyn_log ==\t$body">>$log 
exit 0 

Ahora observa el archivo colector

tail -f /var/log/mysql_dynamic.log 

Answer 3

Hay an alternate way of testing it by having a temporary debug table. En el ejemplo aquí, lo crean en una propia base de datos debug.

Paso 1: Crear una tabla

DROP TABLE IF EXISTS debug; 
CREATE TABLE debug (
    proc_id varchar(100) default NULL, 
    debug_output text, 
    line_id int(11) NOT NULL auto_increment, 
    PRIMARY KEY (line_id) 
) 

Paso 2: Crear SP depuración para llenar la tabla de depuración

DELIMITER $$ 

DROP PROCEDURE IF EXISTS `debug_insert` $$ 
CREATE PROCEDURE `debug_insert`(in p_proc_id varchar(100),in p_debug_info text) 
begin 
    insert into debug (proc_id,debug_output) 
    values (p_proc_id,p_debug_info); 
end $$ 

DROP PROCEDURE IF EXISTS `debug_on` $$ 
CREATE PROCEDURE `debug_on`(in p_proc_id varchar(100)) 
begin 
    call debug_insert(p_proc_id,concat('Debug Started :',now())); 
end $$ 

DROP PROCEDURE IF EXISTS `debug_off` $$ 
CREATE PROCEDURE `debug_off`(in p_proc_id varchar(100)) 
begin 
    call debug_insert(p_proc_id,concat('Debug Ended :',now())); 
    select debug_output from debug where proc_id = p_proc_id order by line_id; 
    delete from debug where proc_id = p_proc_id; 
end $$ 

Paso 3: invocar el SP de depuración en su gatillo

Me gusta,

CREATE PROCEDURE test_debug() 
begin 
declare l_proc_id varchar(100) default 'test_debug'; 
    call debug_on(l_proc_id); 
    call debug_insert(l_proc_id,'Testing Debug'); 
    call debug_off(l_proc_id); 
end $$ 

Como resultado, la tabla de depuración se llenaría de la siguiente manera,

+------------------------------------+ 
| debug_output      | 
+------------------------------------+ 
| Debug Started :2006-03-24 16:10:33 | 
| Testing Debug      | 
| Debug Ended :2006-03-24 16:10:33 | 
+------------------------------------+