Where to store administrative (DBA) data? I am a SQL Server DBA by trade, investigating MongoDB for a project.  One of the conventions we use is to store configuration-style information in a SQLDBA database on each server (index rebuild thresholds, backup exceptions, etc).  

I am wondering if this same technique would be useful here. My question is:


Should/could I use the admin or local database for this information, or should I create a new database to store essentially a single collection and document?
Would this change in a sharded/replica-set environment?


We have a central hub SQL server/database for sure, but we also store some configuration data locally on each server to drive certain processes.  We wouldn't want these to fail because a server couldn't contact the hub.
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 mongod and mongos configuration files.


  Should/could I use the admin or local database for this information?


Each 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 mongod node.