MongoDB instances and oplog
I would like to create a replica-set with oplog


As per MongoDB Documentation sources from MongoDB IN ACTION The Replica sets rely on two basic mechanisms: an oplog and a heartbeat. The oplog enables the replication of data, and the heartbeat monitors health and triggers failover.

At the heart of MongoDB’s replication stands the oplog. The oplog is a capped collection that lives in a database called local on every replicating node and records all changes to the data. Every time a client writes to the primary, an entry with enough information to reproduce the write is automatically added to the primary’s oplog.Once the write is replicated to a given secondary, that secondary’s oplog also stores a record of the write. Each oplog entry is identified with a BSON timestamp, and all secondaries
use the timestamp to keep track of the latest entry they’ve applied.

Applications sometimes query secondary nodes for read scaling. If that’s happening, this kind of failure will cause read failures, So it’s important to design your application with failover in mind.

let’s look more closely at a real oplog and at the operations recorded in it.
First connect with the shell to the primary node and switch to the local database.

amj:PRIMARY&gt; use local
switched to db local


The local database stores all the replica set metadata and the oplog. Naturally, this database isn’t replicated itself. Thus it lives up to its name; data in the local database is supposed to be unique to the local node and therefore shouldn’t be replicated.If you examine the local database, you’ll see a collection called oplog.rs, which is where every replica set stores its oplog. You’ll also see a few system collections. Here’s the complete output:

amj:PRIMARY&gt; show collections
me
oplog.rs
replset.minvalid
slaves
startup_log
system.indexes
system.replset


replset.minvalid contains information for the initial sync of a given replica set member, and system.replset stores the replica set config document. Not all of your mongod servers will have the replset.minvalid collection. me and slaves are used to implement write concerns, and system.indexes is the standard index spec container.


  right now only one mongod instance is running on the server, serving
  all applications; should I run different mongod instances (one for
  every application)


I don't think so it's good idea to run different one mongod instance for one application.

For Your Further Ref Here and Here