[DOCS-9572] Docs for SERVER-7326: "validate" command should perform full index validation Created: 05/Dec/16  Updated: 30/Oct/23

Status: Closed
Project: Documentation
Component/s: manual, Server
Affects Version/s: None
Fix Version/s: Server_Docs_20231030

Type: Task Priority: Major - P3
Reporter: Emily Hall Assignee: Kay Kim (Inactive)
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
documents SERVER-7326 "validate" command should perform ful... Closed
Participants:
Days since reply: 1 year, 14 weeks, 2 days ago
Epic Link: DOCSP-1769

 Description   

Engineering Ticket Description:

If a user tries to use the validate command to validate an index, it sort of works, but it generates errors in the server log and incorrectly reports that the index has failed validation.

By "sort of works", I mean that it correctly lists the extents used by the index and correctly reports the datasize and last extent size. It incorrectly reports the number of btree buckets as the number of records. It also generates multiple errors logged on the server and incorrectly provides "advice" : "ns corrupt, requires repair".

It is easy to know that the specified collection is actually an index and to validate it as an index instead of as a normal collection. The validate() command (without

{ full : true }

) should return correct and useful information.

The command "db.indexName.validate(true)" should validate that the index entries actually point to valid records. We currently have no function that does this, and it is not done by "db.collection.validate(true)", presumably because it would be an expensive operation. This would be a very useful addition to the set of available diagnostic features.



 Comments   
Comment by Education Bot [ 31/Oct/22 ]

Hello! This ticket has been closed due to inactivity. If you believe this ticket is still important, please reopen it and leave a comment to explain why. Thank you!

Generated at Thu Feb 08 07:58:40 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.