[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

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

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 Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP: