[SERVER-16728] Show collection doesn't show some collections Created: 01/Jan/15  Updated: 05/Feb/16  Resolved: 09/Mar/15

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: 2.4.9
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Shaked S Assignee: Ramon Fernandez Marina
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: ALL
Participants:

 Description   

Hello,

We have a problem in the production where show collections doesn't show all of the collections,
but db.mymissingcollection.find() or db.mymissingcollection.count() shows the collection missing from the show collections command.

This happened on 3 servers - 2 Cetons, and 1 windows. Some time after (about 3 weeks) the bug just disappear, and after changing the mongo tables, starts again - not always, just sometimes.

We have no sharding, we do run the "use" command, and we cannot reproduce this. Restarting mongod service doesn't solve this.



 Comments   
Comment by Ramon Fernandez Marina [ 05/Feb/16 ]

matt@clenchmedia.com, a 2.4.14 shell will have trouble with some operations on a 3.0+ server, so that could easily explain the behavior you're seeing. I'm thinking of SERVER-17087 in particular: you'll need at least a 2.6.8 client to talk to a 3.0+ server.

Since 2.4.14 is quite old at this stage I'd strongly recommend you upgrade to a recent version (3.2.1 is the latest stable, 3.2.2-rc0 release candidate was released today). If after the upgrade you're still experiencing problems please open a new SERVER ticket and we'll take a closer look.

Thanks,
Ramón.

Comment by Matt Vincelli [ 05/Feb/16 ]

Update to the previous comment. I noticed that the mongo shell version was different on my two systems (2.4.14 vs 3.0.9). I upgraded mongodb-org per the instructions at https://docs.mongodb.org/manual/tutorial/install-mongodb-on-red-hat/ and retried the commands on the remote server.

Lo and behold, it worked correctly!

My only guess is that I am using WiredTiger collections and the 2.4.14 shell can only read Mmap collections (since WiredTiger was introduced in 3.0+). But if that were the case, then why could the shell perform a db.record.count() correctly, but couldn't show the collections???

Regards,
Mark

Comment by Matt Vincelli [ 05/Feb/16 ]

I just started to experience this issue on my server. It is a single node Replica set, so it is the Primary. Nothing shows up in the logs that I can see.

The command "show databases" works fine, but "show collections" returns an empty array. Although I can still access data in a collection if I know the name of the collection.

remote connection

[root@web01 ~]# mongo db1.pteradata.net
MongoDB shell version: 2.4.14
connecting to: db1.pteradata.net/test
pteradata:PRIMARY> show databases;
local	8.155338287353516GB
rdm_admin	0.005695343017578125GB
rdm_archive	0.000049591064453125GB
rdm_data	0.5376853942871094GB
rdm_queue	0.26190185546875GB
pteradata:PRIMARY> use local;
switched to db local
pteradata:PRIMARY> show collections;
pteradata:PRIMARY> use rdm_data;
switched to db rdm_data
pteradata:PRIMARY> show collections;
pteradata:PRIMARY> db.record.count();
734777
pteradata:PRIMARY> db.getCollectionNames();
[ ]
pteradata:PRIMARY> 

In doing some testing on this, it seems to only be affected when remotely connecting to a mongo server. If I connect directly to the server running mongod, then everything works.

local connection

[root@db1 ~]# mongo localhost
MongoDB shell version: 3.0.9
connecting to: localhost
pteradata:PRIMARY> show databases;
local        8.155GB
rdm_admin    0.006GB
rdm_archive  0.000GB
rdm_data     0.538GB
rdm_queue    0.262GB
pteradata:PRIMARY> use local;
switched to db local
pteradata:PRIMARY> show collections;
clustermanager
me
oplog.rs
startup_log
system.replset
pteradata:PRIMARY> use rdm_data;
switched to db rdm_data
pteradata:PRIMARY> show collections;
banned
record
record_matrix
record_post
screamer
pteradata:PRIMARY> db.record.count();
734777
pteradata:PRIMARY> db.getCollectionNames();
[ "banned", "record", "record_matrix", "record_post", "screamer" ]
pteradata:PRIMARY> 

I have not repaired my tables at all. The tried restarted mongod (using Mongo MMS), but the situation persisted. Could it be a permissions issue?

Regards,
Mark

Comment by Ramon Fernandez Marina [ 09/Mar/15 ]

Thanks for letting us know shaked. Yes, if this happens again re-opening the ticket and sending full logs will be the first steps – we'll cross that bridge if/when we get to it.

Regards,
Ramón.

Comment by Shaked S [ 09/Mar/15 ]

Hello,

No problem. Actually, this hasn't happened again since the creation of this issue (no change in packages versions, or in uploaded databases).

When this behaviour will occur again, I will be happy to send full log (only /var/log/mongo folder, right?) to the private and secure upload you suggested.
Sending the database files may be a problem.

Thank you,
Shaked

Comment by Ramon Fernandez Marina [ 05/Mar/15 ]

Apologies for the long delay shaked; the information about --repair makes me wonder if there's a race condition somewhere or an "accounting error" when keeping track of collections. If this happens again, would you be able to upload the database file(s) containing the affected collection(s) so we can investigate further? Having full server logs may be useful as well.

I can provide a private and secure upload so your data is only accessible to MongoDB staff for the purpose of troubleshooting this ticket – please let me know and I'll send you the details on the upload procedure.

Thanks,
Ramón.

Comment by Shaked S [ 06/Jan/15 ]

Yes this is the case.
We have installed the next packages:
mongo-10gen-server-2.4.9-mongodb_1.x86_64
mongo-10gen-2.4.9-mongodb_1.x86_64

The servers are no replica sets, but just stand alone servers. And yes - we sometimes dropping and creating the collections anew (part of some process we need).

We found out that after `mongod --repair` command the collections disappear, and we can create them again.

Comment by Ramon Fernandez Marina [ 05/Jan/15 ]

shaked, if I understand correctly, the scenario you're describing is as follows:

> show collections
foo
system.indexes
> db.bar.find()
... documents returned ...

Is this the case? Can you please provide some more information about your setup, including the MongoDB version? You mention three servers – do they form a replica set or are they stand-alone? Can you also elaborate on what you mean when you say "after changing the mongo tables"? Do you have multiple clients creating and dropping collections?

Generated at Thu Feb 08 03:42:04 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.