[SERVER-32116] Retryable writes not safely retryable across collection drops in sharded clusters Created: 29/Nov/17 Updated: 06/Dec/22 Resolved: 19/Dec/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 3.6.0-rc7 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Randolph Tan | Assignee: | [DO NOT USE] Backlog - Sharding Team |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | RF36 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Sharding
|
| Operating System: | ALL |
| Sprint: | Sharding 2018-01-01 |
| Participants: |
| Description |
|
Scenario: |
| Comments |
| Comment by Randolph Tan [ 19/Dec/17 ] |
|
After thinking a bit more, making unsharded collection versioned is not sufficient, retryable write requests will also need to send the UUID of the collection and the retry logic should check that it matches with the write history. Closing this as won't fix. |
| Comment by Randolph Tan [ 18/Dec/17 ] |
|
This issue should go away once we start versioning unsharded collections as the retry will now throw a version error. |
| Comment by Andy Schwerin [ 08/Dec/17 ] |
|
There's no retry support required across fcv downgrade and re-upgrade. |
| Comment by Randolph Tan [ 05/Dec/17 ] |
kaloian.manassiev What I meant to say is that when user downgrades to v3.4, all UUID information is stripped, and if the user decides to upgrade back to fcv v3.6, the collections will be assigned a new UUID. In other words, the same collection can be assigned different UUID across it's lifetime if downgrade -> upgrade happens in it's lifetime. So, the plan to use UUID stored in oplog to detect if collection is the same as the current won't work in all cases. |
| Comment by Kaloian Manassiev [ 01/Dec/17 ] |
|
Retryable writes require sessions, which are only available in FCV 3.6, so downgrade should not be a problem. Also for the optimization in |
| Comment by Randolph Tan [ 29/Nov/17 ] |
|
Hm... realized that the fix above is not perfect for v3.6 as collections can lose their UUID information when a shard downgrades their featureCompatibilityVersion from v3.6 to v3.4. |
| Comment by Randolph Tan [ 29/Nov/17 ] |
|
One way to handle this is to have mongos include the UUID of the collection in the write request and the shard should return an error if it detects UUID mismatch in the write history (this also means that the we have to undo the optimization by |