A short recipe extracted from our award winning administration Cookbook regarding online major upgrades of PostgreSQL.
Upgrading between major releases is hard, and it should be deferred until you have some good reasons and sufficient time to get it right.
You can use replication tools to minimize the downtime required for an upgrade, so we refer to this recipe as online upgrade.
The following general steps should be followed, allowing at least a month for the complete process to ensure that everything is tested and everybody understands the implications:
- Set up a new release of the software on a new test system.
- Take a standalone backup from the main system and copy it to the test system.
- Test the applications extensively against the new release on the test system.
When everything works and performs correctly, then do the following:
- Set up a connection pooler to the main database (it may be there already).
- Set up pglogical for all tables from old to new database servers. Make sure you wait until all the initial copy tasks have completed for all tables.
- Retest the application extensively against the new release on live data, then when ready for the final cut-over, we can do the following:
- Pause the connection pool.
- Switch the config of the pool over to the new system, reload.
- Resume the connection pool (so it now accesses new server)
Downtime for the application is the length of time to do steps 4-6.
The preceding recipe allows online upgrades with zero data loss because of the use of the clean switchover process. There's no need for lengthy downtime during the upgrade, and there's much reduced risk in comparison with an in-place upgrade. It works best with new hardware, and is a good way to upgrade the hardware or change the disk layout at the same time. This is also very useful for changing server encoding.