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

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



On Thu, 2017-03-02 at 16:49 -0800, Quanah Gibson-Mount wrote:
> --On Thursday, March 02, 2017 10:36 PM +0000 mberg@synacor.com wrote:
> 
> > I'm not sure if there is any guard against writing an older
> > contextCSN
> > than is currently stored, but this could theoretically rewind the
> > stored contextCSN on A if there is any latency in replication from
> > B.
> 
> Older contextCSNs will be ignored.  And it is accurate to then have
> a contextCSN for each server in the system.  That was part of the
> initial problem in 8281.  I still see no evidence of incorrect
> behavior. ;)

I'm well aware that there will be a contextCSN for each SID in the
system.  The questionable part was the apparent overwriting of the
contextCSN on another server.  I seem to be unable to reproduce that
today, so I'm not sure if I fat-fingered something.

However there would seem to be a couple possibilities here:

  1) The contextCSN written as an accesslog entry is read by the other
     server and applied, which would be wrong since it should represent
     the most recent entryCSN seen for that SID, or

  2) The contextCSN written as an accesslog entry is read by the other
     server and ignored, which would waste IOPS and increase latency, 
     or

  3) The contextCSN written as an accesslog entry has some non-obvious
     function, and replicas reading from the active master would be at
     a disadvantage since these entries are only being written on the
     passive master.

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).
This message and any attachment may contain information that is confidential and/or proprietary. Any use, disclosure, copying, storing, or distribution of this e-mail or any attached file by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please notify the sender by reply email and delete the message and any attachments. Thank you.