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.