| From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Joshua Tolley <eggyknap(at)gmail(dot)com>, Yeb Havinga <yebhavinga(at)gmail(dot)com>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Synchronous replication |
| Date: | 2010-08-02 08:45:40 |
| Message-ID: | AANLkTi=JwopeetrtUP4czTHuzLfzz7sJrSY2c6HpVCDh@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Aug 1, 2010 at 3:11 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> I don't think any of this quorum stuff makes much sense without explicitly
> registering standbys in the master.
I'm not sure if this is a good idea. This requires users to do more
manual operations than ever when setting up the replication; assign
unique name (or ID) to each standby, register them in the master,
specify the names in each recovery.conf (or elsewhere), and remove
the registration from the master when getting rid of the standby.
But this is similar to the way of MySQL replication setup, so some
people (excluding me) may be familiar with it.
> That would also solve the fuzziness with wal_keep_segments - if the master
> knew what standbys exist, it could keep track of how far each standby has
> received WAL, and keep just enough WAL for each standby to catch up.
What if the registered standby stays down for a long time?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2010-08-02 09:02:34 | Re: Synchronous replication |
| Previous Message | Pavel Stehule | 2010-08-02 08:21:13 | Re: Initial review of xslt with no limits patch |