[SERVER-49145] Prevent distributed lock timeouts in suites with background migrations Created: 26/Jun/20 Updated: 29/Oct/23 Resolved: 16/Nov/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 4.9.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Jack Mulrow | Assignee: | Jordi Serra Torrens |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | sharding-wfbf-day | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Linked BF Score: | 23 | ||||||||||||||||||||
| Description |
|
A migration holds a distributed lock on the migrating namespace for its duration, so in suites with background migrations, like multi_stmt_txn_jscore_passthrough_with_migration, sharding metadata commands that take the distributed lock can exhaust the 20 second acquisition timeout if a migration takes longer than 20 seconds or if it repeatedly fails to acquire the lock due to a lack of a fairness policy. Even if the commands use the in-memory NamespaceSerializer lock, they can still time out taking the distributed lock because migrations don't use the NamespaceSerializer. Changing all config server commands that take distributed locks to use the NamespaceSerializer should avoid timeouts, or the distributed lock acquisition timeout can be raised in these suites. |
| Comments |
| Comment by Githook User [ 16/Nov/20 ] |
|
Author: {'name': 'Jordi Serra Torrens', 'email': 'jordi.serra-torrens@mongodb.com', 'username': 'jordist'}Message: |