<div dir="ltr">Hello Everyone,<div>due to problem with database master overload, i&#39;ve decided to move one and use pgpool especially for load balacing.</div><div>We already bumped our postgres to 9.4.1 version last year and performances got a litte better.</div><div><br></div><div>First problem was that we still have rhel 5 in prod, so i&#39;ve downloaded sources compiled over a rh5 and pached to rpm using .spec from sources.</div><div><br></div><div>Our configuration has 2 nodes in streaming replica all-in-one that means webapp+db for each node for HA purpose. At the moment we are using just 1 pgpool for testing, then we will use WD with query health check to sync another pgpool instance on second server(we know is deprecated, but we just need to keep connection if server 1 die).</div><div><br></div><div>Anyway we were good until at application start we had this and the application crash:</div><div><br></div><div><br></div><div><div>2016-02-09 18:05:53: pid 7898: LOG:  Backend status file /tmp/pgpool_status does not exist</div><div>2016-02-09 18:05:53: pid 7898: LOG:  Setting up socket for <a href="http://0.0.0.0:9999">0.0.0.0:9999</a></div><div>2016-02-09 18:05:53: pid 7898: LOG:  pgpool-II successfully started. version 3.5.0 (ekieboshi)</div><div>2016-02-09 18:05:53: pid 7898: LOG:  find_primary_node: checking backend no 0</div><div>2016-02-09 18:05:53: pid 7898: LOG:  find_primary_node: checking backend no 1</div><div>2016-02-09 18:05:53: pid 7921: FATAL:  Backend throw an error message</div><div>2016-02-09 18:05:53: pid 7921: DETAIL:  Exiting current session because of an error from backend</div><div>2016-02-09 18:05:53: pid 7921: HINT:  BACKEND Error: &quot;recovery is in progress&quot;</div><div>2016-02-09 18:05:53: pid 7921: CONTEXT:  while checking replication time lag</div><div>2016-02-09 18:05:53: pid 7898: LOG:  find_primary_node: primary node id is 1</div><div>2016-02-09 18:05:53: pid 7898: LOG:  worker child process with pid: 7921 exits with status 256</div><div>2016-02-09 18:05:53: pid 7898: LOG:  fork a new worker child process with pid: 7924</div><div>2016-02-09 18:06:41: pid 7917: WARNING:  packet kind of backend 1 [&#39;Z&#39;] does not match with master/majority nodes packet kind [&#39;1&#39;]</div><div>2016-02-09 18:06:41: pid 7917: FATAL:  failed to read kind from backend</div><div>2016-02-09 18:06:41: pid 7917: DETAIL:  kind mismatch among backends. Possible last query was: &quot;COMMIT&quot; kind details are: 0[1] 1[Z]</div><div>2016-02-09 18:06:41: pid 7917: HINT:  check data consistency among db nodes</div><div>2016-02-09 18:06:41: pid 7898: LOG:  child process with pid: 7917 exits with status 512</div><div>2016-02-09 18:06:41: pid 7898: LOG:  fork a new child process with pid: 8103</div><div>2016-02-09 18:07:10: pid 7916: WARNING:  packet kind of backend 1 [&#39;Z&#39;] does not match with master/majority nodes packet kind [&#39;1&#39;]</div><div>2016-02-09 18:07:10: pid 7916: FATAL:  failed to read kind from backend</div><div>2016-02-09 18:07:10: pid 7916: DETAIL:  kind mismatch among backends. Possible last query was: &quot;COMMIT&quot; kind details are: 0[1] 1[Z]</div><div>2016-02-09 18:07:10: pid 7916: HINT:  check data consistency among db nodes</div><div>2016-02-09 18:07:10: pid 7898: LOG:  child process with pid: 7916 exits with status 512</div><div>2016-02-09 18:07:10: pid 7898: LOG:  fork a new child process with pid: 8213</div><div>2016-02-09 18:07:11: pid 7913: WARNING:  packet kind of backend 1 [&#39;Z&#39;] does not match with master/majority nodes packet kind [&#39;1&#39;]</div><div>2016-02-09 18:07:11: pid 7913: FATAL:  failed to read kind from backend</div><div>2016-02-09 18:07:11: pid 7913: DETAIL:  kind mismatch among backends. Possible last query was: &quot;COMMIT&quot; kind details are: 0[1] 1[Z]</div><div>2016-02-09 18:07:11: pid 7913: HINT:  check data consistency among db nodes</div></div><div><br></div><div>We forced the replicafrom async to sync thought that maybe was the problem, but nothing changed.</div><div><br></div><div><br></div><div>This is our postgresql.conf:</div><div><div><br></div><div>listen_addresses = &#39;*&#39;</div><div>max_connections = 100</div><div>shared_buffers = 32MB</div><div>log_destination = &#39;stderr&#39;</div><div>logging_collector = on</div><div>log_directory = &#39;pg_log&#39;</div><div>log_filename = &#39;postgresql-%a.log&#39;</div><div>log_truncate_on_rotation = on</div><div>log_rotation_age = 1d</div><div>log_rotation_size = 0</div><div>log_line_prefix = &#39;%m                           &#39;</div><div>datestyle = &#39;iso, mdy&#39;</div><div>lc_messages = &#39;en_US.UTF-8&#39;</div><div>lc_monetary = &#39;en_US.UTF-8&#39;</div><div>lc_numeric = &#39;en_US.UTF-8&#39;</div><div>lc_time = &#39;en_US.UTF-8&#39;</div><div>default_text_search_config = &#39;pg_catalog.english&#39;</div><div>ssl = on</div><div>ssl_renegotiation_limit = 0</div><div>wal_level = hot_standby</div><div>archive_mode = off</div><div>max_wal_senders = 1</div><div>wal_keep_segments = 100</div><div>hot_standby = on</div><div>work_mem = 100MB</div><div><br></div><div>#Sync edit edit</div><div>synchronous_standby_names = &#39;walreceiver&#39;</div><div>synchronous_commit = on</div><div><br></div></div><div><br></div><div>the pgpool.conf is just the sample-streaming example conf:</div><div> we added sr_check_user properly and two postgres.</div><div><br></div><div>Anyway if the stanby db is stopped everything works ok.</div><div><br></div><div>Thanks for your patience,</div><div>Stefano.<br></div></div>