Re: Streaming replication and triggering failover

Magnus Hagander wrote:
> On Fri, Jan 8, 2010 at 10:58, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> So the trigger file is really a "holdoff file", like a safety catch on a
>> gun. At the very least it should be renamed, but I don't think that's a
>> very useful behavior anyway.
>>
>> It doesn't seem wise to consider a clean shutdown of the master as a
>> signal to trigger failover. If you're setting up a HA system, that by
>> itself is not robust enough; you also need to trigger failover if the
>> master goes down unexpectedly, or if the standby was disconnected for
>> some reason when the master was shut down. Secondly, what if you want to
>> restart the master server, without initiating failover? You'll have to
>> restart the standby too, to have it reconnect.
>>
>> Let's have a default of no failover, and retry connecting to the master
>> indefinitely. When you *do* want to fail over, create the trigger file.
>> When the standby sees the trigger file, it should stop streaming, finish
>> up replaying what it had streamed up to that point, and start up as new
>> master.
>
> +1.
>
> The default should be to "maintain the replication cluster", if
> nothing else then by principle of least surprise.
>
> It would also agree with a well-established procedure, which is what
> pg_standby does. Keeping the same basic behavior around something like
> this can only be a good thing.

Thinking more clearly, my comment above about the trigger file logic
being backwards was bollocks; if the master is shut down, standby waits
for the trigger file to appear, not to go away. And creating the trigger
file during replication causes it to finish, and failover to happen.

Nevertheless, let's make the default "no failover" if no trigger file
location is configured, and remove the notion that normal shutdown of
master stops recovery.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com