Gavin Henry wrote:
----- "Quanah Gibson-Mount"quanah@zimbra.com wrote:
--On Tuesday, May 26, 2009 8:35 PM -0700 Howard Chuhyc@symas.com wrote:
For example, we may have a cluster of servers in MMR with a pool of
other
servers operating as slaves. We'd want the syncprov overlay active
on all
of the masters, the syncrepl consumer active on all of the servers,
and
the chain overlay active on all of the slaves. Setting
olcServerMatch on
the syncprov and chain overlays would allow things to behave as
desired,
without needing to create a parallel config tree just for the
slaves.
Comments?
I like it. One thing we've needed to do in the past is drop the replication configuration portions of a master (taking it to single-server mode). This would allow that. I would note it may be common (I certainly do so) to run the syncprov overlay on the replica as well, at least in a glue'd environment.
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.
Agreed, it's still not a perfect solution for ACLs and such. Although you could use servermatch on the database itself, and have two separate olcDatabase entries, one for the master and one for the slave. That would also allow you to use separate indexing on the master vs the slaves.
I agree with Quanah too. Would these be a 2.5 features?
If we can get it working right away, no, I'd release it into 2.4 ASAP since we have an immediate need for this ability. Of course, it may not be a candidate for 2.4.17 - we need to focus on stability there still. (Moving the syncrepl consumer into an overlay would not happen in 2.4...)