On Apr 28, 2009, at 2:39 PM, Devananda vdv wrote:
However, if drizzle were pulling (via a plugin) its config from a central source, it also needs to be able to handle local changes (eg, SLAVE STOP)? On restart, drizzle needs to know that the slave thread should still be stopped, so any "remote config container plugin" needs to cache local changes locally. This leads me to agree that it should also keep track of where each (nondefault) config option was set.
I don't see "STOP SLAVE" as configuration, so much as state that probably should be saved along with master log file/position/etc. The evolved mysql behavior of suppressing starting by adding 'skip-slave- start' is just a little clumsy because of its history.
This is why its great to get replication out of the "kernel" of drizzle and into its own process. I'm struggling to think of any other need to keep and reproduce state that isn't already in the realm of storage engines.
Whether config data lives in a local config cache pulled from HTTP servers backed by a database, or a memory table loaded from a file.. as long as you can't push changes into the global runtime configs without updating the stored configs, it makes system management very simple and the code very straight forward.
Here's something to chew on though. Plugins need to be configured.. so configuring the configuration plugin should be as *simple* as possible. To avoid having 16 different my.cnf files that might get read (<ahem>), one or two command line arguments should be enough to get configuration loaded. Something like '--config-plugin=url_config -- config-args=http://confighost/configs'. and then that plugin defines the behaviors from there. Maybe the default value would be the drizzle_cnf plugin...
_______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
