[SERVER-10000] Can't connect to mongod when another DB is being compacted (v2.2.x) Created: 24/Jun/13  Updated: 14/Jan/14  Resolved: 25/Jun/13

Status: Closed
Project: Core Server
Component/s: Admin, Concurrency, Internal Code, Querying, Shell
Affects Version/s: 2.2.3
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Kay Agahd Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

linux 64 bit


Issue Links:
Related
is related to SERVER-12359 Compacting blocks "admin" db authenti... Closed
Operating System: Linux
Steps To Reproduce:

1) compact a db
2) use another shell and try to connect to another db to see db.currentOp()

Participants:

 Description   

Can't connect to mongod when another DB is being compacted (v2.2.x)

Mongo's doc states out that Mongo v2.2 (and newer) allows to open another shell in order to view the current ops even though another database is being compacted:

http://docs.mongodb.org/manual/reference/command/compact/
"You may view the intermediate progress [...] by running the db.currentOp() in another shell instance."

However, it seems that the whole mongod is blocked and not only the database which is being compacted.
In my case, I was compacting the database "offerStore". Then I wanted to see the current ops by connecting in another shell to another DB ("admin"):

> mongo s131:27018/admin -u XXX -p XXX

However, the mongo shell was blocked until the compact was terminated!
The logs show this as well:

Mon Jun 24 14:46:49 [initandlisten] connection accepted from 192.168.200.31:35323 #4425462 (681 connections now open)
Mon Jun 24 14:46:49 [conn4425462]  authenticate db: admin { authenticate: 1, nonce: "4b8be295eacec496", user: "admin", key: "970e8ac6c6e9de71b704c297c653c917" }
...
Mon Jun 24 14:53:28 [conn4425462] command admin.$cmd command: { authenticate: 1, nonce: "4b8be295eacec496", user: "admin", key: "970e8ac6c6e9de71b704c297c653c917" } ntoreturn:1 keyUpdates:0 locks(micros) r:157023 reslen:82 398960ms
...
Mon Jun 24 14:53:28 [conn4425462] SocketException handling request, closing client connection: 9001 socket exception [2] server [192.168.200.31:35323]

As you can see, I wanted to connect at 14:46:49. I closed the shell after some minutes because it was blocked. After compaction at 14:53:28, mongo tried to auth again and closed the connection since my shell was closed already.

Should I open a bug report?

How can one see the progress of compaction programmatically (means not by the log-files).

My mongod version is 2.2.3.
My Mongo shell version is 2.2.1.



 Comments   
Comment by Kay Agahd [ 05/Dec/13 ]

Please reopen the task. In v2.4.6 it happened again. One can't access a database while another db is being compacted.

Comment by Ian Whalen (Inactive) [ 25/Jun/13 ]

no problem, kay.agahd@idealo.de. just add a comment if you can reproduce.

Comment by Kay Agahd [ 24/Jun/13 ]

My last assumption was wrong. My current compact process builds the indexes right now and I'm able to connect to the admin db.

I don't know why my first attempt didn't work (see above). It would be nice to know a comprehensible explanation.

You might close this issue. I'll reopen it when it happens again.

Comment by Kay Agahd [ 24/Jun/13 ]

It might be that this only happens at the end of a compaction process (when the indexes are being rebuilt) because I tried the same operation on another node and I could connect to the admin db just after having started the compact process.

If this is the case, it should at least be mentioned in the doc because rebuilding indexes might be a long task on big db's during which it won't be possible to connect and read-out the current ops.

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