We have completed Resharding work on Server. Flagging downstream teams as an FYI

Description of Linked Ticket

Summary

Introduce the ability to change the shard key of an existing sharded collection.

Motivation

Sharding enables workloads to achieve write scalability at the expense of additional latency by splitting up the data onto separate shards. Data access patterns within a user's application have varying levels of sensitivity to additional latency. The level of sensitivity influences the possible partitioning schemes and determines what additional latency for each data access pattern is acceptable. Moreover, the desired Serverless UX requires the Atlas team to be able to choose a shard key without prompting the user. Such an automated system can unknowingly make an undesirable trade-off for the user, or can learn later on that the application’s query shapes have changed. Thus, for such an automated system to be self-correcting, we would need the possibility to change the shard key of an existing sharded collection while having a minimal negative impact on the workload being run.

Cast of Characters

• Product Owner: Garaudy Etienne
• Project Lead: Max Hirschhorn
• Program Manager: Ratika Gandhi
• Drivers Contact:

Documentation

Product Description
Scope Document
Technical Design Document