[SERVER-67695] Remove the write-blocking mode of dbCheck Created: 30/Jun/22  Updated: 29/Oct/23  Resolved: 03/Nov/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 6.2.0-rc0

Type: Improvement Priority: Major - P3
Reporter: Louis Williams Assignee: Louis Williams
Resolution: Fixed Votes: 0
Labels: louis-preferred
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-66145 Identify and fix locations that write... Closed
is depended on by SERVER-60621 Investigate if we can ban upgrading t... Closed
Problem/Incident
Backwards Compatibility: Minor Change
Sprint: Execution Team 2022-09-19, Execution Team 2022-10-03, Execution Team 2022-10-31, Execution Team 2022-11-14
Participants:
Linked BF Score: 157

 Description   

The point-in-time snapshot mode of dbCheck (the default) seems to have been working well. Given that the default history window is 5 minutes, there is less of a risk of secondaries not having enough history to support a timestamped read in the past. This was more of a concern in 4.4 where the window was 5 seconds.

We should remove support for the version that uses MODE_S locks and blocks writes, since it does not appear to be in active use.



 Comments   
Comment by Githook User [ 04/Nov/22 ]

Author:

{'name': 'Louis Williams', 'email': 'louis.williams@mongodb.com', 'username': 'louiswilliams'}

Message: SERVER-67695 Prevent dbcheck.js from running in multiversion tests
Branch: master
https://github.com/mongodb/mongo/commit/6800a766528950978fe4f67f88350c2da152c9dd

Comment by Githook User [ 03/Nov/22 ]

Author:

{'name': 'Louis Williams', 'email': 'louis.williams@mongodb.com', 'username': 'louiswilliams'}

Message: SERVER-67695 Remove write-blocking dbCheck

This removes the snapshotRead:false option to dbCheck which blocked concurrent writes
Branch: master
https://github.com/mongodb/mongo/commit/ba467f46cc1bc49965e1d72b541eff0cf1d7b22e

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