Database Reference
In-Depth Information
The first field, ts , stores the entry's BSON timestamp. Pay particular attention here;
the shell displays the timestamp as a subdocument with two fields, t for the seconds
since epoch and i for the counter. This might lead you to believe that you could query
for the entry like so:
db.oplog.rs.findOne({ts: {t: 1296864947000, i: 1}})
In fact, this query returns null . To query with a timestamp, you need to explicitly con-
struct a timestamp object. All the drivers have their own BSON timestamp construc-
tors, and so does JavaScript. Here's how to use it:
db.oplog.rs.findOne({ts: new Timestamp(1296864947000, 1)})
Returning to the oplog entry, the second field, op , specifies the opcode. This tells
the secondary node which operation the oplog entry represents. Here you see an i ,
indicating an insert. After op comes ns to signify the relevant namespace (database
and collection) and o , which for insert operations contains a copy of the inserted
document.
As you examine oplog entries, you may notice that operations affecting multiple
documents are analyzed into their component parts. For multi-updates and mass
deletes, a separate entry is created in the oplog for each document affected. For
example, suppose you add a few more Dickens topics to the collection:
> use bookstore
db.books.insert({title: "A Tale of Two Cities"})
db.books.insert({title: "Great Expectations"})
Now with four books in the collection, let's issue a multi-update to set the author's
name:
db.books.update({}, {$set: {author: "Dickens"}}, false, true)
How does this appear in the oplog?
> use local
> db.oplog.$main.find({op: "u"})
{ "ts" : { "t" : 1296944149000, "i" : 1 }, "op" : "u",
"ns" : "bookstore.books",
"o2" : { "_id" : ObjectId("4d4dcb89ec5855af365d4283") },
"o" : { "$set" : { "author" : "Dickens" } } }
{ "ts" : { "t" : 1296944149000, "i" : 2 }, "op" : "u",
"ns" : "bookstore.books",
"o2" : { "_id" : ObjectId("4d4dcb8eec5855af365d4284") },
"o" : { "$set" : { "author" : "Dickens" } } }
{ "ts" : { "t" : 1296944149000, "i" : 3 }, "op" : "u",
"ns" : "bookstore.books",
"o2" : { "_id" : ObjectId("4d4dcbb6ec5855af365d4285") },
"o" : { "$set" : { "author" : "Dickens" } } }
As you can see, each updated document gets its own oplog entry. This normalization is
done as part of the more general strategy of ensuring that secondaries always end up
with the same data as the primary. To guarantee this, every applied operation must be
Search WWH ::




Custom Search