Re: Core team statement on replication in PostgreSQL

From: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Core team statement on replication in PostgreSQL
Date: 2008-06-11 01:11:07
Message-ID: 20080611095156.81B0.52131E4D@oss.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-hackers


Josh Berkus <josh(at)agliodbs(dot)com> wrote:

> I still see having 2 different settings:
>
> Synchronous: XID visibility is pushed to the master. Maintains synchronous
> failover, and users are expected to run *1* master to *1* slave for most
> installations.
>
> Asynchronous: replication stops on the slave whenever minxid gets out of
> synch. Could have multiple slaves, but noticeable lag between master and
> slave.

I agree with you that we have sync/async option in log-shipping.
Also, we could have another setting - synchronous-shipping and
asynchronous-flushing. We won't lose transactions if both servers are
down at once and can avoid delays to flush wal files into primary's disks.

As for multiple slaves, we could have a cascading configuration;
WAL receiver also delivers WAL records to other servers.
I think it is simple that the postgres core has only one-to-one replication
and multiple slaves are supported by 3rd party's WAL receivers.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

In response to

Browse pgsql-advocacy by date

  From Date Subject
Next Message Santiago Zarate 2008-06-11 01:26:20 Re: POP material
Previous Message Joshua D. Drake 2008-06-11 00:42:14 Re: Booth Swag

Browse pgsql-hackers by date

  From Date Subject
Next Message billy 2008-06-11 01:30:45 why copy tuple in the end of trigger when nothing changed in NEW OLD record variable
Previous Message Dawid Kuroczko 2008-06-11 00:51:07 Re: RFD: ALTER COLUMN .. SET STORAGE COMPRESSED;