Quote:
Originally Posted by
radoulov
Neo,
I assume these options are static so you could take a dump of the production db (use --master-data), then import the data in the slave, update the rows on the slave with the proper configuration and then start the replication. As far as those rows remain untouched on the master, the slave configuration will remain valid.
Thanks!
That is exactly what I've been doing (manually). The part I wish to avoid is editing the slave each time I upload the masterdump data into the slave.
In addition to the static data, some data is dynamic, and I want the data on the slave and master to remain unique to each other (secondary requirement, not a show stopper).
For example, when replicating this vB forum, static information is, for example, the URL of the forum (they are different in the test environment), and dynamic information is the number of users on the site. This information comes from a table called "datastore" which contains rows with various static configuration / option data and dynamic data, like who is on the site, spiders, number of users on line, etc.
If I replicate the entire datastore table, I have problem when I turn off vB plugins on the slave that remain on on the master. Yes, I can work around by manually updating the configuration on the slave each time; but then if I turn off a plugin (or turn on a dormant one) on the master, it will update the slave, which I don't want.
That's why I was hoping there was some way to just exclude some rows in the datastore table from replicating.
Also, I thought about perhaps instructing the slave to permanently lock the rows so they can't be effected by uploading a dump or master replication.
Maybe that will work?