Re: 100% failover + replication solution

Shoaib,

Also just so you know, we plan to use SLES 10 OS. so also let me know the
compatibility of EnterpriseDB to the OS.

Regards,
Moiz

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