Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-97721

system.profile visibility inconsistency in sharded cluster after db.setProfilingLevel

    • Type: Icon: Bug Bug
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: 8.1.0-rc0, 8.0.0
    • Component/s: Catalog, Sharding
    • None
    • Query Integration
    • ALL
    • 0
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      Problem:

      When enabling profiling on a new database in a sharded cluster using db.setProfilingLevel(2), the system.profile collection is created on the local shard but may not be visible through the mongos router or replica set endpoint. This results in the collection not appearing in show collections output. Additionally the db appears in "show dbs" output, but running a command (e.g. db.checkMetadataConsistency()) returns a "database not found" error.

      Steps to Reproduce (Simplified):

      1. Initialize a sharded cluster.
      2. Connect to a shard directly.
      3. Use a new or non-existent database (e.g., use profile1).
      4. Execute db.setProfilingLevel(2) - note that enabling profiling is documented as a Shard Direct Command.
      5. Connect to the router.
      6. Run show collections. The system.profile collection is not visible.
      7. Perform an operation that creates a collection within the database (e.g., db.createCollection("xyz")).
      8. Run show collections again. Now the system.profile collection has become visible.

      Below in the comments the detailed steps can be found how to reproduce for sharder cluster including stepdowns and stepups and replica set endpoint, as the same root cause also has 2 other alternative ways to reproduce it, either using the Replica Set Endpoint, or by creating system.profile through the router.

      Root Cause:

      Enabling profiling creates the system.profile collection on the local shard's catalog but fails to register the database in the cluster's catalog. Consequently, the collection exists locally but is not visible or recognized by the mongos router.

      Expected Behaviour:

      The system.profile collection should be immediately visible through the mongos router after executing db.setProfilingLevel(2) on a new database, mirroring the behavior observed in standalone replica sets. db.checkMetadataConsistency() should also pass without errors.

      Impact:

      Primarily affects consistency validation in tests; no known production impact.

      Additional Notes:

      • The described behavior is observed in sharded clusters, including those with the featureFlagReplicaSetEndpoint enabled.
      • There are 3 different ways to reproduce, direct shard connection, creating system.profile through the router, and replica set endpoints

            Assignee:
            Unassigned Unassigned
            Reporter:
            joan.bruguera-mico@mongodb.com Joan Bruguera Micó
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              None
              None
              None
              None