Convertir un nœud autonome en cluster Patroni

Procédure de conversion des données PostgreSQL existantes en cluster Patroni.

Tâche

Cette section décrit le processus de conversion d’une instance PostgreSQL autonome en cluster Patroni.

Pour déployer un cluster Patroni sans utiliser d’instance PostgreSQL préexistante, consultez plutôt Exécution et configuration .

Procédure

Vous trouverez ci-dessous un aperçu des étapes permettant de convertir un cluster Postgres existant en cluster géré par Patroni. Dans ces étapes, nous supposons que tous les nœuds faisant partie du cluster existant sont actuellement en fonctionnement, et que vous ne prévoyez pas de modifier la configuration de Postgres pendant la migration. Les étapes :

Créez les utilisateurs Postgres comme indiqué dans la section authentification de la configuration Patroni. Vous trouverez des exemples de commandes SQL pour créer les utilisateurs dans le bloc de code ci-dessous, dans lequel vous devez remplacer les noms d’utilisateur et les mots de passe selon votre environnement. Si vous avez déjà les utilisateurs correspondants, vous pouvez ignorer cette étape.

-- Patroni superuser
-- Replace PATRONI_SUPERUSER_USERNAME and PATRONI_SUPERUSER_PASSWORD accordingly
CREATE USER PATRONI_SUPERUSER_USERNAME WITH SUPERUSER ENCRYPTED PASSWORD 'PATRONI_SUPERUSER_PASSWORD';

-- Patroni replication user
-- Replace PATRONI_REPLICATION_USERNAME and PATRONI_REPLICATION_PASSWORD accordingly
CREATE USER PATRONI_REPLICATION_USERNAME WITH REPLICATION ENCRYPTED PASSWORD 'PATRONI_REPLICATION_PASSWORD';

-- Patroni rewind user, if you intend to enable use_pg_rewind in your Patroni configuration
-- Replace PATRONI_REWIND_USERNAME and PATRONI_REWIND_PASSWORD accordingly
CREATE USER PATRONI_REWIND_USERNAME WITH ENCRYPTED PASSWORD 'PATRONI_REWIND_PASSWORD';
GRANT EXECUTE ON function pg_catalog.pg_ls_dir(text, boolean, boolean) TO PATRONI_REWIND_USERNAME;
GRANT EXECUTE ON function pg_catalog.pg_stat_file(text, boolean) TO PATRONI_REWIND_USERNAME;
GRANT EXECUTE ON function pg_catalog.pg_read_binary_file(text) TO PATRONI_REWIND_USERNAME;
GRANT EXECUTE ON function pg_catalog.pg_read_binary_file(text, bigint, bigint, boolean) TO PATRONI_REWIND_USERNAME;

Effectuez les étapes suivantes sur tous les nœuds Postgres. Effectuez toutes les étapes sur un nœud avant de passer au nœud suivant. Commencez par le nœud primaire, puis passez à chaque nœud de secours :
1. Si vous exécutez Postgres via systemd, désactivez l’unité systemd de Postgres. Patroni gère le démarrage et l’arrêt du démon Postgres, il est donc nécessaire de désactiver cette unité.
2. Créez un fichier de configuration YAML pour Patroni. Vous pouvez utiliser l’outil de génération et de validation de la configuration Patroni à cette fin.
  - Note (spécifique au nœud primaire) : Si vous utilisez des fentes de réplication pour la réplication entre les membres du cluster, il est recommandé d’activer use_slots et de configurer les fentes de réplication existantes comme permanentes via l’élément de configuration slots. Prenez garde au fait que Patroni crée automatiquement des fentes de réplication pour la réplication entre les membres, et supprime les fentes qu’il ne reconnaît pas, lorsque use_slots est activé. L’idée d’utiliser des fentes permanentes consiste à permettre à vos fentes existantes de persister pendant la migration vers Patroni. Consultez Paramètres de configuration dynamique pour plus de détails.
3. Démarrez Patroni à l’aide de l’unité de service systemd patroni. Elle détecte automatiquement que Postgres est déjà en cours d’exécution et commence à surveiller l’instance.
Transférez la procédure de démarrage de Postgres à Patroni. Pour cela, vous devez redémarrer les membres du cluster à l’aide de la commande patronictl restart cluster-name member-name . Pour une interruption minimale, vous pouvez souhaiter diviser cette étape en :
1. Redémarrage immédiat des nœuds de secours.
2. Redémarrage planifié du nœud primaire au sein d’une fenêtre de maintenance.
Si vous avez configuré des slots permanents à l’étape 1.2., vous devez les supprimer de la configuration slots à l’aide de la commande patronictl edit-config cluster-name une fois que le restart_lsn des slots créés par Patroni est en mesure de rattraper le restart_lsn des slots originaux pour les membres correspondants. En supprimant les slots de la configuration slots, vous permettez à Patroni de supprimer les slots originaux de votre cluster une fois qu’ils ne sont plus nécessaires. Vous trouverez ci-dessous une requête d’exemple pour vérifier le restart_lsn de quelques slots, afin de les comparer :
```
-- Assume original_slot_for_member_x is the name of the slot in your original
-- cluster for replicating changes to member X, and slot_for_member_x is the
-- slot created by Patroni for that purpose. You need restart_lsn of
-- slot_for_member_x to be >= restart_lsn of original_slot_for_member_x
SELECT slot_name,
       restart_lsn
FROM pg_replication_slots
WHERE slot_name IN (
    'original_slot_for_member_x',
    'slot_for_member_x'
)
```

Mise à jour majeure de la version PostgreSQL

La seule méthode possible pour effectuer une mise à niveau majeure actuellement est :

Arrêtez Patroni
Mettez à jour les binaires PostgreSQL et exécutez pg_upgrade sur le nœud primaire
Mettez à jour patroni.yml
Supprimez la clé d’initialisation du DCS ou effacez l’état complet du cluster depuis le DCS. La deuxième option peut être réalisée en exécutant patronictl remove cluster-name . Cela est nécessaire car pg_upgrade exécute initdb, qui crée effectivement une nouvelle base de données avec un nouvel identifiant système PostgreSQL.
Si vous avez effacé l’état du cluster à l’étape précédente, vous pouvez souhaiter copier patroni.dynamic.json depuis le répertoire de données ancien vers le nouveau. Cela vous aidera à conserver certains paramètres PostgreSQL que vous aviez définis auparavant.
Démarrez Patroni sur le nœud primaire.
Mettez à jour les binaires PostgreSQL, mettez à jour patroni.yml et effacez le répertoire de données sur les nœuds secondaires.
Démarrez Patroni sur les nœuds secondaires et attendez la fin de la réplication.

L’exécution de pg_upgrade sur des nœuds en veille n’est pas prise en charge par PostgreSQL. Si vous savez ce que vous faites, vous pouvez essayer la procédure rsync décrite dans https://www.postgresql.org/docs/current/pgupgrade.html au lieu de supprimer le répertoire data_dir sur les nœuds en veille. La méthode la plus sûre reste toutefois de laisser Patroni effectuer la réplication des données pour vous.

FAQ

Lors du démarrage de Patroni, Patroni signale qu’il ne peut pas se lier au port PostgreSQL.

Vous devez vérifier listen_addresses et port dans postgresql.conf et postgresql.listen dans patroni.yml. N’oubliez pas que pg_hba.conf doit autoriser un tel accès.

Après avoir demandé à Patroni de redémarrer le nœud, PostgreSQL affiche le message d’erreur could not open configuration file "/etc/postgresql/10/main/pg_hba.conf": No such file or directory

Cela peut signifier différentes choses selon la manière dont vous gérez la configuration de PostgreSQL. Si vous avez spécifié postgresql.config_dir, Patroni génère le pg_hba.conf à partir des paramètres de la section amorçage uniquement lorsqu’il amorce un nouveau cluster. Dans ce scénario, le PGDATA n’était pas vide, par conséquent, aucun amorçage n’a eu lieu. Ce fichier doit exister au préalable.