Re: 7.4?

From: "Ed L(dot)" <pgsql(at)bluepolka(dot)net>
To: Andrew Sullivan <andrew(at)libertyrms(dot)info>, PostgreSQL General <pgsql-general(at)postgresql(dot)org>
Subject: Re: 7.4?
Date: 2003-02-27 19:00:50
Message-ID: 200302271200.50272.pgsql@bluepolka.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thursday February 27 2003 6:36, Andrew Sullivan wrote:
> On Wed, Feb 26, 2003 at 02:41:10PM -0700, Ed L. wrote:
> > I also share the objectives of reliability/redundancy. My
> > concern with syncronous solutions in general is recoverability
> > when one of two masters fails. Admittedly at the price of
> > intervals of data inconsistency between master and slave, async
> > solutions can just pop back online and "catch-up", thus the
> > appeal. In reading a little
>
> It seems to me that this answer is only true if you can tolerate
> loss or delay of transactions. That is, if the order of
> transactions matters, you really can't just make your former slave
> a master without knowing that the failed master has sent everything
> to the slave.

Agreed. In our case, we presently have _no_ replication solution nor
do we have a true file system snapshot capability e.g. NetApp. So,
in the event of the untimely total demise of the primary server, the
timespan of data loss equals time since the last dump that made it
off the server. That typically amounts to _hours_. With async
replication to a spare server, that couple of hours of lost data
would seem to be reduced to seconds. That's not ideal by any
stretch, but is a monstrous improvement. I'm assuming eRServer,
rserv, or DBMirror maintains a proper transaction order, even if it's
incomplete.

> If order matters, then the opposite is true: because you know that
> any master has all the data, you can just accept it when one master
> goes away. Of course, that requires a good program for adding new
> replicated systems, which I guess is what Postgres-R is going to
> do.

Agreed. It also requires a good program for dealing with failed
masters and dealing with sync performance issues (2-phase commit).
Sounds like PG-R + Spread is tackling that, too. I am learning that,
if PG-R can work as advertised, it removes all my concerns about a
syncronous system.

My current thinking is to implement simple async master/slave now,
with the acknowledged potential data loss (albeit much smaller), and
migrate to sync multi-master if/when PG-R comes online. I had little
success with rserv, but DBMirror worked ok. I'm enhancing DBMirror
up to work better for our environment.

Ed

In response to

  • Re: 7.4? at 2003-02-27 13:36:41 from Andrew Sullivan

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jon Swinth 2003-02-27 19:27:54 Re: Help! I don't get mail anymore
Previous Message Greg Stark 2003-02-27 18:41:33 Optimizer going cuckoo for full table scans