Re: High-availability - Mailing list pgsql-general

From Chander Ganesan
Subject Re: High-availability
Date
Msg-id 46655F35.6040806@otg-nc.com
Whole thread Raw
In response to Re: High-availability  ("Simon Riggs" <simon@2ndquadrant.com>)
List pgsql-general
Simon Riggs wrote:
On Mon, 2007-06-04 at 10:21 -0400, Chander Ganesan wrote:
 
It's not too hard to put together a "warm standby" synchronous
replication mechanism with overhead that isn't too much more than what
you incur by enabling PITR...  Such systems can also have very fast
failover on failure detection (via heartbeat2), and be synchronous.   
Do you have any performance measurements of either the replication
overhead or the failover time? I'm interested in how well we cope with
high transaction rates. Thanks.
 
Aside from a bunch of customized pgbench benchmarks (on the 9.6 GB sample database we use), which are "better than nothing, but far from the best", not really.  In my experience, the larger the database; slower the commit rate; and less frequently the checkpoints - the better the performance of synchronous warm-replication.  In our tests, higher commit rates and more frequent checkpoints incur a higher penalty.  Basically, the more WAL activity the higher the cost.

If I have time I'll see if we can run a more meaningful metric (need to generate a smaller database for that) the next time we have a performance tuning class (in August).

The failover time is tunable to some extent...via heartbeat2 (incurs < 1% performance penalty, but with sub-second failover this can go up a bit), and can be pretty quick (I usually set it up with around a 3 second failover time on node failure, then factor that in with the amount of time required for WAL auto-recovery)...it really depends a lot on what your metric is for "failure" (since node failover is probably the "worst worst case").
-- 
Chander Ganesan
The Open Technology Group
One Copley Parkway, Suite 210
Morrisville, NC  27560
Phone: 877-258-8987/919-463-0999
http://www.otg-nc.com

pgsql-general by date:

Previous
From: Gregory Stark
Date:
Subject: Re: There can be only one! How to avoid the "highlander-problem".
Next
From: Michael Fuhr
Date:
Subject: Re: COPY error