[MDEV-22327] Feature request: replicate_do_engine/replicate_ignore_engine Created: 2020-04-21  Updated: 2023-07-11

Status: Open
Project: MariaDB Server
Component/s: Replication
Fix Version/s: None

Type: Task Priority: Major
Reporter: Hartmut Holzgraefe Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Duplicate
Relates
relates to MDEV-19964 S3 replication support Closed

 Description   

When using remote table engines, like FEDERATEDX or CONNECT, usually one wouldn't want to have master side changes to be replicated to slaves, as these would just lead to duplicate actions on the remote tables by default.

In edge cases though, where e.g. CONNECTION parameters for CONNECT tables on the slave side have been altered to point to different servers than on the master, replication for such tables may actually be wanted though.

Right now this could only be solved by using replicate_do/ignore_table rules, and having a consistent table naming scheme that would allow for CONNECT tables to be easily identified, or by adding per-table rules one by one.

So I'd request to be able to outright ignore CONNECT or FEDERATEDX tables by default, by having a new filter like

replicate_ignore_engine=CONNECT,FEDERATEDX

This would obviously be a ROW-only filter.

 Comments   
Comment by Hartmut Holzgraefe [ 2022-02-18 ]

DDL for CONNECT, FEDERATED and the likes should still be replicated, only DML needs to be filtered indeed as that is already replicated otherwise.

So my request indeed looks similar to s3_slave_ignore_updates, just in a more general form that handles this on the server level for all potentially affected engines.

Comment by Andrei Elkin [ 2023-02-06 ]

ralf.gebhardt, hholzgra: while the proposed one is a generalization of an existing replicate_do_... let me first comment on how the desired effect can be achieve with a bit different user interface. That is a new option to Change-Master can trigger the desired filtering and already on the master side.
The new Change-Master's option would be passed to the actual master at handshake time so in the following
it would watch over specifically marked events.

As a crude idea, could not master actually always compute *on its own* what Connect/Federated table events to filter out?
After all the master is aware of both: the tables' hosts and slave hosts. Of course a slave may placehold a certain set of tables while being a user
of another set which makes the slave interested in a selective automated

{if possible}

filtering.

ralf.gebhardt, to your questions, sure the task is doable and there seems to be more than 1 approach how to.
To any existing 'hard coded engine' filters - we don't have. But we have a "soft" s3_slave_ignore_updates one which also may serve as a pattern to follow (or be refactored, hopefully replaced by the automatic policy mentioned above.

Generated at Thu Feb 08 09:13:54 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.