Eseguire i trigger nello slave per gli eventi Row-based
Contents
Eseguire i trigger nello slave
A partire da MariaDB 10.1.1, è possibile forzare lo slave thread ad eseguire i trigger per gli eventi del binlog row-based.
Questa impostazione dipende dalla variabile globale slave_run_triggers_for_rbr. E' anche possibile specificarla da riga di comando o nel file my.cnf.
I valori possibili sono:
| Valore | Significato |
|---|---|
| NO (Predefinito) | Non invocare i trigger per gli eventi row-based |
| YES | Invocare i trigger per gli eventi row-based, ma non scriverli nel binary log |
| LOGGING | Invocare i trigger pe gli eventi row-based e scriverli nel binary log |
Si noti che se si desidera soltanto usare i trigger con la replica, questa opzione non è necessaria. Ulteriori dettagli, più avanti nella pagina.
Quando utilizzare slave_run_triggers_for_rbr
Background
Normalmente, la replica di MySQL può replicare automaticamente le azioni eseguite dai trigger.
- Quando si utilizza la replica statement-based, il binary log contiene le istruzioni SQL. Gli slave server le eseguono. I trigger vengono eseguiti nel master e su tutti gli slave, in modo indipendente.
- Quando si utilizza la replica row-based, il binary log contiene le modifiche alle righe. Contiene sia le modifiche effettuate direttamente dalle istruzioni SQL, sia quelle effettuate dai trigger che sono stati invocati dalle istruzioni. Gli slave non eseguiranno i trigger.
Caso d'uso
Si potrebbe avere un setup in cui uno slave ha dei trigger che non sono presenti nel master (per esempio se lo slave deve aggiornare delle tabelle riassuntive, o effettuare qualche procedura ETL).
Se si utilizza la replica statement-based, è possibile creare nello slave i trigger necessari. Lo slave eseguirà le istruzioni dal binary log, che attiveranno i trigger.
Vi sono però casi in cui si utilizza la replica row-based. Potrebbe essere perché il master esegue istruzioni non deterministiche, oppure il master potrebbe essere un nodo di un cluster Galera. In questi casi, si desidera che gli eventi row-based invochino i trigger nello slave. Questo è possibile grazie all'opzione slave_run_triggers_for_rbr. Impostandola a YES, lo slave thread SQL invocherà i trigger per gli eventi row-based; impostandola a LOGGING, le modifiche effettuate dai trigger verranno anche scritte nel binary log.
I seguenti triggers vengono invocati:
- L'evento Update_row_event esegue un trigger UPDATE;
- L'evento Delete_row_event esegue un trigger DELETE;
- L'azione attivata dall'evento Write_row_event dipende se l'operazione richiede controlli sulle chiavi esterne:
- quando i controlli sulle FK non sono necessari, l'operazione invoca un trigger DELETE se il record da modificare esisteva in tabella. Dopodiché viene invocato un trigger INSERT.
- quando i controlli sulle FK sono necessari, viene invocato un trigger UPDATE oppure una combinazione di DELETE e INSERT.
Prevenire esecuzioni multiple dei trigger
Vi è una protezione di base per impedire che i trigger vengano eseguiti sia sul master sia sullo slave. Se il master modifica una tabella alla quale sono associati dei trigger, produce degli eventi row-based con il flag "i trigger sono stati invocati per questo evento". Lo slave non invoca alcun trigger per gli eventi con questo flag.
Si veda anche
- Il task in Jira, MDEV-5095.
