Message-ID: <4C3B3EBE.9070205@2ndquadrant.com>
Date: Mon, 12 Jul 2010 12:11:42 -0400
From: Greg Smith <greg@2ndquadrant.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: Thomas Kellerer <spam_eater@gmx.net>
CC: pgsql-admin@postgresql.org
Subject: Re: High Availability: Hot Standby vs. Warm Standby
References: <i172f8$kug$1@dough.gmane.org> <4C386B33.8090708@2ndquadrant.com>
	<i1eefg$je9$1@dough.gmane.org>
In-Reply-To: <i1eefg$je9$1@dough.gmane.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Thomas Kellerer wrote:
> The manual lists three possible solutions to HA: shared disk failover, 
> file system replication and Warm/Hot Standby. I'm not an admin (nor a 
> DBA), so my question might sound a bit stupid: from my point of view 
> solutions using shared disk failover of file system replication seem 
> to be more reliable in terms of how much data can get lost (and 
> possibly the switch over lag)

Yes, but if you try you'll discover that actually getting any shared 
disk or file system replication solution setup so that you really do 
achieve less failover loss than the file shipping approach will be 
expensive, complicated, fragile in its own way, and just generally a 
pain to pull off.  The fundamental problem with shared storage for 
example is how to keep a note that's failed from try to reassume being 
the master when it comes back.  Doing that well requires hardware 
support aimed at that specific use case. 

Meanwhile, file shipping for Warm Standby use requires nothing special 
at all except some modest software setup.  It's comparatively simple to 
setup, validate, and keep going on any hardware capable of running the 
database.  This is why shared storage and the like isn't the only 
obvious solution even though it's technically capable of losing less 
transactions; you'll discover that keeping from losing that last little 
bit of data when there's a crash turns out to be quite expensive.  
Whether it worth it or not depends on the value of your data and whether 
it can be retained at some higher level when this happens instead.

-- 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us