Blind Alley of Data

December 16th, 2007 by Ralf S. Engelschall

I don’t know whether you once thought about the following interesting fact: many people in the IT are really exited about easy branching in version control, data replication for database/directory systems, hot-standby services in server computing, etc… But wouldn’t you really expect that those people actually better be excited about multi-master support for database/directory systems, real clustering of servers and subsequent branch merging in version control? Do you already see the major difference here? If not, let me describe in more detail why I think people are without any reason excited about blind alley approaches…

Easy Branching vs. Subsequent Branch Merging

In the version control system (VCS) area one often hears that modern VCS implementations like Subversion support the important feature of “easy branching” or even “cheap branching”.

common sociology assignment types
viagra online pharmacy generic

Although it is certainly great that branching became a less expensive operation in modern VCS and one now is encouraged to leverage from branches more often, I’m nevertheless wondering why people get told that they now can “easily branch”, but nobody tells them at the same time that their real problem still is not to be able to “easily branch“, but how to “easily merge“.

cialis cheapest

The merging is what people should get excited about.

Even in Subversion the support for merging is still rather limited. At least in Subversion 1.5 we finally can expect this to change the first time. So, if someone talks about “branching”, tell him that this is just the harmless side of the medal and leads to a blind alley. The real challenge usually is merging to get out of the blind alley again. Just a tip: if you want to see IMHO good branching and merging capabilities have a look for instance at the great Monotone VCS.

Data Replication vs. Multi-Master Support

I was already a dozen times in the situation that someone was excited about the possibility that a directory or database system is able to replicate data to a second instance. For instance, with the OpenLDAP directory server people tell you to replicate data to a secondary server via slurpd(8), with PostgreSQL they tell you to replicate data to a secondary RDBMS via Slony-I, with MySQL they direct you to the NDB Cluster feature, etc. But if one looks carefully at those implementations one recognizes that in practice their approaches are far more waggly solutions than the impression people give you about them. First, it is always a complex task to initially synchronize the master and slave servers. Once you mastered this challenge, the replication usually works fine. But now let the master or slave server crash!

Now in mostly all those systems I ever evaluated it gets really interesting. If the master crashes, the slave usually still can take over the task just fine. But once the master is back, how do you synchronize it again and move the primary service back to it? In mostly all systems you now are forced into a service downtime and manual intervention. Sorry, from my perspective this is not acceptable, because one usually doesn’t want replication and fail-over in just one direction. One usually always wants some sort of bi-directional data synchronization and fail-over capability. This is what people should really get excited about, not the one-way replication and fail-over solution one gets today with most solutions… Or in other words: IMHO you should be better excited about real multi-master approaches instead of all those single-master-multiple-slave solutions…

Hot-Standby Services vs. Real Clustering

A similar experience one receives when it comes to server and service “clustering”. I know that “cluster” is a burned name which means all and nothing in the IT, but for me a “cluster” is a setup of multiple servers which provide services in a seamlessly fail-safe way. But when people tell you about their server computing “cluster” solutions, they most of the time just mean simple Hot-Standby solutions. Sure, those are also nice to have and they are better than nothing. But they are far away from a real “cluster” where one can treat the whole setup as a single logical instance, as here we are faced usually with the single direction fail-over situation and the downtime and manual intervention requirements in case of switching back from the Hot-Standby server again. I’ve only seen a few “real clusters” in my IT life. Most of the “clusters” I get told are IMHO nothing more than rather simple Hot-Standby solutions. They are good to have and better than nothing, of course. But on those one shouldn’t get really excited about…


Just be as skeptic as you can be and don’t be excited too easily about easy branching, rock-solid replication and fail-safe hot-standby solutions. Instead ask whether the solution actually provides you easy and subsequent branch merging, bi-directional replication without manual intervention and seamless multiple-master based clustering. If this is the case, then get excited…

Leave a Reply