[SERVER-38609] Invalidate sessions that have a retryable write on stepDown instead of stepUp Created: 13/Dec/18  Updated: 03/Jun/19  Resolved: 03/Jun/19

Status: Closed
Project: Core Server
Component/s: Replication, Sharding
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Samyukta Lanka Assignee: Randolph Tan
Resolution: Won't Fix Votes: 0
Labels: gm-ack
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: Sharding 2019-01-28, Sharding 2019-06-17
Participants:

 Description   

When a node becomes primary, we invalidate sessions that could have a retryable write on them because secondaries don't keep retryable writes state up-to-date. It would be more appropriate to refresh this state on stepDown instead.



 Comments   
Comment by Randolph Tan [ 03/Jun/19 ]

Confirmed that w: majority would fail when ran on secondary because of this check: https://github.com/mongodb/mongo/blob/9d212e4f098ccf4821fd6a1acde60402373b70ee/src/mongo/db/repl/replication_coordinator_impl.cpp#L1712

Comment by Kaloian Manassiev [ 06/May/19 ]

Spoke with Randolph in person.

Because the check for whether a write happened or not is done outside of a lock, this means a stepDown and rollback can happen concurrently. Now, this is not a problem per-se for local writes, because we don't guarantee they won't be rolled back, but as part of this ticket we need to check whether a wait for majority will also succeed in that situation, because that would be incorrect.

Comment by Kaloian Manassiev [ 06/May/19 ]

renctan, I assume you are referring to the rollback case, right? But if the callers are using a majority write concern, they will not get a response based on outdated information, only if they are using local. But with local write concern this is a problem regardless of when we do cleaning of the session catalog.

Comment by Randolph Tan [ 06/May/19 ]

kaloian.manassiev Based on my comment above, there is in potential bug: secondaries can claim that write was written based on information possibly invalidated by primary.

Comment by Randolph Tan [ 25/Jan/19 ]

Confirmed that we don't have the DB/coll lock while calling checkStatementExecuted, so a secondary in theory can respond that it did a write based on outdated information.

Generated at Thu Feb 08 04:49:26 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.