View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000760 | Pgpool-II | Bug | public | 2022-07-08 06:50 | 2022-08-01 15:32 |
| Reporter | Dave Sisk - Bullhorn | Assigned To | pengbo | ||
| Priority | high | Severity | major | Reproducibility | always |
| Status | feedback | Resolution | open | ||
| Product Version | 4.3.2 | ||||
| Summary | 0000760: With 1 primary + 2 standby's w/ streaming replication, PGPool does not down 2nd standby on failover | ||||
| Description | Take a 3 node cluster with 1 primary and 2 standby's. node0 - primary node1 - standby node2 - standby Stop postgres on node1...failover event executes, but PGPool does not mark node2 standby as down. It remains up and should not. | ||||
| Steps To Reproduce | Create 3 node cluster: node0 - primary node1 - standby node2 - standby Stop postgres on node1...failover event executes, but PGPool does not mark node2 standby as down. | ||||
| Additional Information | Debian 11, PostgreSQL 14.4, PGPool 4.3.2 | ||||
| Tags | No tags attached. | ||||
|
|
> Stop postgres on node1...failover event executes, but PGPool does not mark node2 standby as down. It remains up and should not. If you stopped PostgreSQL on node1, Pgpool-II will mark node1 as DOWN, not node2. You can run "show pool_nodes" and verify the "status" column. https://www.pgpool.net/docs/latest/en/html/sql-show-pool-nodes.html |
|
|
Hi Pengbo...typo in my description, here is what I meant: "Stop postgres on node0...failover event executes, but PGPool does not mark node2 standby as down. It remains up and should not." So, node0 primary, node1 standby, node2 standby. Stopping node0 causes failover, and node1 gets promoted to primary. Node0 is down, and node2 should be marked "down" but is not. |
|
|
Sorry for the late response. > So, node0 primary, node1 standby, node2 standby. Stopping node0 causes failover, and node1 gets promoted to primary. Node0 is down, and node2 should be marked "down" but is not. It is the expected behavior. The node1 is promoted and node2 will follow the new primary node1 as a standby. If you want to stop node2 after failover, you need to modify the script executed by failover_command or follow_primary_command. |
|
|
Hi Pengbo... Thanks for the response. After failover, how does node2 become rewound or recovered so that it knows to follow the new primary node1? It has to be downed first so it can be either recovered using pg_basebackup or rewound using pg_rewind. This behavior changed between PGPool 4.1 and current 4.3. Previously, a failover downed all standby's, then a follow_master script would recover/rewind each standby, then "up" them in PGPool. If this change is intentional behavior, can you point me to release notes or documentation that explains what is supposed to happen and why it was changed from previous behavior? Thank you! Dave |
|
|
> This behavior changed between PGPool 4.1 and current 4.3. Previously, a failover downed all standby's, > then a follow_master script would recover/rewind each standby, then "up" them in PGPool. > If this change is intentional behavior, can you point me to release notes or documentation that explains > what is supposed to happen and why it was changed from previous behavior? No. We didn't change the behavior. The script specified in follow_master_command will recover the standby node to follow the new primary node. This script will first stop the standby node, then run pg_rewind or pg_basebackup. Below are the scripts in 4.1 and 4.3: https://git.postgresql.org/gitweb/?p=pgpool2.git;a=blob_plain;f=src/sample/scripts/follow_master.sh.sample;hb=refs/heads/V4_1_STABLE https://git.postgresql.org/gitweb/?p=pgpool2.git;a=blob_plain;f=src/sample/scripts/follow_primary.sh.sample;hb=refs/heads/V4_3_STABLE |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2022-07-08 06:50 | Dave Sisk - Bullhorn | New Issue | |
| 2022-07-11 12:55 | pengbo | Assigned To | => pengbo |
| 2022-07-11 12:55 | pengbo | Status | new => assigned |
| 2022-07-11 13:00 | pengbo | Note Added: 0004090 | |
| 2022-07-11 13:00 | pengbo | Status | assigned => feedback |
| 2022-07-12 03:22 | Dave Sisk - Bullhorn | Note Added: 0004091 | |
| 2022-07-12 03:22 | Dave Sisk - Bullhorn | Status | feedback => assigned |
| 2022-07-27 21:36 | pengbo | Note Added: 0004096 | |
| 2022-07-27 21:37 | pengbo | Status | assigned => feedback |
| 2022-07-28 04:58 | Dave Sisk - Bullhorn | Note Added: 0004097 | |
| 2022-07-28 04:58 | Dave Sisk - Bullhorn | Status | feedback => assigned |
| 2022-08-01 15:32 | pengbo | Note Added: 0004103 | |
| 2022-08-01 15:32 | pengbo | Status | assigned => feedback |
