You can update a document's shard key value unless the shard key field is the immutable _id field.
db.collection.replaceOne()
db.collection.updateOne()
db.collection.findOneAndReplace()
db.collection.findOneAndUpdate()
db.collection.findAndModify()
You must be on a mongos. Do not issue the operation directly on the shard.
You must run either in a transaction or as a retryable write.
You must include an equality condition on the full shard key in the query filter. For example, consider a messages collection that uses { activityid: 1, userid : 1 } as the shard key. To update the shard key value for a document, you must include activityid: <value>, userid: <value> in the query filter. You can include additional fields in the query as appropriate.
You have a collection sharded on 'userId' and need to change the userId for one document. How would you handle that?
What happens if you try to run an update that modifies the shard key field of a document in a sharded collection?
If a document must move to a different shard because its shard key changes, what steps would you take in MongoDB?
Our service lets users change their email address, which is part of the shard key. Explain how you would implement this change without downtime and discuss any performance implications.
During a migration we saw that updating the shard key caused chunk migrations to stall. Walk me through how you would debug and resolve the issue.
We considered a two‑phase update to change the shard key. What are the pros and cons of that versus a delete‑and‑re‑insert approach?
Design a strategy to support mutable shard keys for a high‑traffic collection, ensuring minimal impact on read/write latency and balanced distribution.
Explain how you would safely change the shard key for an existing collection with billions of documents, covering data migration, index rebuilding, and client compatibility.
What are the risks and mitigation techniques when using the 'moveChunk' command as part of a bulk shard key change across a cluster?
Our platform stores multi‑tenant data with a shard key that includes tenantId, but we now need to allow tenantId changes. Propose an architectural migration plan that minimizes service disruption and supports future schema evolution.
Discuss the long‑term maintenance implications of allowing mutable shard keys in a microservices environment, including versioning, backward compatibility, and operational tooling.
If you were to redesign the data model to avoid mutable shard keys altogether, what alternatives would you consider and how would you evaluate their trade‑offs at scale?