Replication - MongoDB in Action - page 169

the new primary. The problem here is that the old primary has a series of writes that
don't exist in the new primary's oplog. This situation triggers a rollback.
In a rollback, all writes that were never replicated to a majority are undone. This
means that they're removed from both the secondary's oplog and the collection
where they reside. If a secondary has registered a delete, then the node will look for
the deleted document in another replica and restore it to itself. The same is true for
dropped collections and updated documents.
The reverted writes are stored in the rollback subdirectory of the relevant node's
data path. For each collection with rolled-back writes, a separate BSON file will be cre-
ated whose filename includes the time of the rollback. In the event that you need to
restore the reverted documents, you can examine these BSON files using the bsondump
utility and manually restore them, possibly using mongorestore .
If you ever find yourself having to restore rolled-back data, you'll realize that this is
a situation you want to avoid, and fortunately you can to some extent. If your applica-
tion can tolerate the extra write latency, you can use write concern, described later, to
ensure that your data is replicated to a majority of nodes on each write (or perhaps
after every several writes). Being smart about write concern and about monitoring of
replication lag in general will help you mitigate or even avoid the problem of rollback
altogether.
In this section you learned perhaps a few more replication internals than expected,
but the knowledge should come in handy. Understanding how replication works goes
a long way in helping you to diagnose any issues you may have in production.

8.2.3 Administration

For all the automation they provide, replica sets have some potentially complicated
configuration options. In what follows, I'll describe these options in detail. In the
interest of keeping things simple, I'll also suggest which options can be safely ignored.

C ONFIGURATION DETAILS
Here I present the mongod startup options pertaining to replica sets, and I describe the
structure of the replica set configuration document.

Replication options
Earlier, you learned how to initiate a replica set using the shell's rs.initiate() and
rs.add() methods. These methods are convenient, but they hide certain replica set
configuration options. Here you'll see how to use a configuration document to initi-
ate and update a replica set's configuration.
A configuration document specifies the configuration of the replica set. To create
one, first add a value for _id that matches the name you passed to the --replSet
parameter:

> config = {_id: "myapp", members: []}
{ "_id" : "myapp", "members" : [ ] }
The individual members can be defined as part of the configuration document as
follows: