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

[mberg@synacor.com]

Reading back over the report on ITS-8281, the reported behavior would
have been a collision of generating a new contextCSN as well as
duplicating the producer's SID.  So it's generated contextCSN would
have masked the one it never committed from the original master.

However, the point still stands that the contextCSN entry is *not*
being written to the access log by the first server (A) here.  It is
only being written by the second server (B).

So in the scenario that is supposed to be addressed by the fix - a
second MMR node with an uninitialized database is in its initial
refresh, it wouldn't be receiving contextCSN updates through the access
log because they simply aren't there.

To me the logical behaviour would be that a new node would remain
without a recorded contextCSN until it receives the sync cookie along
with the refreshDone message.  Sending an explicit contextCSN update
after every single accesslog entry seems an awfully expensive and
unintuitive approach to fixing a refresh issue.

TL;DR: The objection raised in scenario #3 stands if you are
initializing a new MMR node, since. Or in a single master + replica
scenario.

Or to rephrase, if these entries are intended and necessary, shouldn't
they be generated on the original server as well?
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.