Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I don't want to rent another server...

But wikipedia says:

MongoDB should never be deployed on fewer than two servers[citation needed]: a master and a slave. A master can perform reads and writes. A slave copies data from the master and can only be used for reads or backup (not writes).

share|improve this question
up vote 3 down vote accepted

That's quite outdated. With 1.8 you have single node durability, see --journal.

share|improve this answer
That does not protect you from a disk crash on that single server, though. Replication among two servers is still safer. – Thilo Nov 10 '11 at 2:00

With the current release, you can indeed use a single server thanks to Journaling. Technically you always could use only one server, however, due lack of journaling, your database could become corrupted.

A word of advice. create a replica set on your single server with. You can create multiple mongo instances on one machine. You can create a primary (master), secondary (slave), and a arbiter. This way you can shut down the slave on occasions and copy the DB files for backups, and if for some reason one of the other processes gets shut down, your app will still be able to connect to the DB.

share|improve this answer

I think the new recommended environment for mongo in production involves "replica sets", which is actually at minimum three servers. If the primary server goes down, the other two servers elect one of them to take over. When the original primary comes back online, another election is held, and a new primary is selected.

I'm not sure if master-slave is deprecated, but I think if you're building mongo fresh, you should consider building a replica set.

If you really don't want more servers, then you may consider running all secondaries side-by-side on the same server as the primary (but on different ports). However, this isn't very redundant.

share|improve this answer

I think it depends on the use that you need to do of the mongodb...

The reason of the wikipedia suggestion is that with mongoDb (until version 1.3.1) you couldn't make a backup without sopping the database first.

From 1.3.1 onward you can do a backup locking writes :

MongoDB v1.3.1 and higher supports an fsync and lock command with which we can flush writes, lock the database to prevent writing, and then backup the datafiles.

While in this locked mode, all writes will block. If this is a problem consider one of the other methods below.

If you have high usage of your application with many accesses deploying on two server it's the better way, whereas instead you have an application that is used only during the day, you could stop or lock the database, make a backup, then restart or unlock in the nightly hours ...

share|improve this answer

Your Answer


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.