Re: (ITS#8607) Second master in MMR config logging contextCSN changes to accesslog

[quanah@symas.com]

--On Friday, March 03, 2017 9:57 PM +0000 quanah@symas.com wrote:

> Your context for points 1-3 are invalid as the entire issue was around
> N-way MMR (and their individual serverID contextCSNs) so non-master
> replicas are beside the point.  In addition, a correct setup via the most
> recent tools would include replicas pulling from all masters, vs a single
> master.  So there is no replica only pulling from an "active" or
> "passive"  master in a correct setup.  Replicas pull from *all* masters
> when deployed  correctly.  See also
> <https://bugzilla.zimbra.com/show_bug.cgi?id=95200>

For background on ITS#8281, the context was:

2 (or more) MMR nodes fully populated with X number of entries.

Add a new MMR node (with no database populated)

While the MMR node is in REFRESH mode, stop/start slapd on that node.  The 
interuption in the REFRESH phase results in the DB not fully replicating 
(Stopped at the point in which slapd was stopped).  This is clearly 
described in the initial report, where only 625/15000 users got replicated 
due to stopping slapd.  The discussion about what to do when there's no 
contextCSN generated yet on a new system, where it is single 
master/consumer was an orthogonal but related discussion, in relation to 
the value of generating a contextCSN at startup or not.

--Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>