Re: 100% failover + replication solution

Shoaib,

This sounds really like what i need, but again 8.2 is in beta.

Just one question, i dunno if i am thinking in right direction, but is there
anyway of finding out the END XID, transaction id and OID of last archived
WAL log applied to the database. I was thinking if i can get that value then
i can reset XLOGs using pg_resetxlog to that point and then start applying
the new WAL logs. Am i thinking it correctly or there is some flaw here.

Also if i am thinking it right, then how can i find the details i asked
above.

Regards,
Moiz Kothari

On 10/30/06, Shoaib Mir <shoaibmir(at)gmail(dot)com> wrote:
>
> 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
> >
>
>