Where to store administrative (DBA) data?

Question

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.

Answer 1

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.

Answer 2

I'm not sure if this is the 'right' way or if I'm understanding the question but where I work we store configurations in a parm table.

Example as follows:

CREATE TABLE example_schema.parm_table(
    parm  VARCHAR2(20),
    parm_value VARCHAR2(255)
);

Then say we wanted to store whether or not we wanted the application to start in windowed mode. We would do the following:

INSERT INTO example_schema.parm_table(parm, parm_value)
VALUES('windowed', 'Y');

And then retrieve that particular parm. The thing is all of our applications use the same database. If this is not the case or would not work, you might want to go with the following:

Set up a network share, mount it on each server, and have a .ini file with all your configurations. You might then want to regularly copy the .ini file to the local directory. This would probably be my ideal method. This would work in the case that the network share happened to be down.