[SERVER-33363] Getting list of connections per database Created: 16/Feb/18 Updated: 16/Oct/19 Resolved: 16/Oct/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Networking |
| Affects Version/s: | 3.6.0 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Bhairav | Assignee: | Benjamin Caimano (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Participants: | |||||
| Description |
|
Hello, Wondering if there is a way to get a list of connections on a per database basis. I've looked into using db.currentOp(true).inprog which list several connections, but does not show which database it is associated with (see below for example).
It would be great to have the database name associated with it (as long as that connection did a 'use' or similar command to connect to it). An even better option would be to list databases (as long as they have live connections) and have the connections listed under their individual names. Thanks. |
| Comments |
| Comment by Benjamin Caimano (Inactive) [ 16/Oct/19 ] |
|
Hey bhairav, it seems that this ticket became untracked when we had a restructuring of teams. Apologies, this is far from ideal. As of v4.0, you can set appName as part of your connection string (see here). This would likely require you to make your own Mongo() client connections or to run one shell process per test suite. The other two options that matt.lord had mentioned are probably outside your control. For example, "client" would require one instance per test or egress redirection, this is non-trivial. That said, we cannot feasibly annotate currentOp() with database info. I am closing this ticket as "Won't Fix". |
| Comment by Bhairav [ 07/Oct/18 ] |
|
Thanks Matt. I can try out the options you suggested. One question though: are the appName and clientMetadata.application.name configurations that can be set in the client connection that is made to the server? In my case, the user, role, application and host are all the same, but if I can set the appName/clientMetadata then I could fake out some unique names that I can use to track on the server side.
Thanks.
|
| Comment by Matt Lord (Inactive) [ 30/Sep/18 ] |
|
Hi bhairav, I apologize for the delay. The issue on our side is that a connection on the server side isn't associated with a database/namespace, as that's set per operation. I wonder if the client metadata in 3.6+ could serve the same underlying purpose even better? With that you could see connection counts by:
So you have information to gauge resource usage by user, role, application, and host. With this in mind, does a count by the last used database/namespace still hold special value? Thanks! |
| Comment by Bhairav [ 24/Mar/18 ] |
|
Thanks Matt. Appreciate you looking into this. My use case is that for every instance of tests I run, I have to create a separate database for them. These simply do insertion of data only. Within these, there may be hundreds of connections per DB. Sometimes, these connections would go away perhaps when a problem happens in environment that kills the connections (temporary network outages or the tests themselves failing). By getting a list (or rather number) of connections to the particular database, the reporting side (which only does the read of the data, and has no view into the insertion processes) could watch for these connections to ascertain whether something has gone wrong or not. I thought of using some kind of keep-alive mechanism that periodically would update a timestamp which the reporting could interpret. However, I thought that since MongoDB already showed total connections, it might be easy for it to provide the specific number of connection per DB. Hence, the ask. Hope that helps. |
| Comment by Matt Lord (Inactive) [ 19/Mar/18 ] |
|
Hi bhairav! Could you comment on the use case(s) or user story here, taking a step back from any potential implementation? What's the business problem you want to solve? For example: "As a DBA, I need to better understand how each schema and its users are impacting the current global maximum connection limit". A database in MongoDB is really just a schema or a namespace. So a connection isn't tightly coupled with it and the current/default namespace is easily crossed (e.g. the db.currentOp() actually executes in the admin database/namespace). I would like to better understand what it is that you hope to do with or glean from this information. That would better help me understand what may be the best way to meet your actual use case and business needs. Thank you for your interest in MongoDB! Best Regards, Matt |