<div dir="ltr"><div dir="ltr">Hi,<div><br></div><div>Is there any option to specify read queries on specific tables to master only?</div><div><br></div><div>Thanks!</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 8, 2021 at 3:58 PM valsaraj pv <<a href="mailto:valsarajpv@gmail.com">valsarajpv@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Ok, thanks. <br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 8, 2021 at 3:35 PM Tatsuo Ishii <<a href="mailto:ishii@sraoss.co.jp" target="_blank">ishii@sraoss.co.jp</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Hi,<br>
> <br>
> Set delay_threshold = 30 and load tested. The error is not seen.<br>
<br>
It seems Pgpool-II is avoiding the PostgreSQL backend having too much<br>
replication delay. Good.<br>
<br>
> The following appearing in log sometimes:<br>
> 2021-07-08 04:05:13: pid 4285: LOG:  selecting backend connection<br>
> 2021-07-08 04:05:13: pid 4285: DETAIL:  failover or failback event<br>
> detected, discarding existing connections<br>
<br>
This is normal. Pgpool detects there has been a failover/failback<br>
event. This means that existing connections (connection pools) to<br>
backend may not be usable any more. Thus pgpool creats new connections<br>
to backend.<br>
<br>
> Any thoughts on this?<br>
> <br>
> Thanks!<br>
> <br>
> On Sat, Jul 3, 2021 at 6:22 AM Tatsuo Ishii <<a href="mailto:ishii@sraoss.co.jp" target="_blank">ishii@sraoss.co.jp</a>> wrote:<br>
> <br>
>> >>> Any recommendations for this kind of scenario?<br>
>> >><br>
>> >> synchronous_commit = remote_apply will help at the expense of<br>
>> >> performance.<br>
>> ><br>
>> > Another option is, setting delay_threshold of pgpool.conf to lower<br>
>> > value. Default is 10000000 which allows large replication delay. So<br>
>> > you might want to set smaller value for it.<br>
>> ><br>
>> > Note that observation of replication delay is done periodically,<br>
>> > defined by sr_check_period. This means that if replication delay grows<br>
>> > rapidly, the replication delay observed by pgpool could be outdated<br>
>> > and pgpool may send SELECT to delayed standby, and you might see the<br>
>> > error.<br>
>> ><br>
>> > In summary delay_threshold is not perfect but can be useful if you<br>
>> > want to keep on using asynchronous replication.<br>
>><br>
>> Actually Pgpool-II has many other options that might help you. Please<br>
>> checkout the manual:<br>
>><br>
>> <a href="https://www.pgpool.net/docs/latest/en/html/runtime-config-load-balancing.html#RUNTIME-CONFIG-LOAD-BALANCING-SETTINGS" rel="noreferrer" target="_blank">https://www.pgpool.net/docs/latest/en/html/runtime-config-load-balancing.html#RUNTIME-CONFIG-LOAD-BALANCING-SETTINGS</a><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>
>><br>
> <br>
> <br>
> -- <br>
> Life is like this: "Just when we get all the answers of life.... God<br>
> changes the question paper....<br>
> <br>
> Valsaraj Viswanathan<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr">Life is like this: "Just when we get all the answers of life.... God changes the question paper....<br><br>Valsaraj Viswanathan</div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Life is like this: "Just when we get all the answers of life.... God changes the question paper....<br><br>Valsaraj Viswanathan</div></div>