Unable to shard the collection and using db version 6.0.12

I am trying to setup sharded cluster on docker environment, 3 config server, 3 sets of shard servers (each set has 3 nodes), after create the cluster, i see the partitioned: false on database level,
and unable to shard the collection as well, with appropriate shard key,
I just followed the mongodb document in order to shard the timeseries collection (sample steps that i followed from document), Please help, what could be the issue?

Just followed this document to shard the timeseries collection,

also created an index, but no luck, this is what i see, with sh.status() from mongos,

database: {
  _id: 'demodb',
  primary: 'shard3RS',
  partitioned: false,
  version: {
    uuid: UUID('b5062d73-7025-4da8-ae92-e8e696fcd0c6'),
    timestamp: Timestamp({ t: 1705452091, i: 1 }),
    lastMod: 1
  }
},
collections: {
  'demodb.system.buckets.deliverySensor': {
    shardKey: { 'meta.location': 1 },
    unique: false,
    balancing: true,
    chunkMetadata: [ { shard: 'shard3RS', nChunks: 1 } ],
    chunks: [
      { min: { 'meta.location': MinKey() }, max: { 'meta.location': MaxKey() }, 'on shard': 'shard3RS', 'last modified': Timestamp({ t: 1, i: 0 }) }
    ],
    tags: []
  }   }
}

}
]

I get this error,

[direct: mongos] demodb> db.deliverySensor.getShardDistribution()
MongoshInvalidInputError: [SHAPI-10001] Collection deliverySensor is not sharded

The backing collection demodb.system.buckets.deliverySensor is sharded per the sh.status() output.

This is known issue: https://jira.mongodb.org/browse/MONGOSH-1447

1 Like

Thanks for your attention and update,
i am worried about this value “partitioned: false”, if the collection is sharded already, (any thoughts please)
database: {
_id: ‘demodb’,
primary: ‘shard3RS’,
partitioned: false,

And this is what i see it from config.collection,

{
_id: ‘demodb.system.buckets.deliverySensor’,
lastmodEpoch: ObjectId(‘65a7246057deb6515e858e5e’),
lastmod: ISODate(‘2024-01-17T00:50:40.969Z’),
timestamp: Timestamp({ t: 1705452640, i: 7 }),
uuid: UUID(‘897306da-7791-4c3e-8bb6-d6e72eac053f’),
key: { ‘meta.location’: 1 },
unique: false,
chunksAlreadySplitForDowngrade: false,
noBalance: false,
timeseriesFields: {
timeField: ‘timestamp’,
metaField: ‘metadata’,
granularity: ‘minutes’,
bucketMaxSpanSeconds: 86400
}
}

https://www.mongodb.com/docs/manual/reference/method/sh.status/#mongodb-data-sh.status.databases.partitioned

Emphasis mine:

Starting in MongoDB 6.0 and feature compatibility version (fCV) 6.0, the partitioned flag only maintains backward compatibility with previous versions. By default, all databases are enabled for sharding regardless of the partitioned value.

Cool, then the cluster is perfect to load the data to distribute it across the nodes of the cluster, am i correct, please ?

Looks good to me, start loading it up.

1 Like

Thanks a lot for your continuous attention and response,

1 Like

One more small clarification, after i load the data, how could i know the loaded data have been partitioned, because the expectation is the response time with data retrieval faster than single instance.

Check the sh.status() again. The distribution will be updated when the migration threshold is reached.

Thank you, i am currently loading the data which is around 600 million records, hopefully i should be able to see some update in sh.status().

Hi Chris,
I have loaded 43 millions of record into collection (timeseries), which took longer time than standalone db (no shard/ single node [timeseries] )
I assume it could be because of write concern (w: majority), is it correct?
I could not able to figure it out if the partition works for this data, also noticed this error in mongos log,

================================================
[direct: mongos] test> sh.status()
shardingVersion
{ _id: 1, clusterId: ObjectId(‘65a71fc5e797e84c33bbbe31’) }

shards
[
{
_id: ‘shard1RS’,
host: ‘shard1RS/10.130.0.6:27017,10.130.0.7:27017,10.130.0.8:27017’,
state: 1,
topologyTime: Timestamp({ t: 1705451871, i: 6 })
},
{
_id: ‘shard2RS’,
host: ‘shard2RS/10.130.0.10:27017,10.130.0.11:27017,10.130.0.9:27017’,
state: 1,
topologyTime: Timestamp({ t: 1705451876, i: 6 })
},
{
_id: ‘shard3RS’,
host: ‘shard3RS/10.130.0.12:27017,10.130.0.13:27017,10.130.0.14:27017’,
state: 1,
topologyTime: Timestamp({ t: 1705451880, i: 5 })
}
]

active mongoses
[ { ‘6.0.12’: 1 } ]

autosplit
{ ‘Currently enabled’: ‘yes’ }

balancer
{
‘Currently running’: ‘no’,
‘Currently enabled’: ‘yes’,
‘Failed balancer rounds in last 5 attempts’: 0,
‘Migration Results for the last 24 hours’: ‘No recent migrations’
}

databases
[
{
database: { _id: ‘config’, primary: ‘config’, partitioned: true },
collections: {
‘config.system.sessions’: {
shardKey: { _id: 1 },
unique: false,
balancing: true,
chunkMetadata: [ { shard: ‘shard1RS’, nChunks: 1024 } ],
chunks: [
‘too many chunks to print, use verbose if you want to force print’
],
tags:
}
}
},
{
database: {
_id: ‘demodb’,
primary: ‘shard2RS’,
partitioned: false,
version: {
uuid: UUID(‘d9d664ac-f5fd-40e3-8be9-f7b0c1e5123c’),
timestamp: Timestamp({ t: 1705527230, i: 1 }),
lastMod: 1
}
},
collections: {
‘demodb.system.buckets.sensor_data’: {
shardKey: { ‘meta.sensorID’: 1, ‘control.min.timestamp’: 1 },
unique: false,
balancing: true,
chunkMetadata: [ { shard: ‘shard2RS’, nChunks: 1 } ],
chunks: [
{ min: { ‘meta.sensorID’: MinKey(), ‘control.min.timestamp’: MinKey() }, max: { ‘meta.sensorID’: MaxKey(), ‘control.min.timestamp’: MaxKey() }, ‘on shard’: ‘shard2RS’, ‘last modifed’: Timestamp({ t: 1, i: 0 }) }
],
tags:
}
}
}
]

================================================

I am receiving this error while retrieving the data,

“id”:4625501, “ctx”:“conn734”,“msg”:“Unable to establish remote cursors”,“attr”:{“error”:{“code”:169,“codeName”:“CommandOnShardedViewNotSupportedOnMongod”,“errmsg”:“Resolved views on sharded collections must be executed by mongos”,“resolvedView”:{“ns”:“demodb.system.buckets.sensor_data”,“pipeline”:[{“$_internalUnpackBucket”:{“timeField”:“timestamp”,“metaField”:“metadata”,“bucketMaxSpanSeconds”:3600}}],

Also, i just had small clarificaiton, using timestamp also along with sensorID would be the issue ?