Comments on: The Multimaster Replication Problem

By: Federico

Federico — Sat, 03 Jan 2009 19:40:30 +0000

But then, based on what you are saying, applications like Torque, Hibernate, Propel and Doctrine violate the SoC principle because they spread work between two or more slave databases, something that a load balancer should be doing?

By: Volkan YAZICI

Volkan YAZICI — Sat, 03 Jan 2009 18:50:51 +0000

Hi Federico,

I don’t want to sound like an RDBMS zealot, but from same perspective, replication could (and should?) be integrated into the application too.

I read your reply 3-4 times and everytime sentences like “application does …”, “application needs to …”, etc. take into my attention. That’s exactly what I was trying to avoid. Application just should do its application logic job, as database just should do its persistency job. High-availability, load-balancing? Let them appear as medium layers between those components. Apples in one hand, and oranges in the other. OTOH, I don’t claim such a scheme will bring less pain. But considering SoC, this obstacle will be negligible.

By: Federico

Federico — Sat, 03 Jan 2009 17:24:36 +0000

Hi Volkan,

I don’t agree with you and here’s why. You are saying that it’s a sign of bad design if the application is concerned with the availability of a database. But, that’s exactly what the application does with the slaves, it checks the availability of a database before moving to the next one. This means that the application is ready to handle a slave failover. And that’s a sign of good design. Of course, adding support for multiple slaves instead of a single VIP is more work, but like you said, it’s not rocket science, and that’s why all the applications are doing it. The concept behind multiple slaves and masters is the same. If you have 2 VIPs, 4 master set of clusters and one of the proxies goes down, your application needs to select a different VIP, otherwise your system becomes unavailable.

By: Volkan YAZICI

Volkan YAZICI — Sat, 03 Jan 2009 14:28:10 +0000

I’m quite declined to implement database load-balancing and high-availability in the application layer, and I think it is a sign of poor design. Yes, in case of a database proxy (e.g. sequoia, pgpool) there appears a single point of failure dilemma (actually, there are high-availability solutions for sequoio, pgpool, etc.), but, IMHO, this problem has a lower priority than seperation-of-concerns principle in such complex application frameworks you mentioned. Neither application should be concerned with the availability of the database system, nor the database system should be concerned with the application logic — except determining access patterns, caching related studies, etc.

OTOH, consider this situation: In one of your web tiers you find out that X database host is down. How will you propogate this information to other web tiers? This is not rocket science, but it needs a considerable amount of work in the application code, which I think quite unnecessary and brings potential critical control flow bugs with itself. (Actually, this problem can be solved using some sorf of messaging infrastructure (e.g. AMQP) but this solution is almost identical to using a database proxy, completing the cycle.)

By: Federico

Federico — Fri, 02 Jan 2009 21:11:56 +0000

That’s right, that’s what they are doing. It’s a very straight forward solution. Solar’s database access layer looks good. It’s simple and powerful. My e-mail is: fedecarg at gmail dot com. Thanks.

By: Göks

Göks — Fri, 02 Jan 2009 12:46:44 +0000

@Frederico
I can send you a Digg like solution if you send me your email address. Can’t find one on the blog :/

But if I am right Digg’s solution is not a failover if a master goes down. It is selecting randomly from a pool of (in Sync) slave servers, like the code I have to offer.

By: Jeff

Jeff — Fri, 02 Jan 2009 01:22:26 +0000

Wouldn’t it be nice to get a peek at Digg’s code, eh? ;)