MDEV-38243 Write binlog row events for changes done by cascading FK operations - #5521
Open
sjaakola wants to merge 3 commits into
Open
MDEV-38243 Write binlog row events for changes done by cascading FK operations#5521sjaakola wants to merge 3 commits into
sjaakola wants to merge 3 commits into
Conversation
…perations This commit implements a feature which changes the handling of cascading foreign key operations to write the changes of cascading operations into binlog. The applying of such transaction, in the slave node, will apply just the binlog events, and does not execute the actual foreign key cascade operation. This will simplify the slave side replication applying and make it more predictable in terms of potential interference with other parallel applying happning in the node. This feature can be turned ON/OFF by new variable: rpl_use_binlog_events_for_fk_cascade, with default value OFF The actual implementation is largely by windsurf. The commit has also mtr tests for testing rpl_use_binlog_events_for_fk_cascade feature: rpl.rpl_fk_cascade_binlog_row, rpl.rpl_fk_set_null_binlog_row and rpl.fk_cascade_binlog_row_rollback
…perations Fixes according to Kristian Nielsen's review: * Removed obsolete checks for slave thread * Supporting slave with old MariaDB version. Events logged in cascade operation are additionally flagged with the long-standing NO_FOREIGN_KEY_CHECKS_F, so a replica that does not understand FK_CASCADE_EVENTS_F still disables foreign key checks and does not re-execute the cascade Also, thee are now binlog event flags to mark both original and derived events. This will make it possible for the slave to choose whether to use the derived events in applying or to execute the cascade operation There is a new test rpl.rpl_fk_cascade_binlog_row_old_slave, for checking compatibility with replication slave of old mariadb version
…perations Refactoring according to Serg's review. In this version, SE/server API now narrows the SE role to just report the changes done by foreign key cascading, and server side does most of the work after that. Added a design document MDEV-38243-design.md
sjaakola
force-pushed
the
MDEV-38243-new_API
branch
from
August 11, 2026 05:20
e605a59 to
c1f5097
Compare
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
This commit implements a feature which changes the handling of cascading foreign
key operations to write the changes of cascading operations into binlog.
The applying of such transaction, in the slave node, will apply just the binlog
events, and does not execute the actual foreign key cascade operation.
This will simplify the slave side replication applying and make it more predictable
in terms of potential interference with other parallel applying happning
in the node.
This feature can be turned ON/OFF by new variable:
rpl_use_binlog_events_for_fk_cascade, with default value OFF
Since the original version, this PR has changes after two reviews, by Kristian and Serg, mainly to:
Events logged in cascade operation are additionally flagged with
the long-standing NO_FOREIGN_KEY_CHECKS_F, so a replica that does
not understand FK_CASCADE_EVENTS_F still disables foreign key checks
and does not re-execute the cascade
and server side does most of the work after that.