[SERVER-43134] Only run background validation on check-pointed tables Created: 03/Sep/19  Updated: 29/Oct/23  Resolved: 16/Sep/19

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

Type: Task Priority: Major - P3
Reporter: Dianna Hohensee (Inactive) Assignee: Gregory Wlodarek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-43171 Validate catalog entries prior to ope... Closed
is depended on by SERVER-43316 uassert when trying to open a checkpo... Closed
Documented
is documented by DOCS-13031 Investigate changes in SERVER-43134: ... Closed
is documented by DOCS-13157 Investigate changes in SERVER-30357: ... Closed
Related
related to SERVER-30357 Allow users to run the validate cmd w... Closed
related to SERVER-42223 Use checkpoint cursors for collection... Closed
is related to SERVER-38962 The second phase of two-phase drop sh... Closed
Backwards Compatibility: Fully Compatible
Sprint: Execution Team 2019-09-09, Execution Team 2019-09-23
Participants:
Linked BF Score: 0

 Description   

A collection or index(es) will not be present in the latest checkpoint if it was created after the last checkpoint was taken. Attempting to open a WiredTiger checkpoint cursor on one of these would result in the following crash:

Failed to open a WiredTiger cursor. Reason: UnknownError: 2: No such file or directory, uri: table:{table_uri}, config: overwrite=false,checkpoint=WiredTigerCheckpoint

Instead of fassert-ing, like today when a cursor fails to open, an exception will be thrown instead for checkpoint cursors only.

When performing a background validation, if there is no check-pointed collection, then validation will return early. On the other hand, if there is no check-pointed index, skip that index but continue to validate the collection and other indexes.

We'll only validate the index(es) that are ready in the checkpoint and present in the in-memory index catalog (not dropped after the checkpoint) for the given collection.

With two-phase collection and index drops, the second phase of the drop is not performed (dropping the WiredTiger table) until the first phase (removing from MDB catalog and in-memory) is checkpointed. Thus, if the checkpoint lock is taken and the MDB catalog at the checkpoint time has an index entry, then the index table existence is ensured until the checkpoint lock is released and we shouldn't have a problem opening a checkpoint cursor on it.



 Comments   
Comment by Githook User [ 16/Sep/19 ]

Author:

{'name': 'Gregory Wlodarek', 'username': 'GWlodarek', 'email': 'gregory.wlodarek@mongodb.com'}

Message: SERVER-43134 Only run background validation on check-pointed tables
Branch: master
https://github.com/mongodb/mongo/commit/2028897e65401497c58d97a16da68f2e404bbee7

Comment by Dianna Hohensee (Inactive) [ 03/Sep/19 ]

I would like to introduce this unit test if we opt for taking a checkpoint if necessary

TEST_F(BackgroundCollectionValidationTest, BackgroundValidationWithoutACheckpoint) {
    auto opCtx = operationContext();
 
    // Insert some data that the checkpoint will not have.
    int numRecords = insertDataRange(opCtx, 0, 5);
 
    {
        // Background validation without taking a checkpoint should see nothing.
        // (This depends upon the fact that checkpoints are taken every 60 seconds. This test should
        // have plenty of time to run (~60 seconds) before the new data is checkpointed.)
 
        ValidateResults validateResults;
        BSONObjBuilder output;
        ASSERT_OK(CollectionValidation::validate(opCtx,
                                                 kNss,
                                                 ValidateCmdLevel::kValidateNormal,
                                                 /*background*/ true,
                                                 &validateResults,
                                                 &output));
        BSONObj obj = output.obj();
 
        ASSERT_EQ(validateResults.valid, true);
        ASSERT_EQ(obj.getIntField("nrecords"), 0);
    }
 
    // Foreground validation will see the previously inserted data.
    foregroundValidate(opCtx, true, numRecords, 0, 0);
}

Generated at Thu Feb 08 05:02:22 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.