Docs Menu
Docs Home
/
MongoDB Manual
/
Reference
/
mongosh Methods
/
Collection Methods

db.collection.validate()

On this page

  • Description
  • Syntax
  • Behavior
  • Examples

Description

db.collection.validate(<documents>)

Important

mongosh Method

This page documents a mongosh method. This is not the documentation for database commands or language-specific drivers, such as Node.js.

For the database command, see the validate command.

For MongoDB API drivers, refer to the language-specific MongoDB driver documentation.

For the legacy mongo shell documentation, refer to the documentation for the corresponding MongoDB Server release:

Validates a collection. The method scans a collection data and indexes for correctness and returns the result. For details of the output, see Validate Output.

Starting in version 5.0, the db.collection.validate() method can also fix inconsistencies in the collection.

Index inconsistencies include:

  • An index is multikey but there are no multikey fields.

  • An index has multikeyPaths covering fields that are not multikey.

  • An index does not have multikeyPaths but there are multikey documents (for indexes built before 3.4).

If any inconsistencies are detected by the db.collection.validate() command, a warning is returned and the repair flag on the index is set to true.

db.collection.validate() also validates any documents that violate the collection's schema validation rules.

The db.collection.validate() method is a wrapper around the validate command.

Syntax

Note

Changed in version 4.4

db.collection.validate() no longer accepts just a boolean parameter. See db.collection.validate() Parameter Change.

Changed in version 5.0.

The db.collection.validate() method has the following syntax:

db.collection.validate( {
   full: <boolean>,          // Optional
   repair: <boolean>         // Optional, added in MongoDB 5.0
} )

Parameters

The db.collection.validate() method can take the following optional document parameter with the fields:

Field
Type
Description
boolean

Optional. A flag that determines whether the command performs a slower but more thorough check or a faster but less thorough check.

  • If true, performs a more thorough check with the following exception:

    • Starting in MongoDB 4.4, full validation on the oplog for WiredTiger skips the more thorough check.

  • If false, omits some checks for a faster but less thorough check.

The default is false.

Starting in MongoDB 3.6, for the WiredTiger storage engine, only the full validation process will force a checkpoint and flush all in-memory data to disk before verifying the on-disk data.

In previous versions, the data validation process for the WT storage engine always forces a checkpoint.

boolean

Optional. A flag that determines whether the command performs a repair.

  • If true, a repair is performed.

  • If false, no repair is performed.

The default is false.

A repair can only be run on a standalone node.

The repair fixes these issues:

  • If missing index entries are found, the missing keys are inserted into the index.

  • If extra index entries are found, the extra keys are removed from the index.

  • If multikey documents are found for an index that is not a multikey index, the index is changed to a multikey index.

  • If multikey documents are found that are not specified by an index's multikey paths, the index's multikey paths are updated.

  • If corrupt documents with invalid BSON data are found, the documents are removed.

Tip

See also:

--repair option for mongod

New in version 5.0.

Behavior

Performance

The db.collection.validate() method is potentially resource intensive and may impact the performance of your MongoDB instance, particularly on larger data sets.

The db.collection.validate() method obtains an exclusive lock on the collection. This will block all reads and writes on the collection until the operation finishes. When run on a secondary, the operation can block all other operations on that secondary until it finishes.

Warning

Validation has exclusive lock requirements that affect performance on primaries and on secondaries that are servicing reads. Consider only running db.collection.validate() on nodes that are not servicing reads or writes.

To minimize impact on the primary, the majority of the data-bearing (non-arbiter), voting members in the cluster must be available and must not have significant replication lag.

To minimize the impact of the validation operation on client applications, run db.collection.validate() on a secondary node that is not servicing read requests. You can convert the current primary node to a secondary node, by running the rs.stepDown() method.

To completely isolate the db.collection.validate() operation from client traffic, choose one of the following options:

Data Throughput Metrics

Starting in version MongoDB 4.4,

Examples

  • To validate a collection myCollection using the default validation setting (specifically, full: false):

    db.myCollection.validate()
    db.myCollection.validate({ })
    db.myCollection.validate( { full: false } )

  • To perform a full validation of collection myCollection, specify full: true:

    db.myCollection.validate( { full: true } )

  • To repair collection myCollection, specify repair: true:

    db.myCollection.validate( { repair: true } )

For details of the output, see Validate Output.

Back

db.collection.watch()