Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

For a production sharded MongoDB installation we need 3 configuration servers. According to the documentation "the config server mongod process is fairly lightweight and can be ran on machines performing other work". However, in the default configuration, they all have journalling enabled, and with preallocation this takes up 3 GB of disk space. I assume that the actual data and transaction volume of a config server is quite small, so that this seems a bit too much.

Is there a way to (safely!) run these config servers with much less disk use for the journal? Do I need journalling at all on config servers? Can I set the journal size to be smaller?

share|improve this question
add comment

3 Answers

Yes - there is a way to minimize the default size of the journal files, subject to a couple of caveats. From the MongoDB configuration documentation:

To reduce the impact of the journaling on disk usage, you can leave journal enabled, and set smallfiles to true to reduce the size of the data and journal files.

Here is the smallfiles config information:

Set to true to modify MongoDB to use a smaller default data file size. Specifically, smallfiles reduces the initial size for data files and limits them to 512 megabytes. The smallfiles setting also reduces the size of each journal files from 1 gigabyte to 128 megabytes.

Use the smallfiles setting if you have a large number of databases that each hold a small quantity of data. The smallfiles setting can lead mongod to create many files, which may affect performance for larger databases.

share|improve this answer
add comment

You can some members, of replication, use journaling and others not. [1]

You can set the jounral size to be smaller by using the command line "--smallfiles". [2]

share|improve this answer
    
And is any of this recommended? –  Thilo Nov 10 '11 at 2:03
    
MongoDB does pre-allocation with journal files to avoid having to waste time with it later. If you are worried about disk space more than performance, it is an option. I would recommend leaving journaling on with all machines, you never know when and how a crash might happen. You can never be too safe. –  Nican Nov 10 '11 at 6:22
    
That is of course a good guideline. But inquiring minds want to know if a config server has a transaction volume that needs 3GB of journals, and if there is any benefit to having journals at all other than faster startup time after a crash (note that with 3 config servers, there should not be any data loss, even without journaling, right?) And how much faster anyway with the small amount of config-only data. It seems to me that the rules here should be different for replica nodes and config servers. The docs say that "you should be fine if you can recover one of them within a day" for example. –  Thilo Nov 10 '11 at 8:48
add comment

You can start mongod with the --nojournal option, but I would be very certain about your config server backups.

share|improve this answer
1  
How much more certain do I need to be than having three config servers on three different machines? Also, what is the procedure for making backups of the config server? If I do not backup after every change (say collection added or sharding event), then I cannot recover from these outdated backups, right? –  Thilo Nov 10 '11 at 23:08
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.