[pgpool-general: 902] Re: How can I automate actions when synchronous standby fails?
maumau307 at gmail.com
Sat Aug 18 17:27:16 JST 2012
Thanks for your answers. As for Q4, I'll read the mail archive.
From: "Tatsuo Ishii" <ishii at postgresql.org>
>> How can I achieve this with pgpool? Is failover_command invoked when
>> the standby stops working?
>> What do the following special characters mean in failover_command
>> description? How does "master" differ from "primary"? In my
>> configuration, what values do they provide when the standby (dbnode1)
>> goes down?
>> %M Old master node ID.
>> %P Old primary node ID.
> Usually they are same. They might be different if you do not have any
> primary node (failed to promote to primary case).
>> What kind of problems could occur when many pgpool instances on the
>> application servers invoke failover_command simultaneously and
>> independently of one another? What should I do to avoid those
>> potential problems?
> If you turn on watchdog, the second failover attempt will fail.
>> I found the below sentence in pgpool manual. Does this apply even
>> when the standby fails? If yes, I would like to know any workaround
>> or reason, because I believe standby failure should not affect
>> application processing which is performed on the normal primary.
>> "When a failover is performed, pgpool kills all its child processes,
>> which will in turn terminate all active sessions to pgpool."
> Excerpt from main.c.
> * Before we tried to minimize restarting pgpool to protect existing
> * connections from clients to pgpool children. What we did here was,
> * if children other than master went down, we did not fail over.
> * This is wrong. Think about following scenario. If someone
> * accidentally plugs out the network cable, the TCP/IP stack keeps
> * retrying for long time (typically 2 hours). The only way to stop
> * the retry is restarting the process. Bottom line is, we need to
> * restart all children in any case. See pgpool-general list posting
> * "TCP connections are *not* closed when a backend timeout" on Jul 13
> * 2008 for more details.
More information about the pgpool-general