-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Sharding
-
Fully Compatible
-
v4.0, v3.6
-
Sharding 2018-09-24, Sharding 2018-10-08
-
25
Sharding's writeConcern timeouts related to writes performed throughout the migration process should be bumped higher to prevent BFs. This write specifically caused the linked BF. Any other related writes that can be bumped without seriously affecting the rest of the system should be as well.
Proposing a bump to 30 second timeouts rather than the 15 second timeout that's the norm in sharding.
suggested fix
as we have 20 different kMajorityWriteConcern values defined in the anonymous namespaces but most still connected we can add the durations to write_concern_options.h
static constexpr Seconds kWriteConcernTimeoutSharding{30}; static constexpr Seconds kWriteConcernTimeoutMigration{60}; static constexpr Seconds kWriteConcernTimeoutUserCommand{60};
and use as instead of
const WriteConcernOptions kMajorityWriteConcern(WriteConcernOptions::kMajority,
WriteConcernOptions::SyncMode::UNSET,
Seconds(30));
use
const WriteConcernOptions kMajorityWriteConcern(WriteConcernOptions::kMajority,
WriteConcernOptions::SyncMode::UNSET,
WriteConcernOptions::kWriteConcernTimeoutSharding);
- is duplicated by
-
SERVER-32693 Increase write concern timeout used during addShard
- Closed
- related to
-
SERVER-37377 Consider increasing default distributed lock timeout
- Closed