Hi @Willy_Latorre,
EDIT: @Pavel_Duchovny answered while I was typing this ! I hope you find what you need in our answers .
Looks like you are connected on the shard0 of your MongoDB Sharded cluster.
You should not do manipulations directly on a shard in a sharded cluster. Your queries should go through the mongos.
Here are the collections I can see from a fresh sharded cluster with just one sharded collection test.testcol
from the mongos.
MongoDB Enterprise mongos> show dbs
admin 0.000GB
config 0.003GB
test 0.000GB
MongoDB Enterprise mongos> use admin
switched to db admin
MongoDB Enterprise mongos> show collections
system.keys
system.version
MongoDB Enterprise mongos> use config
switched to db config
MongoDB Enterprise mongos> show collections
actionlog
changelog
chunks
collections
databases
lockpings
locks
migrations
mongos
shards
system.indexBuilds
tags
transactions
version
MongoDB Enterprise mongos> use test
switched to db test
MongoDB Enterprise mongos> show collections
testcol
In my case, sh.status()
reports that my only chunk for test.testcol
is on my shard2. Here is the content of my shard2 replica set.
MongoDB Enterprise shard2:PRIMARY> show dbs
admin 0.000GB
config 0.001GB
local 0.001GB
test 0.000GB
MongoDB Enterprise shard2:PRIMARY> use admin
switched to db admin
MongoDB Enterprise shard2:PRIMARY> show collections
system.version
MongoDB Enterprise shard2:PRIMARY> use config
switched to db config
MongoDB Enterprise shard2:PRIMARY> show collections
cache.chunks.config.system.sessions
cache.chunks.test.testcol
cache.collections
cache.databases
rangeDeletions
system.indexBuilds
system.sessions
transactions
MongoDB Enterprise shard2:PRIMARY> use local
switched to db local
MongoDB Enterprise shard2:PRIMARY> show collections
oplog.rs
replset.election
replset.initialSyncId
replset.minvalid
replset.oplogTruncateAfterPoint
startup_log
system.replset
system.rollback.id
MongoDB Enterprise shard2:PRIMARY> use test
switched to db test
MongoDB Enterprise shard2:PRIMARY> show collections
testcol
So the above is what you should expect in your cluster too.
Now it looks like you are wondering what the oplog collection is from what I see above and it’s normal if this collection is a little bit big as it’s the collection that participate in the replication process in this shard / replica set. It contains the latest write operations this particular replica set did so far. The oplog is also a capped collection, meaning its size will depend on the size you chose to give it when you configured your mongod nodes. The bigger it is, the more history it can store. The oldest operations are overwritten by new ones.
You can actually see the oplog size along with the first and last time entries with this command:
MongoDB Enterprise shard2:PRIMARY> db.getReplicationInfo()
{
"logSizeMB" : 15910.21054649353,
"usedMB" : 1.5,
"timeDiff" : 2833,
"timeDiffHours" : 0.79,
"tFirst" : "Tue Sep 15 2020 21:04:28 GMT+0200 (CEST)",
"tLast" : "Tue Sep 15 2020 21:51:41 GMT+0200 (CEST)",
"now" : "Tue Sep 15 2020 21:51:44 GMT+0200 (CEST)"
}
In a prod cluster, the more you have, the merrier! That’s going to give more opportunities for a server to catch up if it is stopped and has to catch up.
I hope this helps.
Cheers,
Maxime.