Each database in a sharded cluster has a primary shard. It is the default shard for all unsharded collections in the database. All unsharded collections for a database are created on the database primary shard by default.
The mongos selects the primary shard when creating a new database by picking the shard in the cluster that has the least amount of data.
To change the primary shard for a database, use the movePrimary command.
You have a sharded MongoDB cluster with three shards. If you insert a document whose shard key maps to shard A, which node actually receives the write?
When you run sh.status() you see a primary shard listed for a database. What does that mean for reads and writes to collections in that database?
If you create a new collection in a database that already has a primary shard, where will its data be stored initially?
Your application is experiencing write latency spikes after adding a new shard. How would you investigate whether the primary shard assignment is causing the issue?
During a rolling upgrade, you notice that a secondary in the primary shard becomes read‑only. Explain how that impacts the database's ability to serve reads for that database.
You accidentally set the wrong shard key and all writes are being routed to the primary shard. How would you re‑balance the data?
Design a strategy to mitigate a single primary shard becoming a bottleneck in a high‑throughput e‑commerce platform. Discuss trade‑offs of moving collections to other shards versus adding more replica set members.
Explain how you would handle a scenario where the primary node of the primary shard fails during a critical transaction. What steps does MongoDB take, and what would you need to monitor?
When scaling from a few terabytes to petabytes, how does the concept of primary shard affect your data placement and backup strategy?
At a company with multiple microservices each owning their own database, you need to evolve the sharding architecture to reduce cross‑service latency. How would you redesign the primary shard assignments across databases to achieve this?
Discuss the long‑term maintenance implications of having many databases each tied to a specific primary shard. What migration path would you propose to consolidate or re‑assign primary shards without downtime?
If a regulatory requirement forces you to keep certain data on a specific geographic region, how would you incorporate that constraint into primary shard selection and what architectural changes are needed?