<div dir="ltr">Any more comment on this?</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 19, 2016 at 1:24 PM, Yuri Niyazov <span dir="ltr"><<a href="mailto:yuri@academia.edu" target="_blank">yuri@academia.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">We will never have 127 standbys at the same time.<div><br></div><div>What we will have is, over time, standbys dying, and then new standbys coming up with new hostnames and IP addresses. We will add new standbys as new backend_hostname<number> entries, and then reloading pgpool config. We cannot update old entries without restarting pgpool and breaking connections, so that means that we will be allowed at most 127 failed standbys before we have to restart pgpool. </div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 19, 2016 at 1:10 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Have you actually tried with 127 standbys?<br>
<br>
I don't think the configuration is usable because of too much load on<br>
the primary master.<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" 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>
<div><div><br>
> How do I manage read replicas that appear and disappear dynamically and<br>
> unpredictably in an Amazon Web Services environment? If I understand the<br>
> docs correctly at most, 127 read replicas can appear and disappear before<br>
> we absolutely must restart pgpool, correct?<br>
><br>
> Some background:<br>
><br>
> We are running PostgreSQL in AWS. We have an always-on master database,<br>
> and a number of read-only replicas using streaming replication. At the<br>
> moment, we do not use pgpool - we just hardcode the hostnames of the master<br>
> and the read-only replicas in our app code.<br>
><br>
> We want to dynamically scale up and down our read replicas based on daily<br>
> usage patterns, as well as use the cheaper spot EC2 instances that Amazon<br>
> provides - the caveat being that the latter can be shut down if the market<br>
> price goes above what we are willing to pay. When this happens, we would<br>
> either wait for the spot price to come down again, or bring up new<br>
> instances with a higher price.<br>
><br>
> The following part from the manual for the "backend_hostname"<br>
> configuration setting suggests that using pgpool to accomplish this will be<br>
> hard: "New nodes can be added in this parameter by reloading a<br>
> configuration file. However, values cannot be updated so you must restart<br>
> pgpool-II in that case."<br>
><br>
> So, if we have, in the config:<br>
><br>
> backend_hostname1=A<br>
><br>
> and A goes down, then when its replacement B comes up, we can change the<br>
> config in the following way:<br>
><br>
> backend_hostname1=A<br>
> backend_hostname2=B<br>
><br>
> and tell pgpool to reload the config. I guess we can also remove the<br>
> backend_hostname1 line completely, like this:<br>
><br>
> backend_hostname2=B<br>
><br>
> We *cannot* edit backend_hostname1 like this and expect it work:<br>
><br>
> backend_hostname1=B<br>
><br>
> If I understand the code correctly, the biggest number allowed in the<br>
> backend_hostname<backend_number> is MAX_NUM_BACKENDS, which is 128.<br>
><br>
> This means that after we add backend_hostname127=ZZZ, we must drop back to<br>
> backend_hostname0=ZZZA and restart pgpool. Is there a way to avoid this?<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>