[DOCS-15321] Document that writeConcern.wtimeout is not applicable to sharded cluster ddl operations Created: 04/May/22 Updated: 22/Jan/24 |
|
| Status: | Backlog |
| Project: | Documentation |
| Component/s: | manual, Server |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Eric Sedor | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | backlog, feature, replication, sharding | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Participants: | |||||||||
| Days since reply: | 1 year, 39 weeks, 6 days ago | ||||||||
| Epic Link: | DOCSP-11702 | ||||||||
| Description |
|
In We can make this behavior clearer: Additionally:
|
| Comments |
| Comment by Tommaso Tocci [ 05/May/22 ] |
|
We should also change: In fact DDL operation in sharded clsuter do not use write concern timeout at all. Once they start they are guaranteed to complete eventually |
| Comment by Tommaso Tocci [ 05/May/22 ] |
|
Thanks pierlauro.sciarelli@mongodb.com for the clarification. I just wanted to summarize briefly the relation between Sharded DDL operations and WriteConcern:
|
| Comment by Pierlauro Sciarelli [ 05/May/22 ] |
|
While write concerns for DDLs can be used in replica sets, no write concern other than majority may be provided for sharded DDLs. I would try to explicitly point that out in the documentation: metadata operations are not transactional within a sharded cluster (each shard independently executes them), so once they all start they're all expected to finish (and that is guaranteed to happen for every DDL operations as soon as all shards can majority commit). The rationale behind that is: if there is no possibility to majority commit in a sharded cluster, the user better solve that because anyway all data operations may be rollback-ed at some point. Regarding the wtimeout, there seems to have been a lot of confusion regarding it in A questions may arise at this point: why are we allowing write concerns to be set for sharded DDLs? Since applications need to work seamlessly both on plain replica sets and sharded clusters, the public APIs are still allowing users to set write concerns. Any set write concern is then ignored and "upgraded" always to majority in a sharded cluster. (NB: this only applies to DDLs, write concerns are always respected for CRUD operations). |