User Tools

Site Tools


doc:appunti:linux:sa:postgresql_upgrade

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
doc:appunti:linux:sa:postgresql_upgrade [2020/03/02 17:20] – [Upgrade cluster from] niccolodoc:appunti:linux:sa:postgresql_upgrade [2022/07/07 10:53] (current) niccolo
Line 1: Line 1:
-====== PostgreSQL/PostGIS Upgrade ======+====== PostgreSQL/PostGIS Upgrade from 9.6 to 11 ======
  
 The present notes are about upgrading PostgreSQL from **Debian 9 Stretch** to **Debian 10 Buster**, i.e. upgrading from **PostgreSQL 9.6** to version **11** and consequently upgrading **PostGIS 2.3** to **PostGIS 2.5**. The present notes are about upgrading PostgreSQL from **Debian 9 Stretch** to **Debian 10 Buster**, i.e. upgrading from **PostgreSQL 9.6** to version **11** and consequently upgrading **PostGIS 2.3** to **PostGIS 2.5**.
Line 13: Line 13:
 11  main    5433 online postgres /var/lib/postgresql/11/main  /var/log/postgresql/postgresql-11-main.log 11  main    5433 online postgres /var/lib/postgresql/11/main  /var/log/postgresql/postgresql-11-main.log
 </code> </code>
 +
 +Notice that the new **11/main** cluster is running on the non-standard **TCP port 5433**.
  
 We can also verify that **all our databases** are running **into the old cluster** 9.6/main: We can also verify that **all our databases** are running **into the old cluster** 9.6/main:
Line 38: Line 40:
 The **pg_upgradecluster** can safely upgrade standard databases, but the relative manpage clearly states that: //Some PostgreSQL extensions like PostGIS need metadata in auxiliary tables which must not be upgraded from the old version, but rather initialized for the new version before copying the table data//. The **pg_upgradecluster** can safely upgrade standard databases, but the relative manpage clearly states that: //Some PostgreSQL extensions like PostGIS need metadata in auxiliary tables which must not be upgraded from the old version, but rather initialized for the new version before copying the table data//.
  
-So our strategy will be:+We have several standard (non-GIS) databases and a few PostGIS-enabled ones. You can see if the PostGIS extension is enabled issuing the **\dx** once connected to the database. So our strategy will be:
  
   - **Dump** the PostGIS-enabled databases into files.   - **Dump** the PostGIS-enabled databases into files.
-  - **Drop** PostGIS databases. +  - **Drop** the PostGIS databases. 
-  - Do a **pg_upgradecluster** to migrate all the remaining databases to the new cluster. +  - Do a **pg_upgradecluster** to migrate and upgrade all the non-GIS databases to the new cluster. 
-  - **Restore** PostGIS database from the dump files.+  - **Restore** the PostGIS databases from the dump files into the new cluster.
  
 ===== Dump and DROP the PostGIS databases ===== ===== Dump and DROP the PostGIS databases =====
Line 54: Line 56:
 </code> </code>
  
-now we can DROP them:+Then we DROP them:
  
 <code> <code>
Line 64: Line 66:
 ===== Upgrade cluster from 9.6 to 11 ===== ===== Upgrade cluster from 9.6 to 11 =====
  
-Drop the new 11 (empty) cluster:+Drop the new 11/main cluster (which should be indeed empty): 
 <code> <code>
 pg_dropcluster --stop 11 main pg_dropcluster --stop 11 main
Line 79: Line 82:
 <code> <code>
 Fixing hardcoded library paths for stored procedures... Fixing hardcoded library paths for stored procedures...
-Upgrading database non_gis_database... +Upgrading database nongis_database... 
-Analyzing database non_gis_database...+Analyzing database nongis_database...
 </code> </code>
  
-Verify the new situation. Notice that the new 11 cluster was moved to the default **TCP** port **5432**:+Verify the new situation. Notice that the new **11/main** cluster was moved to the default **TCP** port **5432** and it is the only one running:
  
 <code> <code>
Line 98: Line 101:
 </code> </code>
  
-Now the 11 main cluster is running as the postgres user, not as the regular systemd service. To fix this situation run the following as the postgres user:+Now the **11/main cluster** is running, but **started by the postgres user**. We want it to be started by the regular **systemd** subsystem. To fix the situation run the following **as the postgres user**:
  
 <code> <code>
Line 104: Line 107:
 </code> </code>
  
-and as the root user, restore proper systemd status:+and the following as the **root user**:
  
 <code> <code>
Line 113: Line 116:
 </code> </code>
  
 +===== Restore the PostGIS databases =====
 +
 +We need to CREATE the PostGIS databases as new, users should instead aready exist because they were automatically restored by **pg_upgradecluster**. As the postgres user:
 +
 +<code>
 +~$ psql
 +postgres=# CREATE DATABASE gis_database OWNER gis_owner ENCODING 'UTF8';
 +postgres=# \connect gis_database
 +gis_database=# CREATE EXTENSION postgis;
 +</code>
 +
 +Finally you can restore the dump, as a regular user (you will be prompted for the DB user password):
 +
 +<code>
 +~$ pg_restore -U gis_user -W -h localhost -d gis_database -Fc gis_database.dump
 +</code>
 +
 +**NOTICE**: during the restore some warnings will be printed, because some objects already exist into the database and they actually should be not restored: the **public** schema, the **plpgsql** language, the **postgis** extension and the **spatial_ref_sys** table.
doc/appunti/linux/sa/postgresql_upgrade.1583166041.txt.gz · Last modified: 2020/03/02 17:20 by niccolo