[pgpool-hackers: 1226] Re: Preventing disconection to clients on failover

Tatsuo Ishii ishii at postgresql.org
Thu Dec 17 07:28:04 JST 2015


>> I think we could mitigate it in a certain condition:
>>
>> 1) Pgpool-II runs in the streaming replication mode
>>
>> 2) The failed node is one of standbys (not primary)
>>
>> 3) We accept that clients connecting to the standby cannot continue
>>    the processing thus it will be disconnected from pgpool-II
>>
>> If all of the conditions above are satisfied, by changing pgpool-II in
>> the way below, some of clients will not be suffered by the
>> disconnection problem on fail over.
>>
>> 1) Let pgpool-II connects to the primary node and the load balancing
>>    node only (currently pgpool-II connects to all live nodes).
>>
>> 2) When a fail over happens, lucky clients connecting to other standby
>>    servers will not be affected by the fail over.
>>
>>
> Pardon me if I am missing anything obvious here as I am just saying out
> what's currently being on top of my head after reading this. What if change
> the failover behavior of child and even when the connected node fails, the
> child instead of restarting itself keeps the frontend connection alive and
> cancels out the current query ( if query is currently running) and return
> the ERROR back to front-end client for currently executing query, and
> re-initialize the backend connections by keeping the frontend connection.
> Or if there is no active query on the connection we just silently shift to
> new backend server and do not disturb the front-end connection.  Yet if
> there are scenarios where there is no easy way out we just disconnect the
> front-end just the way we currently do

There are several things that prevent it:

- How to keep session wide status after moving to another backend. For
  example, if the schema search path has been changed in the previous
  session, we need to restore it on the new backend.

- What if the client is inside an explicit transaction? When an error
  happens in an open transaction, PostgreSQL keeps it in "abort" state
  and refuses to accept any command. We need to simulate this.

- Temp tables. They can't be migrated to other backend.

There may be more but they are just coming to my mind.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp


More information about the pgpool-hackers mailing list