[DOCS-13031] Investigate changes in SERVER-43134: Only run background validation on check-pointed tables Created: 16/Sep/19  Updated: 13/Nov/23  Resolved: 10/Feb/20

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

Type: Task Priority: Major - P3
Reporter: Backlog - Core Eng Program Management Team Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
documents SERVER-43134 Only run background validation on che... Closed
Duplicate
duplicates DOCS-13157 Investigate changes in SERVER-30357: ... Closed
Participants:
Days since reply: 4 years, 21 weeks, 2 days ago
Epic Link: DOCS: 4.4 Server Release Work

 Description   

Description

Downstream Change Summary

Background validation will only run if the checkpointed files exist for the _mdb_catalog and collection. If a checkpointed file is missing for an index, that index will be skipped in the validation.

Description of Linked Ticket

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.

Scope of changes

Impact to Other Docs

MVP (Work and Date)

Resources (Scope or Design Docs, Invision, etc.)


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