--On Friday, March 03, 2017 9:36 PM +0000 mberg@synacor.com wrote:

I'm not precisely sure how this relates to 8281, since that seemed to be fixed by not generating an initial contextCSN for newly initialized databases and telling consumers to smeg off if they tried to connect before a contextCSN was written (presumably by a successful REFRESH in a newly initialized MMR provider, or an initial write in a single- master provider).

See http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=cd8ff37629012c1676ef79de164a159da9b2ae89, where the code was clearly modified to push the contextCSN's through where before they were not. The entire issue around ITS#8281 was REFRESH mode in MMR failing if the server was stopped and restarted midstream while doing the refresh, with the wrong CSN value being stored. The changes in ITS#8281 ensure it maintains the correct CSN value internally.

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

--Quanah

--

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