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
    • 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: