FB8-48: Option to run triggers on slave for row-based events #946
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
laurynas-biveinis
suggested changes
Feb 1, 2019
| Table_map_log_events. | ||
| */ | ||
| if (!thd->variables.sql_log_bin_triggers) { | ||
| for (TABLE_LIST *tables = m_lex->query_tables; tables; |
There was a problem hiding this comment.
Suggested change
| for (TABLE_LIST *tables = m_lex->query_tables; tables; | |
| for (auto *tables = m_lex->query_tables; tables; |
inikep
force-pushed
the
FB8-48
branch
7 times, most recently
from
dec4934 to
b84ea47
Compare
|
PR is ready for a 2nd review. All comments except |
percona-ysorokin
approved these changes
Feb 4, 2019
inikep
force-pushed
the
FB8-48
branch
3 times, most recently
from
df178de to
f1c349a
Compare
inikep
changed the title
There was a problem hiding this comment.
@hermanlee has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
hermanlee
approved these changes
Feb 7, 2019
|
@inikep has updated the pull request. Re-import the pull request |
|
Conflicts were resolved and the commit was rebased. |
JIRA: https://jira.percona.com/browse/FB8-48 This patch ports the following commits: 1. facebook@8225c64 2. facebook@f5466d6 3. facebook@87e3650 ================================ facebook@8225c64 ================================ Option to run triggers on slave for row-based events Summary: Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. Test Plan: mtr tests =============================== facebook@f5466d6 ================================ optionally disable binlogging while executing triggers Summary: Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Test Plan: mtr tests ================================ facebook@87e3650 ================================ Another attempt to fix rpl.rpl_unsafe_statements Summary: The rpl.rpl_unsafe_statements test was added in 5.6.29 and when we rebased to 5.6.35 it started causing a problem with the diff "optionally disable binlogging while executing triggers". This is an attempt to modify that diff to work correctly for this case. Squash with: facebook@cdeb012 fbshipit-source-id: facebook@87e3650
|
@inikep has updated the pull request. Re-import the pull request |
|
The commit was rebased and conflicts were solved. |
There was a problem hiding this comment.
@hermanlee has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
facebook-github-bot
pushed a commit
that referenced
this pull request
Mar 8, 2019
Summary: JIRA: https://jira.percona.com/browse/FB8-48 Reference Patch: 8225c64 Reference Patch: f5466d6 Reference Patch: 87e3650 Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. optionally disable binlogging while executing triggers Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Pull Request resolved: #946 Reviewed By: lth Differential Revision: D13972562 Pulled By: lth fbshipit-source-id: e543a50
facebook-github-bot
pushed a commit
that referenced
this pull request
Nov 18, 2019
Summary: JIRA: https://jira.percona.com/browse/FB8-48 Reference Patch: 8225c64 Reference Patch: f5466d6 Reference Patch: 87e3650 Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. optionally disable binlogging while executing triggers Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Pull Request resolved: #946 Test Plan: mtr Reviewed By: lth Differential Revision: D13972562 Pulled By: lth fbshipit-source-id: 123f0f2
hermanlee
pushed a commit
to hermanlee/mysql-5.6
that referenced
this pull request
Oct 18, 2023
…k#946) (facebook#946) Summary: JIRA: https://jira.percona.com/browse/FB8-48 Reference Patch: facebook@8225c64 Reference Patch: facebook@f5466d6 Reference Patch: facebook@87e3650 Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. optionally disable binlogging while executing triggers Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Pull Request resolved: facebook#946 Reviewed By: lloyd Differential Revision: D13972562 Pulled By: lth
inikep
pushed a commit
to inikep/percona-server
that referenced
this pull request
Apr 15, 2024
…#946) (percona#946) Summary: JIRA: https://jira.percona.com/browse/FB8-48 Reference Patch: facebook/mysql-5.6@8225c64 Reference Patch: facebook/mysql-5.6@f5466d6 Reference Patch: facebook/mysql-5.6@87e3650 Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. optionally disable binlogging while executing triggers Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Pull Request resolved: facebook/mysql-5.6#946 Reviewed By: lloyd Differential Revision: D13972562 Pulled By: lth
inikep
pushed a commit
to inikep/percona-server
that referenced
this pull request
Apr 16, 2024
…#946) (percona#946) Summary: JIRA: https://jira.percona.com/browse/FB8-48 Reference Patch: facebook/mysql-5.6@8225c64 Reference Patch: facebook/mysql-5.6@f5466d6 Reference Patch: facebook/mysql-5.6@87e3650 Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. optionally disable binlogging while executing triggers Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Pull Request resolved: facebook/mysql-5.6#946 Reviewed By: lloyd Differential Revision: D13972562 Pulled By: lth
inikep
pushed a commit
to inikep/percona-server
that referenced
this pull request
Apr 17, 2024
…#946) (percona#946) Summary: JIRA: https://jira.percona.com/browse/FB8-48 Reference Patch: facebook/mysql-5.6@8225c64 Reference Patch: facebook/mysql-5.6@f5466d6 Reference Patch: facebook/mysql-5.6@87e3650 Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. optionally disable binlogging while executing triggers Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Pull Request resolved: facebook/mysql-5.6#946 Reviewed By: lloyd Differential Revision: D13972562 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Apr 23, 2024
…k#946) (facebook#946) Summary: JIRA: https://jira.percona.com/browse/FB8-48 Reference Patch: facebook@8225c64 Reference Patch: facebook@f5466d6 Reference Patch: facebook@87e3650 Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. optionally disable binlogging while executing triggers Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Pull Request resolved: facebook#946 Reviewed By: lloyd Differential Revision: D13972562 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Apr 25, 2024
…k#946) (facebook#946) Summary: JIRA: https://jira.percona.com/browse/FB8-48 Reference Patch: facebook@8225c64 Reference Patch: facebook@f5466d6 Reference Patch: facebook@87e3650 Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. optionally disable binlogging while executing triggers Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Pull Request resolved: facebook#946 Reviewed By: lloyd Differential Revision: D13972562 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 7, 2024
…k#946) (facebook#946) Summary: JIRA: https://jira.percona.com/browse/FB8-48 Reference Patch: facebook@8225c64 Reference Patch: facebook@f5466d6 Reference Patch: facebook@87e3650 Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. optionally disable binlogging while executing triggers Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Pull Request resolved: facebook#946 Reviewed By: lloyd Differential Revision: D13972562 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 8, 2024
…k#946) (facebook#946) Summary: JIRA: https://jira.percona.com/browse/FB8-48 Reference Patch: facebook@8225c64 Reference Patch: facebook@f5466d6 Reference Patch: facebook@87e3650 Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. optionally disable binlogging while executing triggers Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Pull Request resolved: facebook#946 Reviewed By: lloyd Differential Revision: D13972562 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 9, 2024
…k#946) (facebook#946) Summary: JIRA: https://jira.percona.com/browse/FB8-48 Reference Patch: facebook@8225c64 Reference Patch: facebook@f5466d6 Reference Patch: facebook@87e3650 Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. optionally disable binlogging while executing triggers Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Pull Request resolved: facebook#946 Reviewed By: lloyd Differential Revision: D13972562 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 10, 2024
…k#946) (facebook#946) Summary: JIRA: https://jira.percona.com/browse/FB8-48 Reference Patch: facebook@8225c64 Reference Patch: facebook@f5466d6 Reference Patch: facebook@87e3650 Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. optionally disable binlogging while executing triggers Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Pull Request resolved: facebook#946 Reviewed By: lloyd Differential Revision: D13972562 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 13, 2024
…k#946) (facebook#946) Summary: JIRA: https://jira.percona.com/browse/FB8-48 Reference Patch: facebook@8225c64 Reference Patch: facebook@f5466d6 Reference Patch: facebook@87e3650 Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. optionally disable binlogging while executing triggers Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Pull Request resolved: facebook#946 Reviewed By: lloyd Differential Revision: D13972562 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 15, 2024
…k#946) (facebook#946) Summary: JIRA: https://jira.percona.com/browse/FB8-48 Reference Patch: facebook@8225c64 Reference Patch: facebook@f5466d6 Reference Patch: facebook@87e3650 Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. optionally disable binlogging while executing triggers Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Pull Request resolved: facebook#946 Reviewed By: lloyd Differential Revision: D13972562 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 16, 2024
…k#946) (facebook#946) Summary: JIRA: https://jira.percona.com/browse/FB8-48 Reference Patch: facebook@8225c64 Reference Patch: facebook@f5466d6 Reference Patch: facebook@87e3650 Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. optionally disable binlogging while executing triggers Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Pull Request resolved: facebook#946 Reviewed By: lloyd Differential Revision: D13972562 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 17, 2024
…k#946) (facebook#946) Summary: JIRA: https://jira.percona.com/browse/FB8-48 Reference Patch: facebook@8225c64 Reference Patch: facebook@f5466d6 Reference Patch: facebook@87e3650 Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. optionally disable binlogging while executing triggers Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Pull Request resolved: facebook#946 Reviewed By: lloyd Differential Revision: D13972562 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 21, 2024
…k#946) (facebook#946) Summary: JIRA: https://jira.percona.com/browse/FB8-48 Reference Patch: facebook@8225c64 Reference Patch: facebook@f5466d6 Reference Patch: facebook@87e3650 Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. optionally disable binlogging while executing triggers Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Pull Request resolved: facebook#946 Reviewed By: lloyd Differential Revision: D13972562 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 21, 2024
…k#946) (facebook#946) Summary: JIRA: https://jira.percona.com/browse/FB8-48 Reference Patch: facebook@8225c64 Reference Patch: facebook@f5466d6 Reference Patch: facebook@87e3650 Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. optionally disable binlogging while executing triggers Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Pull Request resolved: facebook#946 Reviewed By: lloyd Differential Revision: D13972562 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 30, 2024
…k#946) (facebook#946) Summary: JIRA: https://jira.percona.com/browse/FB8-48 Reference Patch: facebook@8225c64 Reference Patch: facebook@f5466d6 Reference Patch: facebook@87e3650 Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. optionally disable binlogging while executing triggers Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Pull Request resolved: facebook#946 Reviewed By: lloyd Differential Revision: D13972562 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jun 12, 2024
…k#946) (facebook#946) Summary: JIRA: https://jira.percona.com/browse/FB8-48 Reference Patch: facebook@8225c64 Reference Patch: facebook@f5466d6 Reference Patch: facebook@87e3650 Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. optionally disable binlogging while executing triggers Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Pull Request resolved: facebook#946 Reviewed By: lloyd Differential Revision: D13972562 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jun 13, 2024
…k#946) (facebook#946) Summary: JIRA: https://jira.percona.com/browse/FB8-48 Reference Patch: facebook@8225c64 Reference Patch: facebook@f5466d6 Reference Patch: facebook@87e3650 Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. optionally disable binlogging while executing triggers Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Pull Request resolved: facebook#946 Reviewed By: lloyd Differential Revision: D13972562 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jun 14, 2024
…k#946) (facebook#946) Summary: JIRA: https://jira.percona.com/browse/FB8-48 Reference Patch: facebook@8225c64 Reference Patch: facebook@f5466d6 Reference Patch: facebook@87e3650 Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. optionally disable binlogging while executing triggers Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Pull Request resolved: facebook#946 Reviewed By: lloyd Differential Revision: D13972562 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jun 19, 2024
…k#946) (facebook#946) Summary: JIRA: https://jira.percona.com/browse/FB8-48 Reference Patch: facebook@8225c64 Reference Patch: facebook@f5466d6 Reference Patch: facebook@87e3650 Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. optionally disable binlogging while executing triggers Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Pull Request resolved: facebook#946 Reviewed By: lloyd Differential Revision: D13972562 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jun 20, 2024
…k#946) (facebook#946) Summary: JIRA: https://jira.percona.com/browse/FB8-48 Reference Patch: facebook@8225c64 Reference Patch: facebook@f5466d6 Reference Patch: facebook@87e3650 Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. optionally disable binlogging while executing triggers Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Pull Request resolved: facebook#946 Reviewed By: lloyd Differential Revision: D13972562 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jun 21, 2024
…k#946) (facebook#946) Summary: JIRA: https://jira.percona.com/browse/FB8-48 Reference Patch: facebook@8225c64 Reference Patch: facebook@f5466d6 Reference Patch: facebook@87e3650 Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. optionally disable binlogging while executing triggers Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Pull Request resolved: facebook#946 Reviewed By: lloyd Differential Revision: D13972562 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jun 25, 2024
…k#946) (facebook#946) Summary: JIRA: https://jira.percona.com/browse/FB8-48 Reference Patch: facebook@8225c64 Reference Patch: facebook@f5466d6 Reference Patch: facebook@87e3650 Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. optionally disable binlogging while executing triggers Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Pull Request resolved: facebook#946 Reviewed By: lloyd Differential Revision: D13972562 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jul 2, 2024
…k#946) (facebook#946) Summary: JIRA: https://jira.percona.com/browse/FB8-48 Reference Patch: facebook@8225c64 Reference Patch: facebook@f5466d6 Reference Patch: facebook@87e3650 Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. optionally disable binlogging while executing triggers Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Pull Request resolved: facebook#946 Reviewed By: lloyd Differential Revision: D13972562 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jul 19, 2024
…k#946) (facebook#946) Summary: JIRA: https://jira.percona.com/browse/FB8-48 Reference Patch: facebook@8225c64 Reference Patch: facebook@f5466d6 Reference Patch: facebook@87e3650 Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. optionally disable binlogging while executing triggers Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Pull Request resolved: facebook#946 Reviewed By: lloyd Differential Revision: D13972562 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jul 19, 2024
…k#946) (facebook#946) Summary: JIRA: https://jira.percona.com/browse/FB8-48 Reference Patch: facebook@8225c64 Reference Patch: facebook@f5466d6 Reference Patch: facebook@87e3650 Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. optionally disable binlogging while executing triggers Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Pull Request resolved: facebook#946 Reviewed By: lloyd Differential Revision: D13972562 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jul 31, 2024
…k#946) (facebook#946) Summary: JIRA: https://jira.percona.com/browse/FB8-48 Reference Patch: facebook@8225c64 Reference Patch: facebook@f5466d6 Reference Patch: facebook@87e3650 Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. optionally disable binlogging while executing triggers Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Pull Request resolved: facebook#946 Reviewed By: lloyd Differential Revision: D13972562 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Aug 2, 2024
…k#946) (facebook#946) Summary: JIRA: https://jira.percona.com/browse/FB8-48 Reference Patch: facebook@8225c64 Reference Patch: facebook@f5466d6 Reference Patch: facebook@87e3650 Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. optionally disable binlogging while executing triggers Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Pull Request resolved: facebook#946 Reviewed By: lloyd Differential Revision: D13972562 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Aug 6, 2024
…k#946) (facebook#946) Summary: JIRA: https://jira.percona.com/browse/FB8-48 Reference Patch: facebook@8225c64 Reference Patch: facebook@f5466d6 Reference Patch: facebook@87e3650 Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1. When using statement based replication slave executes the sql statments which runs the slave side triggers. Since in row based replication, slave applies the row events directly to the storage engine, triggers on the slave table are not executed. Add functionality to run triggers on slave side when executing row based events. The following triggers are invoked: * 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: 1) 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. 2) when FK checks are necessary, either an UPDATE or or a combination of DELETE and INSERT triggers will be invoked. slave_run_triggers_for_rbr option controls the feature. Default value is NO which don't invoke trigger for row-based events; 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. 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. optionally disable binlogging while executing triggers Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other. disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables. With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave. Pull Request resolved: facebook#946 Reviewed By: lloyd Differential Revision: D13972562 Pulled By: lth
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
JIRA: https://jira.percona.com/browse/FB8-48
Reference Patch: 8225c64
Reference Patch: f5466d6
Reference Patch: 87e3650
Summary:
Port the slave_run_triggers_for_rbr feature from mariadb 10.1.1.
When using statement based replication slave executes the sql statments
which runs the slave side triggers. Since in row based replication, slave
applies the row events directly to the storage engine, triggers on the slave
table are not executed. Add functionality to run triggers on slave side
when executing row based events.
The following triggers are invoked:
to be modified existed in the table. After that, an INSERT trigger will be invoked.
DELETE and INSERT triggers will be invoked.
slave_run_triggers_for_rbr option controls the feature.
Default value is NO which don't invoke trigger for row-based events; 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.
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.
optionally disable binlogging while executing triggers
Online schema change (OSC) creates triggers only on master side. Since RBR logs row changes made by triggers, sql_thread will hit errors due to missing tables on slaves. Add a session variable SQL_LOG_BIN_TRIGGERS to optionally disable binlogging for trigger statements so that RBR and OSC are fine with each other.
disable_sql_log_bin_triggers flag is added in the TABLE_LIST struct to track tables that are opened during trigger execution. This flag is used to skip writing Table_map_log_events for such tables.
With sql_log_bin_triggers enabled, the trigger changes which may be necessary for slave are not propagated. To avoid this, slave_run_triggers_for_rbr option must be enabled on slave.
Test Plan: mtr