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

[quanah@symas.com]

--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>