logging of the commit is done after the WAL operation, it must be
assured that WAL replay during crash recovery also causes
replication log journal to be recovered or repeated. In short, the
replication log must be covered by the same redo mechanism the crash
recovery system uses.
This I will
On 8/12/2004 12:02 PM, Joshua D. Drake wrote:
To make a transaction durable, the changes first have to be recorded in
PostgreSQL's crash recovery WAL. Only after that data is flushed to the
disk it can be assumed that the transaction will be redone in the case
of an immediately following crash.
On Wed, Aug 11, 2004 at 12:02:07PM -0400, Tom Lane wrote:
> Now erServer did work for them, but it required significant amounts of
> tuning and constant babysitting by the DBA. (If Andrew Sullivan is
> paying attention to this thread, he can offer lots of gory details.)
> I can also personally tes
EMAIL PROTECTED]
Subject: Re: [GENERAL] Replication options?
Date: Thu, 12 Aug 2004 09:02:34 -0700
> As far as I know (Joshua please clearify here) Mammoth Replicator
writes
its own, binary journal containing the changes that need to be applied to
the replica.
Yes that is correct.
On a first look
> As far as I know (Joshua please clearify here) Mammoth Replicator
writes
its own, binary journal containing the changes that need to be applied
to the replica.
Yes that is correct.
On a first look inserting into database tables might look more
expensive. But there are some fine details that
I'll try this again, since it doesn't seem to have made it to the
list.
On Wed, Aug 11, 2004 at 12:02:07PM -0400, Tom Lane wrote:
> Now erServer did work for them, but it required significant amounts of
> tuning and constant babysitting by the DBA. (If Andrew Sullivan is
> paying attention to th
On Aug 11, 2004, at 12:02 PM, Tom Lane wrote:
Jeff Eckermann <[EMAIL PROTECTED]> writes:
That probably won't impress your bosses. If you need
a track record, then erServer might be what you need.
erServer is a commercially produced product that was
(is still?) used by Afilias, the provider of regi
From: Jeff Eckermann <[EMAIL PROTECTED]>
To: Tom Lane <[EMAIL PROTECTED]>
CC: Liam Lesboch <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Re: [GENERAL] Replication options? Date: Wed, 11 Aug 2004 12:38:34
-0700 (PDT)
--- Tom Lane <[EMAIL PROTECTED]> wrote:
> Jeff
From: Peter Eisentraut <[EMAIL PROTECTED]>
To: "Liam Lesboch" <[EMAIL PROTECTED]>,[EMAIL PROTECTED]
Subject: Re: [GENERAL] Replication options?
Date: Wed, 11 Aug 2004 21:54:28 +0200
Liam Lesboch wrote:
> Thes slashdots post today about the beta releases of 8.0 caught t
From: "Joshua D. Drake" <[EMAIL PROTECTED]>
To: Jeff Eckermann <[EMAIL PROTECTED]>
CC: Tom Lane <[EMAIL PROTECTED]>,Liam Lesboch <[EMAIL PROTECTED]>,
[EMAIL PROTECTED]
Subject: Re: [GENERAL] Replication options?
Date: Wed, 11 Aug 2004 13:38:54 -0700
Granted...
Granted...
Liam's bosses want something with a history of
successful use in a serious production situation, and
erServer at least has that. Slony has been around for
too short a time to make that claim, yet.
There is also Mammoth Replicator which is an integrated replication
approach that does n
Liam Lesboch wrote:
> Thes slashdots post today about the beta releases of 8.0 caught the
> attention of my boss and I. Many comments about the replicator issue
> and saw many posts about Slony-I in particular. Maybe this is the
> only viable option in PostgreSQL? There are others that cost money
>
--- Tom Lane <[EMAIL PROTECTED]> wrote:
> Jeff Eckermann <[EMAIL PROTECTED]> writes:
> > That probably won't impress your bosses. If you
> need
> > a track record, then erServer might be what you
> need.
> > erServer is a commercially produced product that
> was
> > (is still?) used by Afilias,
> "TL" == Tom Lane <[EMAIL PROTECTED]> writes:
>> serious testing; very large databases and lots of
>> traffic.
>> Note that Afilias paid for the development of Slony-I;
TL> ... because they were quite unhappy with erServer ...
The major point Jan brings up when you talk about this is that
On Tue, 2004-08-10 at 16:53, Liam Lesboch wrote:
> Thes slashdots post today about the beta releases of 8.0 caught the
> attention of my boss and I. Many comments about the replicator issue and saw
> many posts about Slony-I in particular. Maybe this is the only viable option
> in PostgreSQL? Th
n the
magazines, my bosses uncomfort with PostgreSQL will not be remedied with
just project maintainers word of mouth.
Liam
From: Bruce Momjian <[EMAIL PROTECTED]>
To: Liam Lesboch <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
Subject: Re: [GENERAL] Replication options?
Date: Tue, 10
Most people are using Sloney for master/slave replication. You can
search for it easily.
---
Liam Lesboch wrote:
> Greetings,
>
> Yesterday theres was a brief discuissions about replications software for
> PostgreSQL. My
not be remedied with
just project maintainers word of mouth.
Liam
From: Bruce Momjian <[EMAIL PROTECTED]>
To: Liam Lesboch <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
Subject: Re: [GENERAL] Replication options?
Date: Tue, 10 Aug 2004 13:12:39 -0400 (EDT)
Most people are using Sloney for
Hello,
Investigating many options of pgsql replication softwares. Theres are two
thats come up in discussions earliers today which are Mamoth Replicator and
Slony-I. Is there anybodies who has reviewed them and or compared them in
corporate environment? My companys is moving from Microsoft Seque
On Wed, Feb 18, 2004 at 08:58:28PM -, Simon Windsor wrote:
> for MASTER-MASTER
None. Postgres-R is intended to offer it, but it requires work
still.
> and MASTER-SLAVE(Multiple) replication.
All the rest, except for contrib/rserv, which does only one slave. I
have used the erserver on
Hi
I am fairly news to Postgres, but have spent many years
using Oracle (15) and MySQL(5).
Whilst I find Postgres very easy to ‘pickup’, the
number of replication options are puzzling.
There are a number of replication options available to
Postgres. Can anyone on this list advis
On Feb 19, 2004, at 1:24 PM, Simon Windsor wrote:
Hi
I am used to using Oracle (15 years) and MySQL(5 years), but I am
planning to move an existing application from MySQL to Postgres. The
reasons are very simple,
• New requirements means we need views, or a significant re-write
• Bett
Hi
I am used to using Oracle (15 years) and MySQL(5 years), but
I am planning to move an existing application from MySQL to Postgres. The
reasons are very simple,
New requirements means we need
views, or a significant re-write
Better query/index performance
essential.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> 1. In my PHP code, I have functions like
> inserttransaction(values...). I could just modify inserttransaction()
> so that it runs the same query (the INSERT) on two or more DB
> servers. This would probably work ok.
Why not have a proxy server t
I guess if you don't do deletes then something like selecting all the
records with an oid greater than the last replication cycle would
find the most recent additions.
Erich wrote:
>
> I am setting up a system that processes transactions, and it needs to
> be highly reliable. Once a transact
I am setting up a system that processes transactions, and it needs to
be highly reliable. Once a transaction happens, it can never be
lost. This means that there needs to be real-time off-site
replication of data. I'm wondering what's the best way to do this.
One thing that might simplify thi
26 matches
Mail list logo
