MongoDB vs. Clustrix: Fault Tolerance and Availability • Hacker News Board

Re: MongoDB vs. Clustrix: Fault Tolerance and Availability

#21

Post by sergei » Wed, Feb 02, 2011, 8:18 PM UTC

knbanker wrote: post #19

sergei wrote: post #18

Earlier quoted context omitted.

1. Say I have a 2 node replica set. Now a replica dies, permanently. How is the recovery automated? These are quotes directly from your docs: http://www.mongodb.org/display/DOCS/Resyncing+a+Very+Stale+R... "1. Delete all data. If you stop the failed mongod, delete all data, and restart it, it will automatically resynchronize itself. Of course this may be slow if the database is huge or the network slow. 2. Copy data…

1. You really need a minimum of three replica set nodes, one of which can be a lightweight arbiter. If the primary fails, the secondary node will be promoted to primary automatically. In the case of a network partition, the old primary will come back up as a secondary with no problems. In the case of a true hardware failure, you can resync very quickly from a snapshot. For extra peace of mind, add more nodes to the r…

1. Yes, I recognize that MongoDB will automatically fail over when we go from N nodes in the set to N - 1. But how do I get back to N nodes? That's completely manual.

2. What happens when I read an update that succeeded on the master but then later fails on the slaves?

Re: MongoDB vs. Clustrix: Fault Tolerance and Availability

#22

Post by knbanker » Wed, Feb 02, 2011, 8:47 PM UTC

sergei wrote: post #21

knbanker wrote: post #19

Earlier quoted context omitted.

1. You really need a minimum of three replica set nodes, one of which can be a lightweight arbiter. If the primary fails, the secondary node will be promoted to primary automatically. In the case of a network partition, the old primary will come back up as a secondary with no problems. In the case of a true hardware failure, you can resync very quickly from a snapshot. For extra peace of mind, add more nodes to the r…

1. Yes, I recognize that MongoDB will automatically fail over when we go from N nodes in the set to N - 1. But how do I get back to N nodes? That's completely manual. 2. What happens when I read an update that succeeded on the master but then later fails on the slaves?

1. It depends on how the node fails. If there's just a network partition, then you still have N nodes, so no issues. If you're running with durability enabled, and you experience, say, a power outage, then the member should rejoin the set and resync with no issues. If a node's drive crashes, then you'll need to restore from a recent snapshot (within a day or so) or perform a complete resync if you don't have snapshot. But this can all be done without taking the replica set offline. In that last case, there is some manual work involved. But your post, unless you've corrected it, implies that replica set failover is completely manual. That's certainly not true.

2. Outside of some kind of hardware failure, you won't have situations where writes succeed on the primary but fail on a secondary. And as I stated on your blog post, if you're really concerned about it, you can specify a write concern on insert, and if the write fails to replicate in the desired way, you'll know about it.

Re: MongoDB vs. Clustrix: Fault Tolerance and Availability

#23

Post by jeremymcanally » Thu, Feb 03, 2011, 2:40 AM UTC

AndrewO wrote: post #17

smanek wrote: post #12

Earlier quoted context omitted.

Can you name some of the mistakes/omissions he made in the last article? It didn't seem too far off my (admittedly extremely limited) experience.

In the discussion of the previous article posted a couple of days ago, a lot of people complained that he initially didn't provide source code of the tests or go into details about the Mongo's configuration. Some felt that as someone who's worked with internals of RDBMS's, it wouldn't be fair to compare something he knows intimately with something he just learned and didn't spend any time optimizing. After he posted…

Yup, (nearly) all of those points are valid.

He could have gotten comparable performance by simply turning of safe writes, but the commenters point out a lot of other problems with his original assertions.

Re: MongoDB vs. Clustrix: Fault Tolerance and Availability

#24

Post by sergei » Thu, Feb 03, 2011, 6:06 AM UTC

knbanker wrote: post #22

sergei wrote: post #21

Earlier quoted context omitted.

1. Yes, I recognize that MongoDB will automatically fail over when we go from N nodes in the set to N - 1. But how do I get back to N nodes? That's completely manual. 2. What happens when I read an update that succeeded on the master but then later fails on the slaves?

1. It depends on how the node fails. If there's just a network partition, then you still have N nodes, so no issues. If you're running with durability enabled, and you experience, say, a power outage, then the member should rejoin the set and resync with no issues. If a node's drive crashes, then you'll need to restore from a recent snapshot (within a day or so) or perform a complete resync if you don't have snapshot…

Sorry, but "hardware failure" is a fault, and when you can't deal with it, you're not tolerant. And with larger clusters, you see hardware faults on a regular basis. So saying we're ok in the nominal mode is not fault tolerance.

Re: MongoDB vs. Clustrix: Fault Tolerance and Availability

#25

Post by lucisferre » Mon, Feb 07, 2011, 7:49 AM UTC

Loic wrote: post #8

lucisferre wrote: post #4

Earlier quoted context omitted.

I haven't read their analysis yet (I will try to when I have some free time), but in general, I would argue that trying to compare a document database to a SQL one is always going to be somewhat misleading. I'd care more if they were comparing Clustrix to MSSQL, MySQL, PostgreSQL. If you are using MongoDB in a way that is similar to the way you would have used a SQL DB you are probably doing something wrong. Specific…

Please do not comment without reading the article . You do not even have the word SQL in it. Sergei is addressing the different approaches to achieve Consistency/Availability and Performance between their solution and MongoDB. A good read and I must say, I would really love to have more details and more general overview of their algorithms. They could be used for other problems. Note that I am a huge fan of MongoDB a…

Sorry your comment is entirely confounding. What do you mean by "You do not even have the word SQL". Are you suggesting Clustrix does not support structured query language or is non-relational?