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