[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:
0. shardB is the primary shard of "test" database.
1. test.foo is a sharded collection and has chunks in shardA [-inf, 0) & shardB [0, inf).
2. User sends batch insert [{-1}, {1}] to mongos, the insert will split up to shardA {-1} & shardB {1}.
3. test.foo gets dropped.
4. If user tries to send the same retryable write in step #2 to mongos, mongos will target the full batch [{-1}, {1}] to shardB. And this will result in the shardB applying the write {-1} and not {1}.



 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 ]

Retryable writes require sessions, which are only available in FCV 3.6, so downgrade should not be a problem.

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 SERVER-31328, we could start storing the UUID in the committed statements map. The UUID for all statements in a txn must be the same so that can even be consolidated if memory is concern, but I don't think adding UUID would be a problem.

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 SERVER-31328).

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