29.13. Mise à jour

» » »

Précédent	Niveau supérieur	Suivant
29.12. Paramètres de configuration	Sommaire	29.14. Démarrage rapide

29.13. Mise à jour #

29.13.1. Préparations pour les mises à jour d'un publieur
29.13.2. Préparations pour les mises à jour d'un abonné
29.13.3. Mettre à jour des clusters de réplication logique

Les migrations d'instances en réplication logique sont possibles seulement quand tous les membres des anciennes instances en réplication logique sont en version 17 ou ultérieur.

29.13.1. Préparations pour les mises à jour d'un publieur #

pg_upgrade tente de migrer les slots de réplication logique. Ceci aide à éviter le besoin de définir manuellement les mêmes slots de réplication sur le nouveau publieur. La migration des slots de réplication logique est uniquement prise en compte quand l'ancienne instance est de version 17 ou ultérieur. Les slots logiques sur des instances de version antérieure à la 17 seront ignorés silencieusement.

Avant de commencer à mettre à jour l'instance publieur, assurez-vous que l'abonnement est désactivé temporairement en exécutant ALTER SUBSCRIPTION ... DISABLE. Ré-activez l'abonnement après la mise à jour.

Il existe quelques prérequis pour que pg_upgrade soit capable de mettre à jour les slots logiques. S'ils ne sont pas rencontrés, une erreur sera levée.

La nouvelle instance doit avoir wal_level à logical.
La nouvelle instance doit avoir max_replication_slots configuré à une valeur supérieure ou égale au nombre de slots présents sur l'ancienne instance.
Les plugins en sortie référencés par les slots de l'ancienne instance doivent être installés dans le nouveau répertoire des exécutables de PostgreSQL.
L'ancienne instance a répliqué toutes les transactions et tous les messages de décodage logique aux abonnés.
Tous les slots de l'ancienne instance doivent être utilisables, donc il ne doit y avoir aucun socle pour lequel pg_replication_slots.conflicting ne vaut pas true.
La nouvelle instance ne doit pas avoir de slots logiques permanents, donc il ne doit y avoir aucun slot pour lequel pg_replication_slots.temporary vaut false.

29.13.2. Préparations pour les mises à jour d'un abonné #

Modifier les configurations de l'abonné vers le nouvel abonné. pg_upgrade tente de migrer les dépendances de l'abonnement qui incluent les informations des tables abonnées présentes dans le catalogue système pg_subscription_rel ainsi que l'origine de la réplication de l'abonnement. Ceci permet à la réplication logique sur le nouvel abonné de continuer à partir de l'endroit où l'ancien abonné s'était arrêté. La migration des dépendances de l'abonnement est seulement prise en compte quand l'ancienne instance est de version 17 ou ultérieure. Les dépendances d'abonnement pour des instances antérieures à la version 17 sont ignorées silencieusement.

Il existe quelques prérequis pour que pg_upgrade soit capable de mettre à jour les abonnements. S'ils ne sont pas rencontrés, une erreur sera remontée.

Toutes les tables de l'abonnement sur l'ancien abonné doivent être dans l'état i (initialisation) ou r (prête). Ceci peut se vérifier en regardant le champ srsubstate de la vue pg_subscription_rel.
L'entrée de l'origine de réplication correspondant à chacun des abonnements doit exister dans l'ancienne instance. Ceci peut se vérifier en regardant les catalogues systèmes pg_subscription et pg_replication_origin.
La nouvelle instance doit avoir le paramètre max_active_replication_origins configuré à une valeur supérieure ou égale au nombre d'abonnements présents dans l'ancienne instance.

29.13.3. Mettre à jour des clusters de réplication logique #

Lors de la mise à jour d'un abonné, les opérations en écriture peuvent se faire sur le publieur. Ces changements seront répliqués sur l'abonné une fois la mise à jour de l'abonné terminé.

Note

Les restrictions de la réplication logique s'appliquent aussi aux mises à jour d'un cluster de réplication logique. Voir Section 29.8 pour plus de détails.

Les prérequis d'une mise à jour d'un publieur s'appliquent aussi aux mises à jour d'un cluster de réplication logique. Voir Section 29.13.1 pour plus de détails.

Les prérequis d'une mise à jour d'un abonné s'appliquent aussi aux mises à jour d'un cluster de réplication logique. Voir Section 29.13.2 pour plus de détails.

Avertissement

Mettre à jour un cluster de réplication logique requiert la réalisation de plusieurs étapes sur plusieurs nœuds. Comme toutes les opérations ne sont pas transactionnelles, l'utilisateur est avisé à réaliser des sauvegardes comme décrit dans Section 25.3.2.

Les étapes pour mettre à jour des clusters de réplication logique sont détaillées ci-dessous :

Suivre les étapes indiquées dans Section 29.13.3.1 pour mettre à jour un cluster de réplication logique à deux nœuds.
Suivre les étapes indiquées dans Section 29.13.3.2 pour mettre à jour un cluster de réplication logique en cascade.
Suivre les étapes indiquées dans Section 29.13.3.3 pour mettre à jour un cluster de réplication logique circulaire à deux nœuds.

29.13.3.1. Étapes pour mettre à jour un cluster de réplication logique à deux nœuds #

Disons que le publieur est sur node1 et l'abonné est sur node2. L'abonné node2 a un abonnement sub1_node1_node2 qui récupère les changements de node1.

Désactivez tous les abonnements sur node2 qui sont récupèrent les changements de node1 en utilisant ALTER SUBSCRIPTION ... DISABLE, par exemple :
```
/* node2 # */ ALTER SUBSCRIPTION sub1_node1_node2 DISABLE;
```
Arrêtez le serveur publieur sur node1, par exemple :
```
pg_ctl -D /opt/PostgreSQL/data1 stop
```
Initialisez l'instance data1_upgraded en utilisant dans la nouvelle version requise.

Mettez à jour le serveur publieur node1 à la nouvelle version requise, par exemple :

pg_upgrade
        --old-datadir "/opt/PostgreSQL/postgres/17/data1"
        --new-datadir "/opt/PostgreSQL/postgres/18/data1_upgraded"
        --old-bindir "/opt/PostgreSQL/postgres/17/bin"
        --new-bindir "/opt/PostgreSQL/postgres/18/bin"

Démarrez le serveur publieur mis à jour sur node1, par exemple :
```
pg_ctl -D /opt/PostgreSQL/data1_upgraded start -l logfile
```
Arrêtez le serveur abonné sur node2, par exemple :
```
pg_ctl -D /opt/PostgreSQL/data2 stop
```
Initialisez l'instance data2_upgraded en utilisant la nouvelle version requise.

Mettez à jour le serveur abonné sur node2 à la nouvelle version requise, par exemple :

pg_upgrade
       --old-datadir "/opt/PostgreSQL/postgres/17/data2"
       --new-datadir "/opt/PostgreSQL/postgres/18/data2_upgraded"
       --old-bindir "/opt/PostgreSQL/postgres/17/bin"
       --new-bindir "/opt/PostgreSQL/postgres/18/bin"

Démarrez le serveur abonné mis à jour sur node2, par exemple :
```
pg_ctl -D /opt/PostgreSQL/data2_upgraded start -l logfile
```
Sur node2, créez toute table qui a été créé sur le serveur publieur mis à jour node1 entre Étape 1 et maintenant :
```
/* node2 # */ CREATE TABLE distributors (did integer PRIMARY KEY, name varchar(40));
CREATE TABLE
```
Activez tous les abonnements sur node2 qui récupèrent des modifications de node1 en utilisant ALTER SUBSCRIPTION ... ENABLE, donc :
```
/* node2 # */ ALTER SUBSCRIPTION sub1_node1_node2 ENABLE;
```
Rafraichissez les publications pour les abonnements de node2 en utilisant : ALTER SUBSCRIPTION ... REFRESH PUBLICATION, donc :
```
/* node2 # */ ALTER SUBSCRIPTION sub1_node1_node2 REFRESH PUBLICATION;
```

Note

Dans les étapes décrites ci-dessus, le publieur est tout d'abord mis à jour, suivi par l'abonné. Autrement, l'utilisateur peut utiliser des étapes similaires pour mettre à jour l'abonné dans un premier temps, puis mettre à jour le publieur.

29.13.3.2. Étapes pour mettre à jour un cluster de réplication logique en cascade #

Disons que nous avons une configuration de réplication logique en cascade du type node1->node2->node3. Ici node2 est abonné aux modifications de node1 et node3 est abonné aux modifications de node2. node2 a l'abonnement sub1_node1_node2 pour les modifications de node1. node3 a l'abonnement sub1_node2_node3 pour les modifications de node2.

Désactivez tous les abonnements sur node2 qui récupèrent les modifications provenant de node1 en utilisant ALTER SUBSCRIPTION ... DISABLE, donc :
```
/* node2 # */ ALTER SUBSCRIPTION sub1_node1_node2 DISABLE;
ALTER SUBSCRIPTION
```
Arrêtez le serveur sur node1, donc :
```
pg_ctl -D /opt/PostgreSQL/data1 stop
```
Initialisez l'instance data1_upgraded en utilisant la nouvelle version requise.

Mettez à jour le serveur de node1 vers la nouvelle version requise, donc :

pg_upgrade
        --old-datadir "/opt/PostgreSQL/postgres/17/data1"
        --new-datadir "/opt/PostgreSQL/postgres/18/data1_upgraded"
        --old-bindir "/opt/PostgreSQL/postgres/17/bin"
        --new-bindir "/opt/PostgreSQL/postgres/18/bin"

Démarrez le serveur mis à jour sur node1, donc :

pg_ctl -D /opt/PostgreSQL/data1_upgraded start -l logfile

Désactivez tous les abonnements sur node3 qui récupèrent les modifications provenant de node2 en utilisant ALTER SUBSCRIPTION ... DISABLE, donc :
```
/* node3 # */ ALTER SUBSCRIPTION sub1_node2_node3 DISABLE;
```
Arrêtez le serveur sur node2, donc :
```
pg_ctl -D /opt/PostgreSQL/data2 stop
```
Initialisez l'instance data2_upgraded en utilisant la nouvelle version requise.

Mettez à jour le serveur de node2 vers la nouvelle version requise, donc :

pg_upgrade
        --old-datadir "/opt/PostgreSQL/postgres/17/data2"
        --new-datadir "/opt/PostgreSQL/postgres/18/data2_upgraded"
        --old-bindir "/opt/PostgreSQL/postgres/17/bin"
        --new-bindir "/opt/PostgreSQL/postgres/18/bin"

Démarrez le serveur mis à jour sur node2, donc :

pg_ctl -D /opt/PostgreSQL/data2_upgraded start -l logfile

Sur node2, créez toute table qui a été créée sur le publieur mis à jour, donc node1, entre Étape 1 et maintenant, par exemple :
```
/* node2 # */ CREATE TABLE distributors (did integer PRIMARY KEY, name varchar(40));
CREATE TABLE
```
Activez tous les abonnements de node2 qui récupèrent les modifications sur node1 en utilisant ALTER SUBSCRIPTION ... ENABLE, donc :
```
/* node2 # */ ALTER SUBSCRIPTION sub1_node1_node2 ENABLE;
```
Rafraichissez les publications des abonnements de node2 en utilisant ALTER SUBSCRIPTION ... REFRESH PUBLICATION, donc :
```
/* node2 # */ ALTER SUBSCRIPTION sub1_node1_node2 REFRESH PUBLICATION;
```
Arrêtez le serveur sur node3, donc :
```
pg_ctl -D /opt/PostgreSQL/data3 stop
```
Initialisez l'instance data3_upgraded en utilisant la nouvelle version requise.

Mettez à jour le serveur de node3 vers la nouvelle version requise, donc :

pg_upgrade
        --old-datadir "/opt/PostgreSQL/postgres/17/data3"
        --new-datadir "/opt/PostgreSQL/postgres/18/data3_upgraded"
        --old-bindir "/opt/PostgreSQL/postgres/17/bin"
        --new-bindir "/opt/PostgreSQL/postgres/18/bin"

Démarrez le serveur mis à jour sur node3, donc :

pg_ctl -D /opt/PostgreSQL/data3_upgraded start -l logfile

Sur node3, créez toute table qui a été créée sur le serveur node2 entre Étape 6 et maintenant, donc :
```
/* node3 # */ CREATE TABLE distributors (did integer PRIMARY KEY, name varchar(40));
CREATE TABLE
```
Activez tous les abonnements sur node3 qui récupèrent les modifications provenant de node2 en utilisant ALTER SUBSCRIPTION ... ENABLE, donc :
```
/* node3 # */ ALTER SUBSCRIPTION sub1_node2_node3 ENABLE;
```
Rafraichissez les publications des abonnements de node3 en utilisant ALTER SUBSCRIPTION ... REFRESH PUBLICATION, donc :
```
/* node3 # */ ALTER SUBSCRIPTION sub1_node2_node3 REFRESH PUBLICATION;
```

29.13.3.3. Étapes pour mettre à jour une instance de réplication logique circulaire à 2 nœuds #

Disons que nous avons une configuration de réplication logique circulaire avec node1->node2 et node2->node1. Ici, node2 est abonné aux modifications de node1 et node1 est abonné aux modifications de node2. node1 a l'abonnement sub1_node2_node1 qui récupère les modifications de node2. node2 a l'abonnement sub1_node1_node2 qui récupère les modifications de node1.

Désactivez tous les abonnements sur node2 qui récupèrent les modifications provenant de node1 en utilisant ALTER SUBSCRIPTION ... DISABLE, donc :
```
/* node2 # */ ALTER SUBSCRIPTION sub1_node1_node2 DISABLE;
```
Arrêtez le serveur sur node1, donc :
```
pg_ctl -D /opt/PostgreSQL/data1 stop
```
Initialisez l'instance data1_upgraded en utilisant la nouvelle version requise.

Mettez à jour le serveur de node1 vers la nouvelle version requise, donc :

pg_upgrade
        --old-datadir "/opt/PostgreSQL/postgres/17/data1"
        --new-datadir "/opt/PostgreSQL/postgres/18/data1_upgraded"
        --old-bindir "/opt/PostgreSQL/postgres/17/bin"
        --new-bindir "/opt/PostgreSQL/postgres/18/bin"

Démarrez le serveur mis à jour node1, donc :

pg_ctl -D /opt/PostgreSQL/data1_upgraded start -l logfile

Activez tous les abonnements sur node2 qui récupèrent les modifications provenant de node1 en utilisant ALTER SUBSCRIPTION ... ENABLE, donc :
```
/* node2 # */ ALTER SUBSCRIPTION sub1_node1_node2 ENABLE;
```
Sur node1, créez toute table qui a été créée sur node2 entre Étape 1 et maintenant, par exemple :
```
node1=# CREATE TABLE distributors (did integer PRIMARY KEY, name varchar(40));
```
Rafraichissez les publications des abonnements de node1 pour copier les données des tables de node2 en utilisant ALTER SUBSCRIPTION ... REFRESH PUBLICATION, e.g.:
```
node1=# ALTER SUBSCRIPTION sub1_node2_node1 REFRESH PUBLICATION;
```
Désactivez tous les abonnements sur node1 qui récupèrent les modifications dprovenant de node2 en utilisant ALTER SUBSCRIPTION ... DISABLE, donc :
```
node1=# ALTER SUBSCRIPTION sub1_node2_node1 DISABLE;
```
Arrêtez le serveur sur node2, donc :
```
pg_ctl -D /opt/PostgreSQL/data2 stop
```
Initialisez l'instance data2_upgraded en utilisant la nouvelle version requise.

Mettez à jour le serveur sur node2 vers la nouvelle version requise, donc :

pg_upgrade
        --old-datadir "/opt/PostgreSQL/postgres/17/data2"
        --new-datadir "/opt/PostgreSQL/postgres/18/data2_upgraded"
        --old-bindir "/opt/PostgreSQL/postgres/17/bin"
        --new-bindir "/opt/PostgreSQL/postgres/18/bin"

Démarrez le serveur mis à jour sur node2, donc :

pg_ctl -D /opt/PostgreSQL/data2_upgraded start -l logfile

Activez tous les abonnements sur node1 qui récupèrent les modifications provenant de node2 en utilisant ALTER SUBSCRIPTION ... ENABLE, donc :
```
node1=# ALTER SUBSCRIPTION sub1_node2_node1 ENABLE;
```
Sur node2, créez toute table que a été créée sur le serveur mise à jour node1 entre Étape 9 et maintenant, donc :
```
/* node2 # */ CREATE TABLE distributors (did integer PRIMARY KEY, name varchar(40));
```
Rafraichissez les publications des abonnements de node2 pour copier les données des tables du serveur node1 en utilisant ALTER SUBSCRIPTION ... REFRESH PUBLICATION, donc :
```
/* node2 # */ ALTER SUBSCRIPTION sub1_node1_node2 REFRESH PUBLICATION;
```