View Issue Details

IDProjectCategoryView StatusLast Update
0000329Pgpool-IIBugpublic2017-08-15 11:08
Reportersupp_kAssigned ToMuhammad Usama 
PriorityhighSeveritymajorReproducibilityrandom
Status assignedResolutionopen 
Platformx86_64OSCentOSOS Version7.3
Product Version3.6.5 
Target VersionFixed in Version 
Summary0000329: Newly elected(promoted) Pgpool does connect to any backend
DescriptionAfter network split the newly elected Pgpool instance doesn't discover any active PG backend. Is succesfully promotes standby PG into master but later it marks all PG instances as down, though the only previous Master PG should be considered down

Environment:
1) Head Server
Head pgpool A

2) DB Node A
- PostgreSQL (Master)
- Pgpool 3.6.5 (Master)

3) DB Node B
- PostgreSQL (Sync standby)
- Pgpool 3.6.5


Steps To ReproduceIn the described environment perform "ifdown eth0" on DB Node A - it emulates network split.

Two remained pgpools (they "see" each other) start election. When the election is complete the new Master Pgpool (on DB Node B) considers both PG backends as down. Though the only PG instance on DB Node A should be "down" because it is invisible from the network perspective.

Logs and configuration files are attached. The destructive case was emulated approximately at 15:25:07.

The only way to survive the case is to perform "pcp_attach_node" for the running PG instance, but it is incorrect
Additional InformationP/S: The similar behavior was observed in the issue 0000306

Please pay attention the log file of the head pgpool contains log fragments that not refer to pgpool. This is because the same log is used by DB client
TagsNo tags attached.

Activities

supp_k

2017-08-11 22:04

reporter  

logs.tar.gz (312,571 bytes)

Issue History

Date Modified Username Field Change
2017-08-11 22:04 supp_k New Issue
2017-08-11 22:04 supp_k File Added: logs.tar.gz
2017-08-15 11:08 t-ishii Assigned To => Muhammad Usama
2017-08-15 11:08 t-ishii Status new => assigned