Re: 100% failover + replication solution

Moiz,

Yes, EnterpriseDB is compatible with SLES 10.

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

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