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> 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> 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