Uploaded image for project: 'Documentation'
  1. Documentation
  2. DOCS-15586

[Server] Improve NaN-handling for expireAfterSeconds TTL index parameter

    XMLWordPrintableJSON

Details

    Description

      From: Investigate changes in SERVER-68477:


      Original Downstream Change Summary

      This is a good opportunity to review/clarify expireAfterSeconds in the docs:

      In MongoDB 4.4 and earlier, TTL indexes with an expireAfterSeconds value of NaN (not-a-number) were functional as indexes for queries but did not expire any documents. When such a config is in place, the following error is logged by MongoDB 4.2 and 4.4 primary replica set nodes:

      2022-08-05T21:00:00.000+0000 E  INDEX    [TTLMonitor] Error processing ttl index: { v: 2, key: { created: 1 }, name: "created_1", ns: "dbname.collname", expireAfterSeconds: nan.0, background: true } -- DurationOverflow: Cannot negate the minimum duration
      

      In MongoDB 5.0 and 6.0, as part of SERVER-56676, TTL indexes began treating NaN as 0, and the listIndexes command necessary for initial syncs and mongodump backups began returning 0 instead of NaN.

      Because of this change in unspecified behavior, when a TTL index with this improper configuration exists, the following can trigger the sudden expiration of TTL-indexed documents in a collection:

      • On MongoDB 4.4, when:
        • upgrading to MongoDB 5.0
        • initially syncing from a 5.0 or 6.0 node
      • On MongoDB 4.2, when initially syncing from a 5.0 or 6.0 node
      • On MongoDB 5.0 or 6.0
        • When restoring from a mongodump of a 4.2 or 4.4 collection that has a TTL configured with expireAfterSeconds: NaN
        • When initially syncing from a version 4.2 or 4.4 node that has a TTL configured with expireAfterSeconds: NaN

      WORKAROUNDS AND REMEDIATION

      In general, avoid this issue by avoiding expireAfterSeconds: NaN as a configuration and correct this config anywhere it exists.

      The following script for the mongosh shell reports any TTL indexes with an expireAfterSeconds: NaN configuration:

      Note: Do not use the legacy mongo shell for this operation.

      function getNaNIndexes() {
        const nan_idx = [];
       
        const dbs = db.adminCommand({ listDatabases: 1 }).databases;
       
        dbs.forEach((d) => {
          const listCollCursor = db
            .getSiblingDB(d.name)
            .runCommand({ listCollections: 1 }).cursor;
       
          const collDetails = {
            db: listCollCursor.ns.split(".$cmd")[0],
            colls: listCollCursor.firstBatch.map((c) => c.name),
          };
       
          collDetails.colls.forEach((c) =>
            db
              .getSiblingDB(collDetails.db)
              .getCollection(c)
              .getIndexes()
              .forEach((entry) => {
                if (Object.is(entry.expireAfterSeconds, NaN)) {
                  nan_idx.push({ ns: `${collDetails.db}.${c}`, index: entry });
                }
              })
          );
        });
       
        return nan_idx;
      };
      getNaNIndexes();
      

      Once identified, correct any TTL indexes with the expireAfterSeconds: NaN configuration and establish an unambiguous, valid configuration with a specified behavior. The collMod command allows you to modify the expireAfterSeconds value for an existing index.

      MongoDB intends to help protect against this behavior change by:

      • In this ticket, SERVER-68477, future MongoDB 5.0 and 6.0 versions will render badly configured TTL indexes ineffective, rather than applying a meaning of expireAfterSeconds: 0 to these indexes.
      • Releasing SERVER-68522 in MongoDB 5.0.11. With this fix, MongoDB 5.0.11+ will refuse to start if a TTL index with expireAfterSeconds: NaN exists, to ensure that the normal upgrade path from 4.4 is protected from this unexpected change in behavior. See SERVER-68522 for additional details.
      Original description

      Currently listIndexes, and subsequently initial sync, do not properly handle NaN values for expireAfterSeconds. This can result in unexpected TTL behavior, especially when upgrading from MongoDB 4.4 to MongoDB 5.0 or when migrating earlier index definitions to MongoDB 5.0 or 6.0.

      Attachments

        Activity

          People

            dave.cuthbert@mongodb.com Dave Cuthbert (Inactive)
            backlog-server-pm Backlog - Core Eng Program Management Team
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:
              1 year, 8 weeks, 2 days ago