Re: 100% failover + replication solution

Hi Moiz,

This might help you :) -->
http://developer.postgresql.org/pgdocs/postgres/warm-standby.html

Thanks,
-------
Shoaib Mir
EnterpriseDB (www.enterprisedb.com)

On 10/30/06, Andrew Sullivan <ajs(at)crankycanuck(dot)ca> wrote:
>
> On Mon, Oct 30, 2006 at 06:41:54PM +0530, Moiz Kothari wrote:
> > I agree that PGCluster might be a better option, i dont want to go with
> > Slony because of primary key constraints.
>
> I don't know what the "primary key constraints" issue you have is,
> but Slony would be inappropriate for a "100% failover" system anyway:
> you can't know you haven't trapped data on the origin. This is in
> fact true for the WAL shipping you suggested, also. The only way to
> achieve 100% reliable failover today, with guaranteed no data loss,
> is to use a system that commits all the data on two machines at the
> same time in the same transaction. I haven't seen any argument so
> far that there is any such system "out of the box", although with two
> phase commit support available, it would seem that some systems could
> be extended in that direction.
>
> The other answer for all of this is to do it with hardware, but
> that's a shared-disk system, so if your disk blows up, you have a
> problem. Or, if you're using the operating system of people who
> don't know how fsck works. I don't know anyone who has that problem;
> certainly not any vendors whose name starts with 'I' and ends with
> 'M'.
>
> > 1) It might slow down the process a bit. as confirmation happens after
> > transaction gets comitted to all the nodes.
>
> Anyone who tells you that you can have completely reliable data
> replication with no performance hit is trying to sell you a bridge in
> Brooklyn. If you want reliable data replication that guarantees you
> can have automatic failover, you are going to pay for it somehow; the
> question is which compromise you want to make. That seems to be
> something you'll need to decide.
>
> > 2) Its difficult to convince, as it is an external project and if
> support
> > for the same stops or future versions of postgres does not work, it
> might be
> > a problem.
>
> If you have this problem, probably free software isn't for you.
> PostgreSQL is a modular system, and people use different components
> together in deployed systems. This happens to be true of commercial
> offerings too (if not, you could buy the cheapest version of, say,
> Oracle and get RAC in the bargain), but they _sell_ it to you as
> though it were one big package. To the extent your managers don't
> understand this, you're always going to have a problem using free
> software.
>
> A
> --
> Andrew Sullivan | ajs(at)crankycanuck(dot)ca
> In the future this spectacle of the middle classes shocking the avant-
> garde will probably become the textbook definition of Postmodernism.
> --Brad Holland
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>