Avoid checkMetadataConsistency false positives due to sintatically mismatching storage engine config string

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Catalog and Routing
    • ALL
    • None
    • 3
    • TBD
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      Ticket blocked on SERVER-107183, once the new API will exist we should just call into that to check storage options equivalence.

      Although the MongoDB server operates above the storage engine layer, the current create command allows users to specify storage engine specific options to be applied to newly created collections.

      When checking metadata consistency across nodes within a replica set or between shards, we double check if collection options—including storage engine options—are aligned. However, comparing these options using simple lexicographic equality is not reliable. We have encountered situations where the order of parameters (such as X before Y versus Y before X) or differences in syntax (like 0 instead of false) varied, even though the underlying semantics were identical.

      Example of same config strings with different shapes:

      cache_resident=false,internal_key_truncate=,log=(enabled=)
      cache_resident=0,internal_key_truncate=true,log=(enabled=true)
      

              Assignee:
              Unassigned
              Reporter:
              Pierlauro Sciarelli
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated: