From: | Greg Smith <greg(at)2ndquadrant(dot)com> |
---|---|
To: | David Kerr <dmk(at)mr-paradox(dot)net> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Postgres Clustering Options |
Date: | 2009-11-11 18:11:52 |
Message-ID: | 4AFAFE68.60104@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
David Kerr wrote:
> Postgres installed on a Cluster configured in active/passive (both pointing to the same SAN
> (If PG or the OS fails we trigger a failover to the passive node)
> Log shipping between that cluster and a single PG Instance off site.
> Is this a common/reccomended method of handling clusterin with Postgres? google searches
> basically point to using a replication based solution, which i don't think would meet my
> performance demands.
>
The part I'm having trouble with here is how it is you expect to keep a
remote node up to date with log-shipping, but then reject log-shipping
based replication as not high enough performance for you? The classic
problem with log-shipping in PostgreSQL is that you've got a single
recovery process trying to replay the work of what many workers did on
the master, and that can turn into a potential lag problem as volume
spikes upwards. If you don't expect a standby is going to be able to
keep up with your volume due to that issue, the remote one is going to
be even worse though.
--
Greg Smith greg(at)2ndQuadrant(dot)com Baltimore, MD
From | Date | Subject | |
---|---|---|---|
Next Message | David Kerr | 2009-11-11 18:13:05 | Re: Postgres Clustering Options |
Previous Message | Greg Smith | 2009-11-11 18:05:58 | Re: Postgres Clustering Options |