Bug #97721 preserve replication filters from config file through startup/configuration
Submitted: 20 Nov 2019 21:24 Modified: 19 Oct 2020 7:18
Reporter: Trey Raymond Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: Replication Severity:S4 (Feature request)
Version:8.0 OS:Any
Assigned to: CPU Architecture:Any
Tags: replication filter

[20 Nov 2019 21:24] Trey Raymond
Description:
[feature request]
current implementation for channel-specific repl filters will discard filters in the config file on initial startup, causing a subsequent CHANGE MASTER/START SLAVE to fail.
ref https://dev.mysql.com/worklog/task/?id=7361
this is a problem re order of operations - startup must complete, including handling everything in my.cnf, before any CHANGE MASTER can possibly be run.  so, to use this feature, someone/something must go parse the config file externally and inject some CHANGE REPLICATION FILTER... statements between CHANGE MASTER and START SLAVE while an instance is being configured.

How to repeat:
install mysql
have at least one channel-based repl filter defined in my.cnf
start mysql
run change master to... to configure that channel
show slave status, observe filters for that channel are blank
start slave, replication will break (worst case would be a missed ignore which caused data loss, but in most cases it will just break immediately)

Suggested fix:
Ideally, an instance would be able to start up and configure itself without those extra steps and risk - i.e. all filters in my.cnf will be preserved at runtime, and if a channel is initialized with change master, it will be aware of its assigned filters.  storing filter info which is temporarily 'orphaned' from a channel doesn't seem harmful in any way.
[19 Oct 2020 7:18] MySQL Verification Team
Hello Trey Raymond,

Thank you for the feedback and feature request!

Thanks,
Umesh