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:
- Update_row_event runs an UPDATE trigger
- Delete_row_event runs a DELETE trigger
- Write_row_event action depends on whether the operation will require foreign key checks:
- when FK checks are not necessary, the operation will invoke a DELETE trigger if the record to be modified existed in the table. After that, an INSERT trigger will be invoked.
- when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked.
Preventing multiple trigger invocations
There is a basic protection against triggers being invoked both on the master and slave. If the master modifies a table that has triggers, it will produce row-based binlog events with the "triggers were invoked for this event" flag. The slave will not invoke any triggers for flagged events.
See also
- Task in Jira, MDEV-5095.
