Les entreprises et les entreprises utilisant d'anciennes versions de PostgreSQL (PG) sont confrontées à des difficultés lors de la mise à niveau vers au moins la version stable la plus récente à partir de PostgreSQL 12 ou PostgreSQL 13. Il existe de nombreuses raisons pour lesquelles la mise à niveau vers la dernière version est une doit. Certaines des principales raisons à cela sont de tirer parti des améliorations critiques apportées à ses fonctionnalités intégrées, des mises à jour de sécurité, des améliorations des performances et des nouvelles implémentations bénéfiques pour la gestion de la base de données.
La mise à niveau de PostgreSQL comporte quelques défis car ce n'est pas aussi simple que d'autres bases de données grand public. Si vous rencontrez ce type de problème, ne vous inquiétez pas. PostgreSQL ne vous bloque pas sur une version spécifique à utiliser. Dans ce blog, nous allons parcourir un exemple de ce défi tout en ayant un TimescaleDB et PostGIS installés sur un hôte PostgreSQL 11 existant.
Pourquoi pg_upgrade ?
pg_upgrade existe depuis très longtemps comme outil de mise à jour des versions majeures de PostgreSQL. L'utilisation de cet outil n'est pas requise pour les mises à niveau de versions mineures, ce qui signifie que la mise à niveau de votre version actuelle de 11.9 vers 11.13 n'est pas nécessaire.
Lors de la mise à niveau de votre PostgreSQL vers une version majeure avec pg_upgrade, l'outil fonctionne en permettant aux données stockées dans les fichiers de données PostgreSQL d'être mises à niveau vers une version majeure ultérieure de PostgreSQL. Cela fonctionne sans avoir besoin d'un vidage/rechargement de données, ce qui peut prendre un certain temps si vous avez un grand ensemble de données.
Maintenant, voici le remue-ménage. PostgreSQL, en particulier pour les versions majeures, est connu pour avoir ajouté de nouvelles fonctionnalités qui modifient souvent la disposition des tables système, mais le format de stockage des données internes change rarement. pg_upgrade utilise ce fait pour effectuer des mises à jour rapides en créant de nouvelles tables système et en réutilisant simplement les anciens fichiers de données utilisateur. Si une future version majeure modifie le format de stockage des données d'une manière qui rend l'ancien format de données illisible, pg_upgrade ne sera pas utilisable pour de telles mises à jour. (La communauté tentera d'éviter de telles situations.)
Certains peuvent considérer pg_upgrade comme dangereux, en particulier pour l'environnement de production. Eh bien, cet outil a été largement utilisé ailleurs, de l'AQ au développement, en passant par les environnements de production. Il a ses limites ou mises en garde, telles que l'Unicode connu ou les jeux de caractères stockés dans votre jeu de données. Dans ce cas, vous pourriez envisager d'utiliser pg_dump/pg_restore, mais cela peut prendre un certain temps en fonction de la taille de vos données. Pour les versions plus récentes de PostgreSQL, telles que PG 14.0, vous ne pouvez effectuer qu'un vidage/restauration (ou exportation/importation) ou une réplication logique, sinon utilisez pg_upgrade.
Pour les ensembles de données plus volumineux, l'utilisation de pg_upgrade vous oblige à l'exécuter sur le même hôte, qui applique par défaut une copie de tous vos fichiers physiques à partir de votre répertoire de données. Dans ce cas, pg_upgrade prend en charge l'option -k ou --link, ce qui signifie qu'il utilisera des liens physiques au lieu de copier les fichiers vers le nouveau cluster.
pg_upgrade fait de son mieux pour s'assurer que l'ancien et le nouveau cluster sont compatibles avec les binaires, par exemple en vérifiant les paramètres de compilation compatibles, y compris les binaires 32/64 bits. Il est également important que tous les modules externes soient compatibles en binaire, bien que cela ne puisse pas être vérifié par pg_upgrade.
pg_upgrade prend en charge les mises à niveau de 8.4.X et versions ultérieures vers la version majeure actuelle de PostgreSQL, y compris les versions instantanées et bêta.
Voici la situation…
Dans cette configuration, j'ai utilisé ClusterControl pour déployer un cluster de base de données PostgreSQL 11 pour un seul nœud. Les éléments suivants ont été testés sur Centos 7 et Ubuntu Focal (20.04.1) :
$ /usr/pgsql-11/bin/postgres --version
postgres (PostgreSQL) 11.13
postgres=# \dx
List of installed extensions
Name | Version | Schema | Description
------------------------+---------+------------+-------------------------------------------------------------------
fuzzystrmatch | 1.1 | public | determine similarities and distance between strings
pg_stat_statements | 1.6 | public | track execution statistics of all SQL statements executed
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
postgis | 3.1.4 | public | PostGIS geometry and geography spatial types and functions
postgis_raster | 3.1.4 | public | PostGIS raster types and functions
postgis_sfcgal | 3.1.4 | public | PostGIS SFCGAL functions
postgis_tiger_geocoder | 3.1.4 | tiger | PostGIS tiger geocoder and reverse geocoder
postgis_topology | 3.1.4 | topology | PostGIS topology spatial types and functions
timescaledb | 2.3.1 | public | Enables scalable inserts and complex queries for time-series data
(9 rows)Alors j'ai obtenu ce qui suit,
Version du serveur PostgreSQL : 11.13
Version TimescaleDB : 2.3.1
Version PostGIS : 3.1.4
Si vous voulez tester cela avec ClusterControl, il y a deux façons d'avoir TimescaleDB. Vous pouvez déployer un cluster TimescaleDB ou avoir PostgreSQL et activer le plugin TimescaleDB.
Configuration pour votre PostgreSQL 13
L'utilisation de la configuration de votre gestionnaire de packages pour l'environnement Linux avec votre référentiel PostgreSQL et TimescaleDB est plus simple. Voici les étapes à suivre :
Configurer les référentiels requis
Commençons par ajouter le référentiel PostgreSQL.
Pour CentOS/RHEL/Oracle Linux
Vous devez vous assurer que vous disposez du bon référentiel. Pour Enterprise Linux (EL) 7, vous pouvez effectuer les opérations suivantes :
sudo yum -y install https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpmPour une autre architecture, vous pouvez baser ici https://download.postgresql.org/pub/repos/yum/reporpms/ et remplacer le sous-répertoire EL-7-x86_64.
Ajoutons également le référentiel TimescaleDB.
vi /etc/yum.repos.d/timescale_timescaledb.repoEnsuite, ajoutez le contenu suivant pour ce fichier,
[timescale_timescaledb]
name=timescale_timescaledb
baseurl=https://packagecloud.io/timescale/timescaledb/el/7/\$basearch
repo_gpgcheck=1
gpgcheck=0
enabled=1
gpgkey=https://packagecloud.io/timescale/timescaledb/gpgkey
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300Remplacez simplement la baseurl en conséquence si vous utilisez une version autre que EL 7.
Pour Ubuntu/Debian
Ajouter le référentiel PG pour Ubuntu Focal :
deb http://apt.postgresql.org/pub/repos/apt/ focal-pgdg mainPour les autres distributions Ubuntu/Debian, remplacez simplement le focal en conséquence, que vous pouvez trouver ici http://apt.postgresql.org/pub/repos/apt/dists/. Par exemple, remplacez focal-pgdg par buster-pgdg.
Maintenant, ajoutons le référentiel pour TimescaleDB,
sudo sh -c "echo 'deb [signed-by=/usr/share/keyrings/timescale.keyring] https://packagecloud.io/timescale/timescaledb/ubuntu/ $(lsb_release -c -s) main' > /etc/apt/sources.list.d/timescaledb.list"Importer le trousseau de clés,
wget --quiet -O - https://packagecloud.io/timescale/timescaledb/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/timescale.keyringet mettre à jour les listes de packages pour les mises à niveau des packages nécessitant une mise à niveau, ainsi que les nouveaux packages qui viennent d'arriver dans les référentiels.
sudo apt-get updateVous pouvez remplacer le sous-répertoire dans l'URL si vous utilisez Debian depuis Ubuntu.
Maintenant que le référentiel est prêt, nous sommes prêts à partir.
Installer PostgreSQL version 13 avec TimescaleDB et PostGIS
L'installation de PostgreSQL 13 peut être effectuée sur le même hôte. Tout d'abord, vous devez vous assurer que des éléments tels que le port de la base de données sont uniques. En d'autres termes, il doit être différent du PostgreSQL 11 actuel installé sur le même hôte.
Pour CentOS/RHEL/Oracle Linux
Exécutez la commande ci-dessous pour installer PostgreSQL 13 et ses packages dépendants :
yum install postgresql13.x86_64 postgresql13-server.x86_64 postgresql13-contrib.x86_64 postgresql13-libs.x86_64 Ensuite, initialisez le cluster de bases de données et sa collection de bases de données requise en exécutant la commande ci-dessous :
$ /usr/pgsql-13/bin/postgresql-13-setup initdbÀ ce stade, il devrait y avoir deux répertoires de données pour PG 11 et PG 13 :
[[email protected] ~]# ls -alth /var/lib/pgsql/* -d
drwx------. 4 postgres postgres 51 Sep 22 14:19 /var/lib/pgsql/13
drwx------. 4 postgres postgres 33 Sep 21 18:53 /var/lib/pgsql/11Maintenant que nous sommes bons avec PostgreSQL 13, installons TimescaleDB. Nous devons nous assurer que le plug-in à installer est de la même version sur PostreSQL 11.
Notez que, pour vous assurer que pg_upgrade fonctionnera correctement, les plugins de votre source et de votre destination de version majeure doivent être de la même version. En effet, pg_upgrade recherchera ses bibliothèques désignées liées aux plugins ou extensions qui ont été chargés ou utilisés par votre ancienne version de base de données ou source de votre PostgreSQL. Vous pouvez le vérifier dans votre Enterprise Linux en exécutant showduplicates ou en vérifiant avec des informations comme ci-dessous avec dnf ou yum :
$ yum --showduplicates list timescaledb_13.x86_64 timescaledb-2-postgresql-13.x86_64 timescaledb-2-oss-postgresql-13.x86_64 timescaledb-2-loader-postgresql-13.x86_64|grep '2.3.1'
Repository pgdg-common is listed more than once in the configuration
timescaledb-2-loader-postgresql-13.x86_64 2.3.1-0.el7 timescale_timescaledb
timescaledb-2-oss-postgresql-13.x86_64 2.3.1-0.el7 timescale_timescaledb
timescaledb-2-postgresql-13.x86_64 2.3.1-0.el7 timescale_timescaledbOu vérifiez-le avec l'option info :
$ yum info timescaledb-2-loader-postgresql-13-2.3.1-0.el7.x86_64 timescaledb-2-postgresql-13-2.3.1-0.el7.x86_64Nous sommes maintenant prêts à installer le package TimescaleDB pour la version PG 13.
$ yum install timescaledb-2-loader-postgresql-13-2.3.1-0.el7.x86_64 timescaledb-2-postgresql-13-2.3.1-0.el7.x86_64Après l'avoir installé, vous pouvez essayer d'exécuter l'outil timescaledb-tune pour régler votre fichier de configuration postgresql.conf. Exécutez simplement la commande ci-dessous :
$ timescaledb-tune --pg-config=/usr/pgsql-13/bin/pg_configMaintenant, installons également le package PostGIS pour la version PG 13.
$ yum install -y postgis31_13.x86_64 Pour Ubuntu/Debian
Exécutez simplement :
$ apt install postgresql-client-13 postgresql-13L'avantage des distributions Ubuntu/Debian est qu'il existe des outils pour PostgreSQL qui sont très pratiques pour gérer vos clusters PostgreSQL, tels que pg_lsclusters, pg_ctlcluster, etc.
Vous pouvez vérifier vos clusters disponibles installés.
$ pg_lsclusters
Ver Cluster Port Status Owner Data directory Log file
11 main 5432 online postgres /var/lib/postgresql/11/main log/postgresql-%Y-%m-%d_%H%M%S.log
13 main 5433 online postgres /var/lib/postgresql/13/main /var/log/postgresql/postgresql-13-main.logDans Ubuntu/Debian, il n'est pas nécessaire de changer le port car il sera géré pendant la phase d'installation et il le détecte et le définit de manière unique, en conséquence.
Maintenant, installons TimescaleDB.
$ apt install timescaledb-2-loader-postgresql-13 timescaledb-2-postgresql-13Facultativement, vous pouvez exécuter l'outil timescaledb-tune pour régler votre fichier de configuration postgresql.conf en appelant simplement l'outil comme suit :
$ timescaledb-tuneNous sommes maintenant prêts à installer le package PostGIS pour PG 13.
$ apt install postgresql-13-postgis-3-scripts postgresql-13-postgis-3
Revoyez votre postgresql.conf
Il est toujours préférable de revoir votre fichier de configuration postgresql.conf. Dans les versions Enterprise Linux, vous pouvez localiser votre postgresql.conf soit dans votre répertoire data_directory, soit dans le chemin PGDATA. Alors que pour Ubuntu/Debian, vous pouvez le localiser dans /etc/postgresql/
shared_preload_libraries = 'pg_stat_statements,timescaledb' # pg_stat_statements is not required but if you are using ClusterControl, make sure this is appended.
port = 5532 # make sure that the port number is unique than the old version of your PostgreSQL
listen_address = * # depends on your setup but if you need to specify the available network interfaces to its IP addresses (IPv4 or IPv6) set it accordingly.Il est recommandé de comparer vos anciennes et nouvelles versions de vos fichiers de configuration PostgreSQL pour vous assurer que votre postgresql.conf est identique à ce qui est nécessaire et défini.
Avant de passer à l'étape suivante, nous devons également vérifier que votre version 13 de PostgreSQL est chargée en conséquence. Assurez-vous que vous disposez de la dernière version acquise ou installée sur votre hébergeur. Démarrez la base de données et assurez-vous qu'elle démarre et s'exécute correctement.
Pour démarrer dans les distributions EL, exécutez la commande ci-dessous :
$ sudo -iu postgres /usr/pgsql-13/bin/pg_ctl -D /var/lib/pgsql/13/data/ -o "-c config_file=/var/lib/pgsql/13/data/postgresql.conf" startou pour Ubuntu/Debian, exécutez la commande ci-dessous :
$ sudo -iu postgres /usr/lib/postgresql/13/bin/pg_ctl -D /var/lib/postgresql/13/main/ -o "-c config_file=/etc/postgresql/13/main/postgresql.conf" startou utilisez l'outil pg_ctlcluster pour démarrer, redémarrer ou arrêter votre cluster PG.
Lorsque vous êtes prêt, exécutez pg_upgrade…
Avant de continuer, assurez-vous d'abord que votre sauvegarde de votre ancien serveur est toujours prête et disponible. Prenez toujours une sauvegarde logique et une sauvegarde physique comme bonne pratique avant de procéder à une mise à niveau majeure.
Maintenant que vous êtes prêt, vous pouvez exécuter pg_upgrade. En pratique, vous devez d'abord exécuter pg_upgrade avec une vérification pour déterminer l'incompatibilité et les problèmes avant de passer à la procédure principale de pg_upgrade. Avant d'exécuter pg_upgrade, assurez-vous que PG 11 et PG 13 sont en panne pendant ce processus. Cela signifie simplement qu'un temps d'arrêt est nécessaire pour ce processus.
Pour ce faire, exécutez la commande suivante avec l'option --check :
$ sudo -iu postgres /usr/lib/postgresql/13/bin/pg_upgrade -o "-c config_file=/etc/postgresql/11/main/postgresql.conf" --old-datadir=/var/lib/postgresql/11/main/ -O "-c config_file=/etc/postgresql/13/main/postgresql.conf" --new-datadir=/var/lib/postgresql/13/main/ --old-bindir=/usr/lib/postgresql/11/bin --new-bindir=/usr/lib/postgresql/13/bin --checkRemplacez la valeur --old-datadir ou config_file en conséquence si elle est différente de votre configuration.
Cela exécutera des vérifications de compatibilité comme le résultat ci-dessous :
Performing Consistency Checks
-----------------------------
Checking cluster versions ok
Checking database user is the install user ok
Checking database connection settings ok
Checking for prepared transactions ok
Checking for system-defined composite types in user tables ok
Checking for reg* data types in user tables ok
Checking for contrib/isn with bigint-passing mismatch ok
Checking for tables WITH OIDS ok
Checking for invalid "sql_identifier" user columns ok
Checking for presence of required libraries ok
Checking database user is the install user ok
Checking for prepared transactions ok
Checking for new cluster tablespace directories ok
*Clusters are compatible*Si toutes les vérifications signalent "ok", cela signifie une vérification réussie, et le message du bas indique que les clusters sont compatibles, alors vous devriez être prêt à partir.
Enfin, exécutez à nouveau la commande sans l'option --check :
$ sudo -iu postgres /usr/lib/postgresql/13/bin/pg_upgrade -o "-c config_file=/etc/postgresql/11/main/postgresql.conf" --old-datadir=/var/lib/postgresql/11/main/ -O "-c config_file=/etc/postgresql/13/main/postgresql.conf" --new-datadir=/var/lib/postgresql/13/main/ --old-bindir=/usr/lib/postgresql/11/bin --new-bindir=/usr/lib/postgresql/13/bin
Performing Consistency Checks
-----------------------------
Checking cluster versions ok
Checking database user is the install user ok
Checking database connection settings ok
Checking for prepared transactions ok
Checking for system-defined composite types in user tables ok
Checking for reg* data types in user tables ok
Checking for contrib/isn with bigint-passing mismatch ok
Checking for tables WITH OIDS ok
Checking for invalid "sql_identifier" user columns ok
Creating dump of global objects ok
Creating dump of database schemas ok
Checking for presence of required libraries ok
Checking database user is the install user ok
Checking for prepared transactions ok
Checking for new cluster tablespace directories ok
If pg_upgrade fails after this point, you must re-initdb the
new cluster before continuing.
Performing Upgrade
------------------
Analyzing all rows in the new cluster ok
Freezing all rows in the new cluster ok
Deleting files from new pg_xact ok
Copying old pg_xact to new server ok
Setting oldest XID for new cluster ok
Setting next transaction ID and epoch for new cluster ok
Deleting files from new pg_multixact/offsets ok
Copying old pg_multixact/offsets to new server ok
Deleting files from new pg_multixact/members ok
Copying old pg_multixact/members to new server ok
Setting next multixact ID and offset for new cluster ok
Resetting WAL archives ok
Setting frozenxid and minmxid counters in new cluster ok
Restoring global objects in the new cluster ok
Restoring database schemas in the new cluste ok
Copying user relation files ok
Setting next OID for new cluster ok
Sync data directory to disk ok
Creating script to analyze new cluster ok
Creating script to delete old cluster ok
Checking for extension updates notice
Your installation contains extensions that should be updated
with the ALTER EXTENSION command. The file
update_extensions.sql
when executed by psql by the database superuser will update
these extensions.
Upgrade Complete
----------------
Optimizer statistics are not transferred by pg_upgrade so,
once you start the new server, consider running:
./analyze_new_cluster.sh
Running this script will delete the old cluster's data files:
./delete_old_cluster.shSelon la taille de votre ensemble de données, cela peut prendre un peu de temps. Dans l'exemple de commande ci-dessus, il copie les journaux de transactions, qui sont des fichiers physiques. Cependant, si la taille de votre disque est restreinte, vous pouvez utiliser l'option -k ou --link, qui utilise des liens physiques. Si tout se passe bien, il devrait vous fournir des messages tels que ceux ci-dessus vous informant de la mise à jour complète et des avis pour mettre à jour les extensions que vous pourriez avoir. Dans cette configuration, tout se passe bien. Le fichier update_extensions.sql ne contient que les éléments suivants :
$ cat update_extensions.sql
\connect postgres
ALTER EXTENSION "pg_stat_statements" UPDATE;Comme vous l'avez remarqué, pg_upgrade effectue une série d'actions. Il analyse toutes les lignes du cluster source, en copiant les journaux de métadonnées de transaction et ses données d'état multi-transactions et le reste.
Une fois que vous avez compris que tout semble bon, exécutez le script analyze_new_cluster.sh, qui doit s'exécuter
vacuumdb --all --analyze-only.
$ sudo -iu postgres PGPORT=5433 ./analyze_new_cluster.shNotez que vous devez spécifier le port de votre PostgreSQL 13 afin que vacuumdb s'exécute correctement sur le bon serveur cible.
Dans ce cas, le résultat de la mise à niveau avec les extensions TimescaleDB et PostGIS activées se passe bien. Une fois que tout apparaît dans l'ordre, assurez-vous de démarrer le serveur et de faire une série de tests et de vérifications.
Tester le processus de mise à jour
Testez et révisez toujours le processus de mise à niveau. Voici quelques tables et une base de données définie par l'utilisateur, qui contient des hypertables et des tables PostGIS qui reposent sur l'utilisation de fonctions et de types spatiaux de géométrie et de géographie.
$ sudo -iu postgres psql -p5433
psql (13.4 (Ubuntu 13.4-1.pgdg20.04+1))
Type "help" for help.
postgres=# \l
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
-----------+----------+----------+---------+---------+-----------------------
mydb | postgres | UTF8 | C.UTF-8 | C.UTF-8 |
postgres | postgres | UTF8 | C.UTF-8 | C.UTF-8 |
template0 | postgres | UTF8 | C.UTF-8 | C.UTF-8 | =c/postgres +
| | | | | postgres=CTc/postgres
template1 | postgres | UTF8 | C.UTF-8 | C.UTF-8 | postgres=CTc/postgres+
| | | | | =c/postgres
(4 rows)
postgres=# \c mydb
You are now connected to database "mydb" as user "postgres".
mydb=# set search_path="$user",public;
SET
mydb=# \dt+
List of relations
Schema | Name | Type | Owner | Persistence | Size | Description
--------+-----------------+-------+----------+-------------+------------+-------------
public | conditions | table | postgres | permanent | 8192 bytes |
public | global_points | table | postgres | permanent | 16 kB |
public | roads | table | postgres | permanent | 16 kB |
public | sample_table | table | postgres | permanent | 8192 bytes |
public | spatial_ref_sys | table | postgres | permanent | 6968 kB |
(5 rows)Vérification de certains de mes PostGIS et hypertables :
mydb=# \d roads
Table "public.roads"
Column | Type | Collation | Nullable | Default
------------+----------------------+-----------+----------+---------
road_id | integer | | |
road_name | character varying | | |
roads_geom | geometry(LineString) | | |
mydb=# \d sample_table
Table "public.sample_table"
Column | Type | Collation | Nullable | Default
--------+--------------------------+-----------+----------+------------------------------------------
id | integer | | not null | nextval('sample_table_id_seq'::regclass)
time | timestamp with time zone | | not null |
name | character varying | | not null |
Indexes:
"sample_table_pkey" PRIMARY KEY, btree (id, "time")
"sample_table_time_idx" btree ("time" DESC)
Triggers:
ts_insert_blocker BEFORE INSERT ON sample_table FOR EACH ROW EXECUTE FUNCTION _timescaledb_internal.insert_blocker()
Number of child tables: 371 (Use \d+ to list them.)
mydb=# \d conditions
Table "public.conditions"
Column | Type | Collation | Nullable | Default
-------------+--------------------------+-----------+----------+---------
time | timestamp with time zone | | not null |
location | text | | not null |
location2 | character(10) | | not null |
temperature | double precision | | |
humidity | double precision | | |
Indexes:
"conditions_time_idx" btree ("time" DESC)
Triggers:
ts_insert_blocker BEFORE INSERT ON conditions FOR EACH ROW EXECUTE FUNCTION _timescaledb_internal.insert_blocker()
Number of child tables: 366 (Use \d+ to list them.)
mydb=# select count(*) from sample_table;
count
-------
2588
(1 row)
mydb=# SELECT name FROM global_points WHERE ST_DWithin(location, 'SRID=4326;POINT(-110 29)'::geography, 1000000);
name
--------
Town
Forest
(2 rows)
mydb=# SELECT n, ST_AsEWKT(ST_GeometryN(the_geom, n)) As geomewkt
mydb-# FROM (
mydb(# VALUES (ST_GeomFromEWKT('MULTIPOINT(1 2 7, 3 4 7, 5 6 7, 8 9 10)') ),
mydb(# ( ST_GeomFromEWKT('MULTICURVE(CIRCULARSTRING(2.5 2.5,4.5 2.5, 3.5 3.5), (10 11, 12 11))') )
mydb(# )As foo(the_geom)
mydb-# CROSS JOIN generate_series(1,100) n
mydb-# WHERE n <= ST_NumGeometries(the_geom);
n | geomewkt
---+-----------------------------------------
1 | POINT(1 2 7)
1 | CIRCULARSTRING(2.5 2.5,4.5 2.5,3.5 3.5)
2 | POINT(3 4 7)
2 | LINESTRING(10 11,12 11)
3 | POINT(5 6 7)
4 | POINT(8 9 10)
(6 rows)Maintenant, tout semble prêt à servir de nouveau cluster.
Une fois que vous avez démarré, vous pouvez exécuter :
$ sudo -iu postgres ./delete_old_cluster.shAssurez-vous de n'exécuter que le script car il s'agit d'un script très dangereux, car il supprimera tous les fichiers de votre ancien cluster PostgreSQL.
Conclusion
pg_upgrade est un excellent outil pour gérer et mettre à niveau votre serveur de base de données PostgreSQL. Il peut gérer des configurations complexes telles que les extensions TimescaleDB ou PostGIS activées. Bien que cet outil ait ses limites, rien ne vous empêche de l'utiliser, en particulier pour votre travail DBA et sur les serveurs de production en dehors des environnements d'assurance qualité et de développement.
