Date: Mon, 26 Apr 2004 14:23:36 -0400
From: Andrew Sullivan <ajs@crankycanuck.ca>
To: pgsql-general@postgresql.org
Subject: Re: Replication
Message-ID: <20040426182336.GB28909@phlogiston.dyndns.org>
Mail-Followup-To: pgsql-general@postgresql.org
References: <E6F241DAF915E24F9E34757342EE3E226A8898@ottas09a.ott.signiant.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <E6F241DAF915E24F9E34757342EE3E226A8898@ottas09a.ott.signiant.com>
User-Agent: Mutt/1.5.5.1+cvs20040105i

On Thu, Apr 22, 2004 at 09:42:12AM -0400, Eric Comeau wrote:
> 
> What is Oracle selling as their replication solution these days? 

[. . .]

> Their ORAC if I understand it correctly is a "cluster" solution and 
> no a "replication" solution.

This is an example of why I think most of the discussion about
"replication" is so confusing.  ORAC is certainly a kind of
replication: it provides always-on, hot redundancy in a cluster of
machines.  It's multi-master, and something very close to
asynchronous.  It's a _very_ clever system, but it'll do you not one
whit of good if your primary site fails.  Also, it's not suitable for
use on unreliable hardware: every cluster member failure causes a
"remastering" event which causes everything to stop while remastering
happens.  Finally, it requires some nifty but expensive storage --
storage which itself could be a single point of failure, if it failed
in the right ways.

To solve all of that, Oracle also offers Data Guard.  This is
basically a standard log-shipping technique.  The off-site "standby"
databases can't be used while in standby mode.  This has all the
standard caveats of asynchronous WAN replication, not least of which
is that if you processed a $100 million transaction right before your
master failed, and then you recovered onto a slave which didn't have
that last moment of data, you might find yourself making a $100
million mistake.

So, Oracle Corp offers two different ways to keeo you up nights. :)
I'm sure they're both wonderful products.  But they certainly don't
have a one-size-fits-all approach.

A

-- 
Andrew Sullivan  | ajs@crankycanuck.ca