View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000329 | Pgpool-II | Bug | public | 2017-08-11 22:04 | 2017-08-15 11:08 |
| Reporter | supp_k | Assigned To | Muhammad Usama | ||
| Priority | high | Severity | major | Reproducibility | random |
| Status | assigned | Resolution | open | ||
| Platform | x86_64 | OS | CentOS | OS Version | 7.3 |
| Product Version | 3.6.5 | ||||
| Summary | 0000329: Newly elected(promoted) Pgpool does connect to any backend | ||||
| Description | After 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 Reproduce | In 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 Information | P/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 | ||||
| Tags | No tags attached. | ||||
