SERVER-84723 didn't fully fix the reported bug when resharding is involved – there's still a small window of time where anomalies can occur.
Resharding first commits on the configsvr (which produces the new collection 'timestamp') and later commits on the shards (renames the resharding temporary collections to the original namespace). Transactions that logically execute at a timestamp in between the two steps above will match post-resharding sharding metadata with pre-resharding data. SERVER-84723 didn't fully fix this because it relies on the new collection 'timestamp' to guarantee that any operation that executes at a later logical timestamp is safe – this isn't true considering the way resharding commits.
On v8.0, this affects moveCollection too.
- causes
-
SERVER-88360 Remove "Sharding catalog and local catalog collection uuid do not match" tripwire assertion
- Closed
- is related to
-
SERVER-87235 Resharding commit protocol should commit last on the configsvr
- Backlog
- related to
-
SERVER-84723 Sharded multi-document transactions can observe partial effects of concurrent DDL operations
- Closed