I wonder what the best way is to get a feature request more visibility (convert a feature request to an actual work item).
We use replicate-do-db on all our slave servers , so after many, many, restarts of our slave servers, I checked the bug list for any feature requests surrounding this, and about 6 months ago, one was opened:
replicate-* rules should be dynamically configurable
Sadly, there does not appear to be a work log for it, nor any targeted version. It seems to me that it's probably a fairly common use case...
I suppose adding or removing a db from the replicate list, might require restarting the slave processes that scan binlogs for transactions to apply, or at least, some way to notify the slave processes that additional databases need to be accounted for. Then we have to make sure that we start at the right point in the binlog, right? (what if the database as been active for a while, and then I try to dynamically add it to the replicate list)
There is a worklog item for having the master filter the database replication (to reduce network traffic), which has a proposed option of allowing this to be dynamic through the use of a CHANGE MASTER command. That might work for the dynamic replicate-* rules as well...
Maybe this is an opportunity to open my MySQL Internals book, and see if I can pull those C programming skills out of my cobweb filled dba brain...
Anyway - it would be interesting to know who all out there would like this as a feature...
1 comment:
Really, now that MySQL is being used for serious things, there is really no excuse for any configuration change to require a restart of mysqld.
I hope all new features being designed have this goal in mind, and that eventually all of the important settings (such as this one, but also more critical ones too) can be tweaked on the fly.
Post a Comment