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