[DOCS-13276] Investigate changes in SERVER-31083: Allow passing primary shard to "enableSharding" command for a new database Created: 10/Dec/19  Updated: 13/Nov/23  Resolved: 17/Dec/19

Status: Closed
Project: Documentation
Component/s: manual
Affects Version/s: None
Fix Version/s: 4.3.1, 4.2.2, 4.0.14, Server_Docs_20231030, Server_Docs_20231106, Server_Docs_20231105, Server_Docs_20231113

Type: Task Priority: Major - P3
Reporter: Backlog - Core Eng Program Management Team Assignee: Kay Kim (Inactive)
Resolution: Fixed Votes: 0
Labels: docs-sharding
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
documents SERVER-31083 Allow passing primary shard to "enabl... Closed
Participants:
Days since reply: 4 years, 8 weeks ago
Epic Link: DOCS: 4.4 Server Release Work

 Description   

Description

Downstream Change Summary

Please document the newly introduced parameter, but include a notice box to warn users that they shouldn't have to specify it and instead should let the balancer choose the primary shard.

Description of Linked Ticket

Background and motivation

Both replica set and sharded cluster MongoDB installations support implicit database and collection creation. In a sharded cluster, by default, implicitly created databases do not support creating sharded collections under them and because of this, sharding provides the enableSharding command, which explicitly creates the database and marks it as permitting sharded collections.

Currently, both implicitly created databases and those created through enableSharding (partially) use the balancer's statistics gathering logic to find the shard with the smallest data size and place the database's primary on it.

We have seen pathological cases where multiple concurrent implicit database creations end-up placing all database primaries on the same shard. In addition, because the implicit database placement doesn't use the complete balancer placement logic, it also does not take into account zones, which may lead to database primaries violating location requirements such as GDPR.

Proposed solution

Expose an optional string parameter called primaryShard on the enableSharding command.

If this parameter is present, it must contain the id of a valid shard, and the new database's primary should be placed on that shard. If the database already exists and its current primary is the same as the one specified through primaryShard, the command succeeds. Otherwise, the command should fail with error code NamespaceExists = 48.

If the parameter is omitted, the command should behave like it does currently and place the database's primary on the shard with the currently smallest data size.

Scope of changes

Impact to Other Docs

MVP (Work and Date)

Resources (Scope or Design Docs, Invision, etc.)



 Comments   
Comment by Githook User [ 18/Dec/19 ]

Author:

{'name': 'Kay Kim', 'email': 'kay.kim@10gen.com', 'username': 'kay-kim'}

Message: DOCS-13276: enableSharding and primaryShard
Branch: v4.0
https://github.com/mongodb/docs/commit/c8ccb0e94e533199f2cb913d303296012fc9cb5f

Comment by Githook User [ 17/Dec/19 ]

Author:

{'name': 'Kay Kim', 'email': 'kay.kim@10gen.com', 'username': 'kay-kim'}

Message: DOCS-13276: enableSharding and primaryShard
Branch: v4.0.14
https://github.com/mongodb/docs/commit/6ac5939c9547e3edf66a7b65385b6fa9d0ecbd9b

Comment by Githook User [ 17/Dec/19 ]

Author:

{'name': 'Kay Kim', 'email': 'kay.kim@10gen.com', 'username': 'kay-kim'}

Message: DOCS-13276: enableSharding and primaryShard
Branch: master
https://github.com/mongodb/docs/commit/097a39a8cc93f62558819a9cf6aafd05f2fe3bde

Generated at Thu Feb 08 08:07:22 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.