Re: 100% failover + replication solution

Shoaib,

I see you are with enterprise DB, does enterpriseDB support clustering? if
it does then probably i can think in terms of it to be an option to go for.

I need to come to a decision soon on it as we have to decide on what
Database to go for.

Thanks for all your help.

Regards,
Moiz Kothari

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
> > > >
> > >
> > >
> >
>