mirror of
https://github.com/ubicloud/ubicloud.git
synced 2025-10-05 22:31:57 +08:00
This commit introduces the machinery to upgrade one server. The sequence of steps added here are mostly dictated by pg_upgrade prerequisites. The sequence of steps required roughly looks like the following: 1. Create an upgrade directory to run pg_upgrade in and give the postgres user ownership. pg_upgrade uses the current working directory to output certain files, and cannot be run as root. 2. Disable archiving, to prevent writing WAL for the newer version to the older timeline. 3. Promote the current PG, as pg_upgrade cannot be run if the current server is in recovery mode. 4. Disable the previous version. 5. Initialize an empty new version. 6. Stop the running new version to allow pg_upgrade to run. 7. Run pg_upgrade --check to detect any potential problems with the upgrade. 8. Run pg_upgrade 9. Enable the new version and wait for it to startup. 10. Run any post-upgrade scripts generated by pg_upgrade. 11. Run any extension-specific upgrade scripts. To execute the upgrade of a given server to a desired version, execute `postgres/bin/upgrade` with the desired version number as the argument. For extension upgrades, pg_upgrade is expected to produce the required scripts based on the versions currently in use and available in the newer version. The current workflow is to: 1. Update the extension binaries before pg_upgrade. 2. Run pg_upgrade. 3. Execute the generated update_extensions.sql file as the database superuser. 4. For specific extensions like PostGIS [2], run their specific upgrade scripts. At this point, upgrading from PG 16 to 17 with the current version of extensions installed by default does not warrant a special-case for any extension. [1]: https://www.postgresql.org/docs/current/pgupgrade.html [2]: https://postgis.net/workshops/postgis-intro/upgrades.html#pg-upgrade |
||
---|---|---|
.. | ||
hugepages_setup.rb | ||
pgbouncer_setup.rb | ||
postgres_extensions.rb | ||
postgres_setup.rb | ||
postgres_upgrade.rb |