[pgpool-general: 902] Re: How can I automate actions when synchronous standby fails?

[MauMau]

Thanks for your answers.  As for Q4, I'll read the mail archive.



Regards
MauMau

From: "Tatsuo Ishii" <ishii at postgresql.org>
>> Q1
>> How can I achieve this with pgpool?  Is failover_command invoked when
>> the standby stops working?
> 
> Yes.
> 
>> Q2
>> 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).
> 
>> Q3
>> 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.
> 
>> Q4
>> 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.
> */
>