Gavin Henry wrote:
----- "Quanah Gibson-Mount"<quanah(a)zimbra.com> wrote:
> --On Tuesday, May 26, 2009 8:35 PM -0700 Howard Chu<hyc(a)symas.com>
>> For example, we may have a cluster of servers in MMR with a pool of
>> 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,
>> the chain overlay active on all of the slaves. Setting
> olcServerMatch on
>> the syncprov and chain overlays would allow things to behave as
>> without needing to create a parallel config tree just for the
> 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
> mode). This would allow that. I would note it may be common (I
> do so) to run the syncprov overlay on the replica as well, at least in
> glue'd environment.
> It sounds like it gracefully solves the ability of keeping both master
> replica configurations around for the most part. What still remains
> is ACLs. There are plenty of valid reasons for the master to have
> 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...)
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/