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

checkMetadataConsistency should not check the timeseriesBucketsMayHaveMixedSchemaData top-level catalog field

XMLWordPrintableJSON

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 8.1.0-rc0
    • Affects Version/s: 8.1.0-rc0
    • Component/s: Catalog
    • None
    • Catalog and Routing
    • Fully Compatible
    • ALL
    • Hide

      The problem can be reproduced with the following jstest:

      import {ShardingTest} from "jstests/libs/shardingtest.js";

const st = new ShardingTest({shards: 3});
const db = st.getDB("whatever");
assert.commandWorked(db.adminCommand({enableSharding: db.getName(), primaryShard: st.shard0.name}));
assert.commandWorked(db.adminCommand({
    shardCollection: `${db.getName()}.tsmixed`,
    key: {meta: 1},
    timeseries: {timeField: "time", metaField: "meta"}
}));
assert.commandWorked(db.runCommand({collMod: "tsmixed", timeseriesBucketsMayHaveMixedSchemaData: true}));
assert.commandWorked(db.adminCommand(
    {moveChunk: `${db.getName()}.system.buckets.tsmixed`, find: {meta: 0}, to: st.shard1.name}));
assert.commandWorked(db.adminCommand({movePrimary: db.getName(), to: st.shard2.name}));

const inconsistencies = db.checkMetadataConsistency().toArray();
assert.eq(0, inconsistencies.length, tojson(inconsistencies));

st.stop();

      Case was originally isolated from a test failure in the sharding_jscore_passthrough_with_config_transitions_gen suite.

      Show
      The problem can be reproduced with the following jstest: import {ShardingTest} from "jstests/libs/shardingtest.js"; const st = new ShardingTest({shards: 3}); const db = st.getDB("whatever"); assert.commandWorked(db.adminCommand({enableSharding: db.getName(), primaryShard: st.shard0.name})); assert.commandWorked(db.adminCommand({ shardCollection: `${db.getName()}.tsmixed`, key: {meta: 1}, timeseries: {timeField: "time", metaField: "meta"} })); assert.commandWorked(db.runCommand({collMod: "tsmixed", timeseriesBucketsMayHaveMixedSchemaData: true})); assert.commandWorked(db.adminCommand( {moveChunk: `${db.getName()}.system.buckets.tsmixed`, find: {meta: 0}, to: st.shard1.name})); assert.commandWorked(db.adminCommand({movePrimary: db.getName(), to: st.shard2.name})); const inconsistencies = db.checkMetadataConsistency().toArray(); assert.eq(0, inconsistencies.length, tojson(inconsistencies)); st.stop(); Case was originally isolated from a test failure in the sharding_jscore_passthrough_with_config_transitions_gen suite.
    • CAR Team 2024-11-25

      Since SERVER-90899, the checkMetadataConsistency command includes a consistency check over the top-level catalog fields to detect inconsistencies, including the timeseriesBucketsMayHaveMixedSchemaData field.

      However, the timeseriesBucketsMayHaveMixedSchemaData top-level catalog field can be inconsistent between shards in some scenarios, for example, after running movePrimary over a collection (SERVER-90568). The field is deprecated (SERVER-96831) and the value stored in md.options.storageEngine.wiredTiger.configString should be used instead.

      Therefore, the field should be projected out from the check, similarly to the timeseriesBucketingParametersHaveChanged field.

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

              Created:
              Updated:
              Resolved: