Tag - oplog

Why TokuMX Changed MongoDB’s Oplog Format for Operations

Over several posts, I’ve explained the differences between TokuMX replication and MongoDB replication, and why they are completely incompatible. In this (belated) post, I explain one last difference: the oplog format for operations. Specifically, TokuMX and MongoDB log updates and deletes differently.
Suppose we have a collection foo, with the following element:


rs0:PRIMARY> db.foo.find()
{ “_id” : […]

Read more

On TokuMX Oplog, Tailable Cursors, and Concurrency

In a post last week, I described the difference in concurrency behavior between MongoDB’s oplog and TokuMX’s oplog. In short, here are the key differences:

MongoDB protects access to the oplog with a database level reader/writer lock, whereas TokuMX does not.
TokuMX can write data to the oplog concurrently, whereas MongoDB cannot.
As a result, because a […]

Read more

On TokuMX (and MongoDB) Replication and Transactions

In my last post, I describe the differences between a TokuMX oplog entry and a MongoDB oplog entry. One reason why the entries are so different is that TokuMX supports multi-statement and multi-document transactions. In this post, I want to elaborate on why multi-statement transactions cause changes to the oplog, and explain how we […]

Read more

Comparing a TokuMX and MongoDB Oplog Entry

As I mentioned in my last post, TokuMX replication is completely incompatible with MongoDB replication. Replica sets (and sharded clusters, but that is for another blog) must be either entirely TokuMX or entirely MongoDB. This is by design. While elections and failover are basically the same, we have completely changed the oplog protocol.
In the […]

Read more