I am wondering if this same technique would be useful here.
Since MongoDB is a distributed database, nodes tend to be part of a larger deployment (replica set or sharded cluster) where configuration differences in individual nodes are usually managed externally. For example, using Configuration Management software like Chef or Puppet to generate
mongos configuration files.
Should/could I use the admin or local database for this information?
mongod node has a
local database which is used for storing node-specific administrative or logging data such as the
startup_log (a capped collection recording history of startup parameters and versions) and
oplog.rs (the replication oplog).
You could store node-specific information in the
local database, but I think it would make more sense to use a normal collection in your deployment in order to coordinate maintenance tasks and availability. Aside from backup, there aren't many node-specific maintenance tasks that should be performed without manual intervention.
or should I create a new database to store essentially a single collection and document?
If you do find the need for node-specific tasks I imagine your maintenance database would have more than a single collection and document. For example, you might have a configuration document per node and perhaps other collections such as a history of maintenance tasks. Capped collections can be useful for storing a rolling snapshot of "recent" activity using a preset storage allocation.
Would this change in a sharded/replica-set environment?
Assuming the details are node-specific, there would be no change in a sharded or replica set environment if you are accessing data in the
local database. The contents of the
local database are excluded from replication/sharding and you should only access the
local database by connecting directly to a