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
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 […]
MongoDB replication has some great features. As I discussed in my last post, MongoDB’s crash safety design is very elegant. In addition to that, MongoDB has automatic failover, parallel slave replication, and prefetch threads on secondaries. The latter, as Mark Callaghan points out, is similar to “InnoDB fake changes”, a feature that has helped […]Read more
At an extremely high level, replication in MongoDB and MySQL are similar. Both databases have exactly one machine, the primary (or master), that accepts writes from clients. With a single transaction (or atomic operation, in MongoDB’s case), the tables and oplog (or binary log in MySQL) are modified to reflect the change. The log […]Read more
It may be easy to choose a NoSQL database, but do you know which distribution is best for you? Which will perform better? Which will scale further? Look before you leap.
SPEAKER: John Schulz
DATE: Wednesday, March 5th
TIME: 1pm ET
AOL, the well-known mass media corporation, asked themselves these questions and ran […]