Download pgpool-II user manual

The procedure to update standby PostgreSQL servers are same as the one of replication mode. Please refer to "Online
recovery with Streaming Replication" to set up recovery_1st_stage_command and recovery_2nd_stage_command.
You cannot version up primary server without stopping pgpool-II. You need to stop pgpool-II while updating primary
server. The procedure to update primary PostgreSQL server is same as the one standby server. The procedure to update
primary PostgreSQL server is as follows:
1.
2.
3.
4.
5.
Stop pgpool-II
Stop primary PostgreSQL
Update primary PostgreSQL
Start primary PostgreSQL
Start pgpool-II
back to top
Backup
To back up backend PostgreSQL servers and system DB, you can use physical backup, logical backup (pg_dump,
pg_dumpall) and PITR in the same manner as PostgreSQL. Please note that using logical backup and PITR should be
performed directory with PostgreSQL, rather than via pgpool-II to avoid errors caused by load_balance_mode and
replicate_select.
replication mode and master/slave mode
If pgpool-II is operated in replication mode or master/slave mode, take a backup on one DB nodes in the cluster.
If you are using master/slave mode and asynchronous replication systems(Slony-I and streaming replication) and
need the latest backup, you should take a backup on the master node.
pg_dump takes ACCESS SHARE lock on database. Commands taking ACCESS EXECUTE lock, such as ALTER TABLE,
DROP TABLE, TRUNCATE, REINDEX, CLUSTER and VACUUM FULL will wait for the completion of pg_dump because of
lock conflict. Also this may affect the primary node even if you are doing pg_dump on standby.
Parallel mode
If you are using parallel mode and need to take a consistent backup, you need to stop pgpool-II.