<div dir="ltr">Hi Tatsuo<br>I've observed some logs following an auto failover that I'd like to discuss<br><br>2023-08-19 00:44:07.277: main pid 62145: LOG: find_primary_node: primary node is 1<br>2023-08-19 00:44:07.277: main pid 62145: LOG: find_primary_node: standby node is 2<br>2023-08-19 00:44:07.278: main pid 62145: LOG: starting follow degeneration. shutdown host 172.16.14.165(5432)<br>2023-08-19 00:44:07.279: main pid 62145: LOG: starting follow degeneration. shutdown host 172.16.14.163(5432)<br>2023-08-19 00:44:07.279: main pid 62145: LOG: failover: 2 follow backends have been degenerated<br>2023-08-19 00:44:07.280: main pid 62145: LOG: failover: set new primary node: 1<br><br>do_query: extended:0 query:"SELECT pg_is_in_recovery()"<br>2023-08-19 00:44:08.305: sr_check_worker pid 62243: DEBUG: verify_backend_node_status: there's no standby node<br>2023-08-19 00:44:08.305: sr_check_worker pid 62243: DEBUG: node status[0]: 0<br>2023-08-19 00:44:08.305: sr_check_worker pid 62243: DEBUG: node status[1]: 1<br>2023-08-19 00:44:08.305: sr_check_worker pid 62243: DEBUG: node status[2]: 0<br><br><br>In the above logs, it's evident that the initial primary node at IP address 172.16.14.165 (which is currently down) and standby2 node at 172.16.14.163 were involved in the auto failover process. <br>My concern is why did pgpool initiate the shutdown of standby2 node as part of the auto failover process? and How can we prevent such a degeneration from happening to standby2 in our case? <br><br>NOTE, I attempted to resolve the situation by restarting pgpool2 using the -d switch. After the restart, everything seemed to work fine, and standby2 node was correctly marked as standby again. Is restart of pgpool really necessary?<br><br>Thanks<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Aug 19, 2023 at 1:06 AM Dev BotX <<a href="mailto:devbotx5@gmail.com">devbotx5@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"><div dir="ltr">Hi Tatsuo</div><div dir="ltr">I've observed some logs following an auto failover that I'd like to discuss<br></div><div dir="ltr"><br></div><div dir="ltr">2023-08-19 00:44:07.277: main pid 62145: LOG: find_primary_node: primary node is 1<br>2023-08-19 00:44:07.277: main pid 62145: LOG: find_primary_node: standby node is 2<br>2023-08-19 00:44:07.278: main pid 62145: LOG: starting follow degeneration. shutdown host 172.16.14.165(5432)<br>2023-08-19 00:44:07.279: main pid 62145: LOG: starting follow degeneration. shutdown host 172.16.14.163(5432)<br>2023-08-19 00:44:07.279: main pid 62145: LOG: failover: 2 follow backends have been degenerated<br>2023-08-19 00:44:07.280: main pid 62145: LOG: failover: set new primary node: 1<br><br>do_query: extended:0 query:"SELECT pg_is_in_recovery()"<br>2023-08-19 00:44:08.305: sr_check_worker pid 62243: DEBUG: verify_backend_node_status: there's no standby node<br>2023-08-19 00:44:08.305: sr_check_worker pid 62243: DEBUG: node status[0]: 0<br>2023-08-19 00:44:08.305: sr_check_worker pid 62243: DEBUG: node status[1]: 1<br>2023-08-19 00:44:08.305: sr_check_worker pid 62243: DEBUG: node status[2]: 0<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">In the above logs, it's evident that the initial primary node at IP address 172.16.14.165 (which is currently down) and standby2 node at 172.16.14.163 were involved in the auto failover process. </div><div dir="ltr">My concern is why did pgpool initiate the shutdown of standby2 node as part of the auto failover process? and How can we prevent such a degeneration from happening to standby2 in our case? </div><div dir="ltr"><br></div><div dir="ltr">NOTE, I attempted to resolve the situation by restarting pgpool2 using the -d switch. After the restart, everything seemed to work fine, and standby2 node was correctly marked as standby again. Is restart of pgpool really necessary?</div><div dir="ltr"><br></div><div dir="ltr"><div>Thanks</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 16 Aug 2023 at 18:41, 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">You need to set backend_weight0 to non 0.<br>
e.g.<br>
<br>
backend_weight0 = 0.5<br>
<br>
Note that you don't need to change backend_weight[0-2] before/after failover.<br>
<br>
> Just make my last message clearer,<br>
> <br>
> When I first setup the cluster these were the properties I was using<br>
> <br>
> backend_weight0 = 0<br>
> <br>
> backend_weight1 = 0.5<br>
> <br>
> backend_weight2 = 0.5<br>
> <br>
> load_balance_mode = on database_redirect_preference_list = '.*:standby'<br>
> Load balancing after failover did not work. After failover, I manually set<br>
> the backend_weight1 = 0 and backend_weight2 = 1, and load balancing started<br>
> to work.<br>
> <br>
> <br>
> <br>
> On Wed, Aug 16, 2023 at 5:29 PM Salman Ahmed <salman.ahmed@stormatics.tech><br>
> wrote:<br>
> <br>
>> I did as you suggested, I set the  database_redirect_preference_list value<br>
>> in pgpool.conf to<br>
>><br>
>> database_redirect_preference_list = '.*:standby'<br>
>><br>
>> but load balancing did not work after failover, however when I manually<br>
>> set the backend_weight1 = 0 and backend_weight2 = 1 after failover, the<br>
>> load balancing started to work.<br>
>><br>
>> On Wed, Aug 16, 2023 at 1:02 PM Tatsuo Ishii <<a href="mailto:ishii@sraoss.co.jp" target="_blank">ishii@sraoss.co.jp</a>> wrote:<br>
>><br>
>>> > Dear pgpool-hackers,<br>
>>> ><br>
>>> > We’re currently working on pg_cirrus - a simple tool to setup 3-node HA<br>
>>> > PostgreSQL clusters using pgpool. We’re facing an issue i.e. load<br>
>>> balancing<br>
>>> > after failover does not work.<br>
>>> ><br>
>>> > When pg_cirrus sets up 3-node HA cluster within the same subnet, load<br>
>>> > balancing works seamlessly as expected i.e. write operations go to<br>
>>> primary<br>
>>> > node and read operations go to standby nodes, but after primary node<br>
>>> goes<br>
>>> > down the read and write queries both land on the same newly promoted<br>
>>> > primary node.<br>
>>> ><br>
>>> > We’re using the following load balancing properties in pgpool.conf:<br>
>>> ><br>
>>> > backend_weight0 = 0<br>
>>> ><br>
>>> > backend_weight1 = 0.5<br>
>>> ><br>
>>> > backend_weight2 = 0.5<br>
>>> ><br>
>>> > load_balance_mode = on<br>
>>> ><br>
>>> > Is this the expected behavior or are we doing something wrong, kindly<br>
>>> guide<br>
>>> > us.<br>
>>><br>
>>> Assuming the initial primary is node 0 and the new primary is node 1,<br>
>>> it seems pgpool behaves as expected. After failover, node 0 becomes<br>
>>> new standby with weight 0, which means no read query is routed to node<br>
>>> 0. In the mean time node 1 becomes the new primary with weight 0.5,<br>
>>> which means some of read queries are routed to node1, new primary.<br>
>>><br>
>>> If you want to keep on routing no read query being sent to primary<br>
>>> node, you can use database_redirect_preference_list. For example,<br>
>>><br>
>>> database_redirect_preference_list = '.*:standby'<br>
>>><br>
>>> will route read queries to one of standby servers (which standby is<br>
>>> chosen is depending on the weight parameter), i.e. no read query is<br>
>>> routed to primary. This behavior is kept regardless which node is<br>
>>> assigned to the primary. See manual for more details.<br>
>>><br>
>>> Best reagards,<br>
>>> --<br>
>>> Tatsuo Ishii<br>
>>> SRA OSS LLC<br>
>>> English: <a href="http://www.sraoss.co.jp/index_en/" rel="noreferrer" target="_blank">http://www.sraoss.co.jp/index_en/</a><br>
>>> Japanese:<a href="http://www.sraoss.co.jp" rel="noreferrer" target="_blank">http://www.sraoss.co.jp</a><br>
>>><br>
>><br>
</blockquote></div>
</blockquote></div>