On Mon, 2007-11-26 at 12:39 -0500, Chris Browne wrote:
> [EMAIL PROTECTED] ("Jeff Larsen") writes:
> Unfortunately, the only way to make things deterministic (or to get
> from "near real time" to "*GUARANTEED* real time") is to jump to
> synchronous replication, which is not much different from 2P
> Sorry, this makes no sense to me -- EnterpriseDB has no replication
> solution that I know of.
slony is bundled with the database
>> Postgres-r sounds very nice but moving our organisations data onto a
>> system that it work in progress is very scary.
>
> You are already offloading your data to
> So what is the state-of-the-art in the Postgresql world if I _do_ want
> synchronous replication? 2-phase commit from the client application? Any
> success/horror stories about doing it in Java?
For Java, you could check out Sequoia (http://sequoia.continuent.org/) or
their commercial version un
On Nov 26, 2007, at 3:21 PM, Chris Browne wrote:
[EMAIL PROTECTED] (Erik Jones) writes:
Since no one's mentioned it, and while I don't have any personal
experience with it, I thought I'd mention the recently released
Bucardo (http://bucardo.org/) as another Postgres replication option.
It's
[EMAIL PROTECTED] (Glyn Astill) writes:
> It it possible to get a system that does syncronous replication and
> also allows slaves to catch up if they're down for a period of time
> like you can with asyncronous?
Well, a "modal approach" is possible - that's what Postgres-R tries to
do.
Of course
[EMAIL PROTECTED] (Erik Jones) writes:
> Since no one's mentioned it, and while I don't have any personal
> experience with it, I thought I'd mention the recently released
> Bucardo (http://bucardo.org/) as another Postgres replication option.
It's Yet Another Asynchronous Replication System, ergo
On Nov 26, 2007 3:41 PM, Garber, Mikhail <[EMAIL PROTECTED]> wrote:
>
> So what is the state-of-the-art in the Postgresql world if I _do_ want
> synchronous replication? 2-phase commit from the client application? Any
> success/horror stories about doing it in Java?
Depending on the restrictions
So what is the state-of-the-art in the Postgresql world if I _do_ want
synchronous replication? 2-phase commit from the client application? Any
success/horror stories about doing it in Java?
---(end of broadcast)---
TIP 6: explain analyze is your
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 26 Nov 2007 12:39:42 -0500
Chris Browne <[EMAIL PROTECTED]> wrote:
> Unfortunately, the only way to make things deterministic (or to get
> from "near real time" to "*GUARANTEED* real time") is to jump to
> synchronous replication, which is no
Since no one's mentioned it, and while I don't have any personal
experience with it, I thought I'd mention the recently released
Bucardo (http://bucardo.org/) as another Postgres replication option.
Erik Jones
Software Developer | Emma®
[EMAIL PROTECTED]
800.595.4401 or 615.292.5888
615.292.
On Mon, Nov 26, 2007 at 03:31:46PM +0100, Thomas Kellerer wrote:
>
> "EnterpriseDB Replication Server replicates data across the enterprise
> in near real time to meet a wide array of business challenges. Data can
Slony does this, except that it can't talk to Oracle. What's wrong with
Slony?
On Mon, Nov 26, 2007 at 07:25:04AM -0600, Jeff Larsen wrote:
>
> My 2 cents...
>
> I would rather see someone working on true synchronous replication,
It will cost more than US$0.02. But if you're willing to put up real money,
there are people willing to put in the work. Or, if you're willing
On Mon, Nov 26, 2007 at 07:02:35PM +, Glyn Astill wrote:
> It it possible to get a system that does syncronous replication and
> also allows slaves to catch up if they're down for a period of time
> like you can with asyncronous?
This is what Postgres-R is intended to do. In order to get that
On Nov 26, 2007 1:02 PM, Glyn Astill <[EMAIL PROTECTED]> wrote:
> It it possible to get a system that does syncronous replication and
> also allows slaves to catch up if they're down for a period of time
> like you can with asyncronous?
Ummm, if one server falls behind, and the other keeps going,
Okay I'm relaxed ;-) honest.
It does irritate me sometimes (my fault) when people post back
comments as if they have knowledge on a subject when they don't
though, if you don't know then keep quiet.
All it does is confuse prople like me, who really don't know, and are
reaching out for a little h
> --- Original Message ---
> From: Chris Browne <[EMAIL PROTECTED]>
> To: pgsql-general@postgresql.org
> Sent: 26/11/07, 17:39:42
> Subject: Re: [GENERAL] replication in Postgres
>
> I believe that what they are using is a version of Slony-I, which
> certa
Glyn Astill escribió:
> It it possible to get a system that does syncronous replication and
> also allows slaves to catch up if they're down for a period of time
> like you can with asyncronous?
Guess what, Postgres-R is designed to do that.
> Just for the record I'm a programmer, not a database
It it possible to get a system that does syncronous replication and
also allows slaves to catch up if they're down for a period of time
like you can with asyncronous?
I'm just interested.
Of course a grid or a clustwer is better to makesure all servers are
in sync, but there's performance issues
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 26 Nov 2007 18:57:19 + (GMT)
Glyn Astill <[EMAIL PROTECTED]> wrote:
>
> --- Alvaro Herrera <[EMAIL PROTECTED]> wrote:
>
> > Glyn Astill wrote:
> > > Thanks everyone for your replies. EnterpriseDB looks like the way
> > to
> > > go if we
--- Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Glyn Astill wrote:
> > Thanks everyone for your replies. EnterpriseDB looks like the way
> to
> > go if we want good replication.
>
> Sorry, this makes no sense to me -- EnterpriseDB has no replication
> solution that I know of.
>
This is bullsh*
[EMAIL PROTECTED] ("Jeff Larsen") writes:
>> Alvaro Herrera wrote:
>> > Glyn Astill wrote:
>> >> Thanks everyone for your replies. EnterpriseDB looks like the way to
>> >> go if we want good replication.
>> >
>> > Sorry, this makes no sense to me -- EnterpriseDB has no replication
>> > solution tha
Jeff Larsen wrote:
Alvaro Herrera wrote:
Glyn Astill wrote:
Yes, but I'd like something better than "near real time" as the above
page describes. Or maybe someone could clarify that Besides,
EnterpriseDB does not save me enough money.
Well do what EnterpriseDB does :) use Slony. Which i
> > Yes, but I'd like something better than "near real time" as the above
> > page describes. Or maybe someone could clarify that Besides,
> > EnterpriseDB does not save me enough money. In my current commercial
> > DB, if a transaction is committed on the master, it is guaranteed to
> > be com
On Nov 26, 2007, at 10:14 AM, Jeff Larsen wrote:
Yes, but I'd like something better than "near real time" as the above
page describes. Or maybe someone could clarify that Besides,
EnterpriseDB does not save me enough money. In my current commercial
DB, if a transaction is committed on the m
> Alvaro Herrera wrote:
> > Glyn Astill wrote:
> >> Thanks everyone for your replies. EnterpriseDB looks like the way to
> >> go if we want good replication.
> >
> > Sorry, this makes no sense to me -- EnterpriseDB has no replication
> > solution that I know of.
>
> Yeah, there is:
>
> http://www.e
Alvaro Herrera wrote:
> Glyn Astill wrote:
>> Thanks everyone for your replies. EnterpriseDB looks like the way to
>> go if we want good replication.
>
> Sorry, this makes no sense to me -- EnterpriseDB has no replication
> solution that I know of.
Yeah, there is:
http://www.enterprisedb.com/pro
Alvaro Herrera, 26.11.2007 15:07:
EnterpriseDB has no replication solution that I know of.
Quote from
http://www.enterprisedb.com/products/enterprisedb_replication.do
"EnterpriseDB Replication Server replicates data across the enterprise
in near real time to meet a wide array of business chal
On Mon, 2007-11-26 at 07:25 -0600, Jeff Larsen wrote:
> > Someone is working on extending the current system to allow read-only
> > queries on a standby server [1], thus making it a "hot standby", but
> > this feature apparently won't be included until 8.4 [2].
>
> My 2 cents...
>
> I would rathe
Glyn Astill wrote:
> Thanks everyone for your replies. EnterpriseDB looks like the way to
> go if we want good replication.
Sorry, this makes no sense to me -- EnterpriseDB has no replication
solution that I know of.
> Postgres-r sounds very nice but moving our organisations data onto a
> system
Jeff Larsen escribió:
> > Someone is working on extending the current system to allow read-only
> > queries on a standby server [1], thus making it a "hot standby", but
> > this feature apparently won't be included until 8.4 [2].
>
> My 2 cents...
>
> I would rather see someone working on true sy
> Someone is working on extending the current system to allow read-only
> queries on a standby server [1], thus making it a "hot standby", but
> this feature apparently won't be included until 8.4 [2].
My 2 cents...
I would rather see someone working on true synchronous replication,
rather than a
On Sun, 2007-11-25 at 22:18 +, Glyn Astill wrote:
> So far the only methods I see would be usable for us are Slony I and
> WAL log shipping.
>
> Does anyone here have a similar setup or any recommendations?
This link may be of some use
http://www.2ndquadrant.com/replication.html
plus 2ndQu
On Sun, 2007-11-25 at 23:38 +0100, Alexander Staubo wrote:
> On 11/25/07, Glyn Astill <[EMAIL PROTECTED]> wrote:
> > So far the only methods I see would be usable for us are Slony I and
> > WAL log shipping.
>
> WAL shipping probably does not work the way you think it does. The
> secondary server
On 11/25/07, Glyn Astill <[EMAIL PROTECTED]> wrote:
> So far the only methods I see would be usable for us are Slony I and
> WAL log shipping.
WAL shipping probably does not work the way you think it does. The
secondary server that receives the log pieces is not actually able to
serve any queries;
Hi people,
Does anyone here have replication setup? We're intending to move onto
Postgres and I'm looking into the replication methods available to
us.
We intend to have a master and slave on site and another slave at our
second site down a 10Mb line.
So far the only methods I see would be usabl
35 matches
Mail list logo
