On 02/08/10 11:45, Fujii Masao wrote:
> On Sun, Aug 1, 2010 at 3:11 PM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.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?
Then you risk running out of disk space. Similar to having an archive
command that fails for some reason.
That's one reason the registration should not be too automatic - there
is serious repercussions if the standby just disappears. If the standby
is a synchronous one, the master will stop committing or delay
acknowledging commits, depending on the configuration, and the master
needs to keep extra WAL around.
Of course, we can still support unregistered standbys, with the current
semantics.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com