<div dir="ltr"><span style lang="EN-US">Understood. I won’t use pcp_promote_node then but one of the two options you
mentioned.</span><p class="MsoNormal"><span style lang="EN-US"><br></span></p>

<p class="MsoNormal"><span style lang="EN-US">By any
chance, do you know an alternative for zero downtime with Postgres while
scaling?</span></p><p class="MsoNormal"><span style lang="EN-US"><br></span></p>

<p class="MsoNormal">Regards,<span style lang="EN-US"></span></p>

<div class="gmail_extra"><br><div class="gmail_quote">2014-10-17 18:19 GMT-06:00 Tatsuo Ishii <span dir="ltr">&lt;<a href="mailto:ishii@postgresql.org" target="_blank">ishii@postgresql.org</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">&gt; Hi,<br>
&gt;<br>
&gt; I&#39;m currently researching on HA, Failover, Autosacaling applications in<br>
&gt; private clouds.  I consider Pgpool2 and Postgres a viable option for the DB<br>
&gt; layer. But I have several question about whether to use horizontal or<br>
&gt; vertical scaling. So far I think vertical scaling would be the way to go<br>
&gt; for the DB layer. Adding more nodes in a master/slave configuration doesn’t<br>
&gt; seem right performance-wise and it seems more complex also. Besides I think<br>
&gt; could only add more slaves nodes. But maybe someone out there knows better.<br>
&gt;<br>
&gt;<br>
&gt; Anyway my question is the following:<br>
&gt;<br>
&gt;<br>
&gt; The promotion of a slave to master is transparent for the client connected<br>
&gt; to pgpool or there’s a short connection loss (data loss)?<br>
<br>
</span>No, it&#39;s not tranparent. Connections from client to pgpool-II will be<br>
closed. Client needs to reconnect to pgpool-II after changing of<br>
master.<br>
<span class=""><br>
&gt; The scenario I have in mind is: for vertical scaling I could start by<br>
&gt; shutting down a slave node, provisioning more resources, boot again, and<br>
&gt; promote to master with the command pcp_promote_node, after that I could do<br>
&gt; the same with the former master, now slave, and then do an online recovery.<br>
&gt; However, I’m not sure this is completely transparent for clients and<br>
&gt; whether or not it has zero downtime.<br>
<br>
</span>So the process is not completely transparent for clients.<br>
<br>
BTW I do not recommend to use pcp_promote_node command. It just<br>
changes the state in pgpool&#39;s memory and does nothing to<br>
PostgreSQL. You&#39;d better either 1) shutdown master and trigger<br>
failover to promoter standby 2) use pcp_detach_node command to trigger<br>
failover to promote standby then shutdown master manually. After #1 or<br>
#2, you do online recovery to resync old master to the new master.<br>
<br>
After recovering the old master (as new standby), you can attach the<br>
new standby by using pcp_attach_node. the process is transparent to<br>
clients. Existing connections from clients to pgpool will be kept.<br>
<br>
Best regards,<br>
--<br>
Tatsuo Ishii<br>
SRA OSS, Inc. Japan<br>
English: <a href="http://www.sraoss.co.jp/index_en.php" target="_blank">http://www.sraoss.co.jp/index_en.php</a><br>
Japanese:<a href="http://www.sraoss.co.jp" target="_blank">http://www.sraoss.co.jp</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Job Cespedes<br>
</div></div>