[SERVER-29557] Allow healthy databases to skip repairs Created: 12/Jun/17  Updated: 06/Dec/22  Resolved: 23/Jun/17

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

Type: Improvement Priority: Major - P3
Reporter: Chris Kuethe Assignee: Backlog - Storage Execution Team
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-19815 Improved mongod --repair option for W... Closed
Related
related to SERVER-19043 Implement a connectDatabase / disconn... Closed
related to SERVER-23573 Backup/Restore of individual database... Closed
Assigned Teams:
Storage Execution
Participants:

 Description   

As a complement to SERVER-29553, allow me to skip repairs on an already repaired database. The aforementioned database with hundreds of millions of documents took a couple of hours to repair, and it's now healthy.

Unfortunately, while attempting to repair some another database in this instance I hit some assertion failure which stopped the entire repair process, rather unnecessarily, i think. SERVER-29555

Now when I restart the repair, I'm going to waste another few hours waiting for a_big_database to repair unnecessarily before I can get around to repairing some_other_big_database which is what I really care about.



 Comments   
Comment by Ian Whalen (Inactive) [ 23/Jun/17 ]

Chris, we've linked a project we have scheduled to improve database repair (SERVER-19815) that should encompass the issues you've encountered here. We'll definitely take your suggestions into account as we continue to design this project.

Comment by Mark Agarunov [ 16/Jun/17 ]

Hello chris.kuethe@gmail.com,

After taking another look at this, I believe you are correct that this is related and not a duplicate. I've reopened the ticket and set the fixVersion to "Needs Triage" for this new feature to be scheduled against our currently planned work. Updates will be posted on this ticket as they happen.

Thanks,
Mark

Comment by Chris Kuethe [ 15/Jun/17 ]

I'd call it related, but not duplicate. Like a file system, you could keep a clean/dirty bit on each database or collection which would be the first write when a database opens and is changed and the last write before it closes (or the last write after changes are committed).

Comment by Mark Agarunov [ 13/Jun/17 ]

Hello chris.kuethe@gmail.com,

Thank you for the report. The behavior you've detailed appears to be the same as the issue in SERVER-23573. Please watch SERVER-23573 for further updates on this issue.

Thanks,
Mark

Generated at Thu Feb 08 04:21:12 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.