<div dir="ltr">Hi<div><br></div><div><br></div><div class="gmail_extra"><div class="gmail_quote">On Wed, Dec 16, 2015 at 2:15 PM, Tatsuo Ishii <span dir="ltr"><<a href="mailto:ishii@postgresql.org" target="_blank">ishii@postgresql.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Currently pgpool-II always disconnects to clients whenever fail over<br>
happens because all the pgpool-II child process restart in the case.<br>
This is annoying and it's been one of the tops 3 compliants from<br>
users.<br>
<br></blockquote><div><br></div><div>I think it would be a very good feature to have and will enhance the user experience of pgpool-II.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I think we could mitigate it in a certain condition:<br>
<br>
1) Pgpool-II runs in the streaming replication mode<br>
<br>
2) The failed node is one of standbys (not primary)<br>
<br>
3) We accept that clients connecting to the standby cannot continue<br>
the processing thus it will be disconnected from pgpool-II<br>
<br>
If all of the conditions above are satisfied, by changing pgpool-II in<br>
the way below, some of clients will not be suffered by the<br>
disconnection problem on fail over.<br>
<br>
1) Let pgpool-II connects to the primary node and the load balancing<br>
node only (currently pgpool-II connects to all live nodes).<br>
<br>
2) When a fail over happens, lucky clients connecting to other standby<br>
servers will not be affected by the fail over.<br>
<br></blockquote><div><br></div><div>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</div><div><br></div><div>Thanks</div><div>Best regards</div><div>Muhammad Usama</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Question is, this is worth to implement or not (are users getting<br>
happier?). In a common configurations such as two DB node<br>
configuration, probability for the occurrence of the disconnecting<br>
problem would be 50% in average, because it is expected that half of<br>
clients are likely connecting to the failing standby (Of course the<br>
more we add standby servers, the smaller the probability of<br>
disconnection is).<br>
<br>
Maybe users could change the standby's weight parameter to 0, to<br>
prevent clients connect to the failing standby.<br>
<br>
Comments, thoughts?<br>
--<br>
Tatsuo Ishii<br>
SRA OSS, Inc. Japan<br>
English: <a href="http://www.sraoss.co.jp/index_en.php" rel="noreferrer" target="_blank">http://www.sraoss.co.jp/index_en.php</a><br>
Japanese:<a href="http://www.sraoss.co.jp" rel="noreferrer" target="_blank">http://www.sraoss.co.jp</a><br>
_______________________________________________<br>
pgpool-hackers mailing list<br>
<a href="mailto:pgpool-hackers@pgpool.net">pgpool-hackers@pgpool.net</a><br>
<a href="http://www.pgpool.net/mailman/listinfo/pgpool-hackers" rel="noreferrer" target="_blank">http://www.pgpool.net/mailman/listinfo/pgpool-hackers</a><br>
</blockquote></div><br></div></div>