[SERVER-16548] Allow enforcement of additional custom write concern at pre-commit Created: 15/Dec/14  Updated: 06/Dec/22  Resolved: 22/Mar/17

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Kevin Pulo Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-15591 enforce secondaryThrottle during move... Closed
related to SERVER-14041 enhance secondaryThrottle parameter Closed
related to SERVER-16357 Chunk migration pre-commit write conc... Closed
Assigned Teams:
Sharding
Participants:

 Description   

The write concern of secondaryThrottle can be fine tuned (SERVER-14041), and is applied at pre-commit (as well as the normal w:majority WC) in case it's stronger than w:majority (or uses tags to target certain nodes) (SERVER-15591). However, a valid use case is a stronger/more targeted WC at pre-commit, but without slowing down the whole migration (as using secondaryThrottle would).

This request is to allow a custom pre-commit write concern to be configured and applied (in addition to w:majority), i.e. similar to SERVER-14041/SERVER-15591 except only at the end of the migration, not the whole way through (which is what secondaryThrottle is). (wtimeout should not be supported at pre-commit, since it would always be pointlessly unsafe.)



 Comments   
Comment by Kaloian Manassiev [ 22/Mar/17 ]

The write concern specified in secondaryThrottle is actually what runs after every single document being migrated. Regardless of what is specified there, we always do a majority write just before migration is committed.

With the more recent performance improvements in v3.4, secondaryThrottle defaults to local write only and its only use effectively becomes just "throttle" and we won't be doing any further enhancements to it.

Generated at Thu Feb 08 03:41:24 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.