Hallvard B Furuseth wrote:
I ought to try syncrepl before talking too much, but anyway:
Quanah Gibson-Mount writes:
It sounds like it gracefully solves the ability of keeping both master and replica configurations around for the most part. What still remains sticky is ACLs. There are plenty of valid reasons for the master to have very different ACLs than the replicas do.
And things like<authz-policy> and<allow>. Security settings, if you run a master inside a well protected subnet and partial slaves on more open ones.
It would be a mistake to run any servers with lesser security settings than any other server, if all of them are sharing data.
Master and slave can share some but not all databases, and you might want to replicate config of those they share - but this way the database numbers will differ. Might not share all related schema either.
It would most likely be a mistake not to share schema. Of course, there's nothing preventing us from putting ServerMatch on schema entries too. And no, the database numbers would be the same - all of the database configs would be replicated, but some of them would be inactive on various servers.
<threads>, cache settings,<argsfile>, etc. if your servers run on different OSes. Which can be useful so that if an OS-specific problem hits one server, others are in no danger.
Threads, maybe. cache settings, perhaps. argsfile is just a command line parameter, so not relevant. Most of the sites we work with deploy identical hardware for their pools of servers. The most common form of load balancing is round-robin DNS, which is only "fair" if all of the servers are equivalent in their load handling capability.
I'm sure there are good reasons for plenty of other things to differ, while config-replication could still be useful. Depends on how flexible partial config-replication is intended to be.
Since there is currently no support at all, I think it's important to get something usable first, and worry about those other cases later.