--On Friday, March 03, 2017 9:36 PM +0000 [email protected] 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>
