2014-05-08 12 views
7

In base allo MySQL Performance Blog, i nuovi server Percona, annunciati ieri (6 maggio), includono entrambi la versione open source del plugin di controllo MySQL.Quali tabelle sono state interessate durante una singola query eseguita da trigger in cascata

L'attività che si desidera eseguire è: registrare le tabelle interessate dall'esecuzione del trigger a cascata durante una singola esecuzione della query di aggiornamento. Per esempio. quando viene eseguito UPDATE MY_TABLE …, i trigger {BEFORE,AFTER}_UPDATE possono aggiornare altre tabelle, su cui potrebbero esserci i propri trigger, ecc.

Attualmente utilizzo la soluzione domestica; all'interno tutto innesca metto smth come:

IF (
     SELECT count(*) 
     FROM `information_schema`.`ROUTINES` 
     WHERE specific_name = 'my_own_log' 
      AND routine_schema = 'my_schema' 
) > 0 THEN 
    CALL my_own_log ('FOO_TRIGGER', 'Hi, I’m to update MY_TABLE') ; 
END IF ; 

Nella produzione non ho la procedura my_own_log definita e poiché la tabella information_schema è ben ottimizzato, non cedere eventuali sanzioni prestazioni.

la domanda è se ho potuto passare alla soluzione aziendale (citato audit plugin) per raccogliere informazioni su un che le tabelle sono state colpite da cascata grilletto esecuzione. JFYI: l'unica domanda simile che ho trovato here non è fornita con una risposta applicabile.

Grazie per eventuali suggerimenti.

risposta

1

Il controllo del plugin è progettato per registrare interazioni esterne con il server, utilizzato per tracciare le intrusioni e altre attività correlate, non le interazioni del server con se stesso (come trigger e procedure).

Queste attività interne non generano azioni su alcun plug-in di controllo in base alla progettazione. Dal blog dev:


http://dev.mysql.com/doc/refman/5.6/en/audit-log-plugin-logging-control.html

Il server MySQL chiama il registro di controllo plugin per scrivere un elemento ogni volta che si verifica un evento verificabile, come ad esempio quando si completa l'esecuzione di un'istruzione SQL ricevuto da un client. In genere il primo elemento scritto dopo l'avvio del server ha la descrizione del server e le opzioni di avvio. Gli elementi che seguono rappresentano eventi come la connessione e la disconnessione del client, le istruzioni SQL eseguite e così via. Vengono registrate solo le istruzioni di livello superiore, non le istruzioni all'interno di programmi memorizzati come trigger o stored procedure. I contenuti dei file referenziati da istruzioni come LOAD DATA INFILE non vengono registrati.


Per ora, si sta meglio con la soluzione homegrown. Potresti provare a migliorare le sue prestazioni in modo da poterlo attivare nell'ambiente di produzione.

+0

Forse queste ruote non erano ancora state inventate. Il tuo requisito è molto insolito. Vedete, dato che i trigger, gli FK ci sono già, dovreste essere in grado di dire le azioni di qualsiasi query prima di eseguirla, solo con l'analisi statica, a meno che non si usi una sorta di percorso d'azione probabilistico per definire i risultati. Quindi è molto insolito non sapere in anticipo dove agiranno le istruzioni DML. – kurast