Re: 100% failover + replication solution

Moiz,

Hmmmm, I think pg_controldata output might help you there to get these
stats.

pg_controldata can be found in the PostgreSQL /bin folder.

Thank you,
---------
Shoaib Mir
EnterpriseDB (www.enterprisedb.com)

On 10/31/06, Moiz Kothari <moizpostgres(at)gmail(dot)com> wrote:
>
> 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
> > >
> >
> >
>