The setting is controlled by the slave_run_triggers_for_rbr global variable. It can be also specified as a command-line option or in my.cnf.
Possible values are:
|NO (Default)||Don't invoke triggers for Row-based events|
|YES||Invoke triggers for Row-based events, don't log their effect into the binary log|
|LOGGING||Invoke triggers for Row-based events, and log their effect into the binary log|
Note that if you just want to use triggers together with replication, you most likely don't need this option. Read below for details.
Normally, MySQL's replication system can replicate trigger actions automatically.
One may want to have a setup where a slave has triggers that are not present on the master (Suppose the slave needs to update summary tables or perform some other ETL-like process).
If one uses statement-based replication, they can just create the required triggers on the slave. The slave will run the statements from the binary log, which will cause the triggers to be invoked.
However, there are cases where you have to use row-based replication. It could be because the master runs non-deterministic statements, or the master could be a node in a Galera cluster. In that case, you would want row-based events to invoke triggers on the slave. This is what the
slave_run_triggers_for_rbr option is for. Setting the option to
YES will cause the SQL slave thread to invoke triggers for row based events; setting it to
LOGGING will also cause the changes made by the triggers to be written into the binary log.
The following triggers are invoked:
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.
© 2019 MariaDB
Licensed under the Creative Commons Attribution 3.0 Unported License and the GNU Free Documentation License.