replSetResizeOplog in disagg causes $listCatalog and listCollections inconsistency about oplog settings

    • Type: Bug
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • RSSD
    • ALL
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      When replSetResizeOplog is run against the standby with a different value from the primary, listCollections and listCatalog on the secondary return different capped size values for the oplog collection.

      The checkMetadataConsistency check that runs during jstest shutdown compares these values, and fails in this case.

       

      To reproduce, remove the workaround in repl_set_resize_oplog.js:

      // TODO (SERVER-131719): Remove this workaround
      // In disaggregated storage, listCollections reads from the secondary's in-memory catalog while
      // listCatalog reads from the shared durable catalog, which is updated by the primary and may
      // reflect the result of replSetResizeOplog from the primary. This can cause a shutdown consistency
      // check to fail because listCollections and listCatalog on the secondary have different
      // options.size values for the oplog.rs collection.
      // As a workaround, set the secondary to the same value as the primary.
      let secondary = replSet.getSecondary();
      assert.commandWorked(
          secondary
              .getDB("admin")
              .runCommand({replSetResizeOplog: 1, size: (1 * PB) / MB, minRetentionHours: 1}),
      );
      assert.eq(
          primary.getDB("local").oplog.rs.stats().maxSize,
          secondary.getDB("local").oplog.rs.stats().maxSize,
      ); 

            Assignee:
            Unassigned
            Reporter:
            Anna Veselova
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: