Streaming replication and triggering failover
От | Heikki Linnakangas |
---|---|
Тема | Streaming replication and triggering failover |
Дата | |
Msg-id | 4B4701C3.8050709@enterprisedb.com обсуждение исходный текст |
Ответы |
Re: Streaming replication and triggering failover
|
Список | pgsql-hackers |
The trigger file logic feels a bit backwards. As the patch stands, when the standby starts up, it retries connecting to the master server indefinitely, until a connection is successfully established. Then it streams until the connection breaks. If the connection is dropped abruptly, because of a network problem or crash in the master, standby retries indefinitely. If master is shut down cleanly, standby gets out of recovery mode, and starts up. Unless the trigger file is present; if it is, standby waits for it to go away before finishing recovery. 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. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: