MongoDB Replication Oplog

Replication uses an operation log ("oplog") to store write operations. These operations replay asynchronously on other nodes. The length of the oplog is important if a secondary is down. The larger the log, the longer the secondary can be down and still recover. Once the oplog has exceeded the downtime of the secondary, there is no way for the secondary to apply the operations; it will then have to do a full synchronization of the data from the primary. By default, on 64 bit builds, oplogs are quite large - perhaps 5% of disk space. Generally this is a reasonable setting. The oplog is a capped collection, and fixed size once allocated. Once it is created it is not easy to change without losing the existing data. This will be addressed in future versions so that it can be extended. The mongod --oplogSize command line parameter sets the size of the oplog. Changing this parameter after the oplog is created does not change the size of your oplog. This collection is named: local.oplog.$main for master/slave replication local.oplog.rs for replica sets

 

文章来源：

 

 http://www.mongodb.org/display/DOCS/Replication+Oplog+Length

 http://www.snailinaturtleneck.com/blog/2011/02/22/resizing-your-oplog/

 http://www.mongodb.org/display/DOCS/Replica+Sets+-+Oplog

 

The MongoDB replication oplog is, by default, 5% of your free disk space. The theory behind this is that, if you’re writing 5% of your disk space every x amount of time, you’re going to run out of disk in 19x time. However, this doesn’t hold true for everyone, sometimes you’ll need a larger oplog. Some common cases:

• Applications that delete almost as much data as they create.
• Applications that do lots of in-place updates, which consume oplog entries but not disk space.
• Applications that do lots of multi-updates or remove lots of documents at once. These multi-document operations have to be “exploded” into separate entries for each document in the oplog, so that the oplog remains idempotent.

If you fall into one of these categories, you might want to think about allocating a bigger oplog to start out with. However, what if your application is already running in production when you realize you need a bigger oplog?

If you’re on 1.6, you’ll need to switch to 1.7 for parts of this. I’ve noted the switch points with asterisks. Hover over the asterisks to see the instructions: ***. If you’re already running 1.7, you can ignore the asterisks.

Usually if you’re having oplog size problems, you want a larger oplog on the master. To get this fixed, shut down the master. Restart it without the --replSet option on a different port. So, for example, if I was starting MongoDB like this:

$ mongod --replSet foo # default port

I would restart it with:

$ mongod --port 10000

Now, connect to it with the shell and drop the local.oplog.rs collection, and recreate it to be the size that you want:

$ mongo localhost:10000/local
MongoDB shell version: 1.8.0-rc0-pre-
connecting to: localhost:10000/local
> db.oplog.rs.drop()
true
> // size is in bytes
> db.runCommand({create : "oplog.rs", capped : true, size : 1900000})
{ "ok" : 1 }

Now shut down the database and start it up again*** with --replSet and --fastsync. If you start it up without --fastsync, it will have to resync everything from the current primary. With --fastsync, it will just copy over the current oplog, meaning it will get up-to-date with any operations that happened while it was down without resyncing everything.

Once you see the log message that the initial sync has finished***, connect to the current primary and ask it to step down so you can have your old primary back.

> rs.stepDown()
// you'll get some error messages because reconfiguration
// causes the db to drop all connections

Your oplog is now the correct size.

 

Edit: as Graham pointed out in the comments, you should do this on each machine that could become primary.