Aller au contenu

Mise à l'échelle et clustering Mis à jour le 2026-05-27

Auto-clustering PostgreSQL

Construire une grappe PostgreSQL primaire-secondaire sur Stack Harbor PaaS — répartition Pgpool-II, réplication WAL, bascule automatique et manuelle.

Pour PostgreSQL, Stack Harbor PaaS construit une grappe primaire-secondaire avec réplication asynchrone basée sur les WAL. Les nœuds ajoutés ensuite par redimensionnement horizontal rejoignent automatiquement la grappe en tant que secondaires. Ajouter une couche Pgpool-II devant la grappe active la bascule automatique.

Deux manières de créer la grappe

Depuis la Marketplace

La voie la plus rapide. Ouvrez Marketplace en haut à gauche du tableau de bord et cherchez PostgreSQL Primary-Secondary Cluster. Cliquez sur Install, choisissez la version PostgreSQL, activez éventuellement les répartiteurs Pgpool-II et appliquez. Quelques minutes plus tard, vous recevez une notification avec les identifiants admin (également envoyés par courriel).

Depuis l’assistant de topologie

Davantage de contrôle sur le reste de l’environnement. Ouvrez l’assistant, choisissez PostgreSQL, activez Auto-Clustering, activez éventuellement Pgpool-II. Ajustez le nombre de nœuds, les cloudlets, ajoutez d’autres piles, définissez les régions et les IP publiques selon le besoin. Appliquez.

Fonctionnement de la réplication PostgreSQL ici

La réplication utilise le Write-Ahead Logging (WAL) en mode asynchrone. Le primaire écrit les segments WAL sur son stockage et le secondaire les lit en mode recovery. Le secondaire applique les segments dès leur arrivée — rapide, mais non synchrone.

Trois réglages dans le postgresql.conf du primaire contrôlent cela :

wal_level = hot_standby
max_wal_senders = 10
archive_mode = on
archive_command = 'cd .'

  • wal_level contrôle la quantité d’information écrite dans le WAL. Valeurs : minimal (récupération seulement), replica (par défaut — assez pour l’archivage WAL et la réplication, supporte les requêtes en lecture sur les secondaires), logical (ajoute l’info nécessaire au décodage logique). Les anciennes versions utilisaient archive et hot_standby ; les deux sont aujourd’hui remappés sur replica.

  • max_wal_senders est le nombre maximal de processus de transfert WAL simultanés.

  • archive_mode active l’archivage WAL en complément de wal_level. Toute valeur sauf minimal permet l’archivage.

  • archive_command est la commande shell exécutée pour chaque segment WAL complété. La valeur par défaut 'cd .' ne fait rien — l’archivage est en pratique désactivé. Réglez-la pour copier les segments WAL vers un stockage durable, par exemple :

    archive_command = 'test ! -f /var/lib/pgsql/data/pg_wal/%f && cp %p /tmp/mydata/%f'

La connexion du secondaire est autorisée depuis le pg_hba.conf du primaire :

host replication all {standby_IP_address}/32 trust

Sur le secondaire, trois éléments signalent le rôle de standby :

  1. hot_standby = on dans postgresql.conf.
  2. Le paramètre primary_conninfo au bas de postgresql.conf — hôte (ou adresse) et port du serveur source, plus l’utilisateur ; le mot de passe va dans primary_conninfo ou dans ~/.pgpass.
  3. Un fichier standby.signal dans le répertoire de données PostgreSQL. La présence de ce fichier dit à PostgreSQL de démarrer en hot standby. Lorsqu’un secondaire est promu, ce fichier est supprimé.

Après modification des options liées à la réplication, redémarrez PostgreSQL. Depuis le tableau de bord, redémarrez un ou les deux nœuds ; depuis le terminal Web SSH : sudo service postgresql restart.

Point d’entrée de la grappe

  • Sans Pgpool-II — connectez-vous directement au nœud primaire.
  • Avec Pgpool-II — connectez-vous à n’importe quel nœud Pgpool-II. Pgpool-II route les écritures vers le primaire courant et équilibre les lectures.

Panneaux d’administration

  • phpPgAdmin est intégré à chaque nœud de base. Utilisez celui du primaire pour les écritures en direct ; les panneaux des secondaires sont en lecture seule.
  • pgAdmin4 est disponible comme nœud séparé via un manifeste Marketplace si vous voulez un outillage plus riche.
  • pgpoolAdmin est intégré à chaque nœud Pgpool-II. Il expose les règles de répartition, les pools de connexions, la journalisation, la réplication, le débogage et les réglages de bascule / restauration.

Vérifier que la réplication fonctionne

Dans phpPgAdmin sur le primaire, créez une base. Ouvrez ensuite le panneau d’un secondaire et confirmez que la nouvelle base y apparaît. Si oui, la réplication fonctionne.

Bascule

Bascule automatique (avec Pgpool-II)

Quand Pgpool-II est en amont de la grappe, il surveille le primaire, détecte une panne et promeut l’un des secondaires disponibles. Quand l’ancien primaire revient, Pgpool-II le réintègre comme secondaire en utilisant pg_rewind pour réconcilier la divergence éventuelle.

Bascule manuelle (sans Pgpool-II)

PostgreSQL ne fait pas de bascule automatique de lui-même. Pour promouvoir un secondaire à la main, ouvrez Web SSH sur le secondaire et lancez :

/usr/pgsql-12/bin/pg_ctl promote -D /var/lib/pgsql/data

Puis pointez votre application sur l’adresse du nouveau primaire.

Vous pouvez automatiser cela avec un cron simple sur le secondaire qui sonde le primaire avec pg_isready et promeut le secondaire quand le primaire cesse de répondre. Un script minimal :

#!/bin/bash
primary="172.25.2.22"
secondary="172.25.2.31"
status=$(/usr/pgsql-12/bin/pg_isready -d postgres -h $primary)
response="$primary:5432 - no response"
if [ "$status" == "$response" ]; then
    /usr/pgsql-12/bin/pg_ctl promote -D /var/lib/pgsql/data
    echo "Secondaire promu. Pointer l'application sur $secondary"
else
    echo "Primaire vivant. Rien à faire."
fi

Restauration de la grappe après une promotion

Si vous voulez revenir à la topologie d’origine après une bascule — ancien primaire à nouveau primaire, secondaire promu redevenu secondaire — c’est possible. Deux raisons d’y tenir : éviter un changement de chaîne de connexion côté application et préserver la capacité à scaler horizontalement (seule la grappe dans sa forme d’origine se redimensionne proprement).

Grandes lignes :

  1. Sur l’ancien primaire, videz le répertoire de données : rm -rf /var/lib/pgsql/data/*.
  2. Ajoutez l’IP de l’ancien primaire au pg_hba.conf du primaire courant, par ex. host replication all 172.25.2.22/32 trust, puis rechargez.
  3. Depuis l’ancien primaire, prenez une base de sauvegarde du primaire courant avec pg_basebackup et les options de recovery / standby.
  4. Démarrez PostgreSQL sur l’ancien primaire ; il tourne maintenant comme secondaire du primaire courant.
  5. Promouvez l’ancien primaire quand vous êtes prêt, rétrogradez le primaire courant par la même procédure en sens inverse.

C’est un travail délicat ; traitez-le comme un changement planifié, pas comme un raccourci de récupération.

Pages connexes

  • Qu’est-ce que l’auto-clustering et auto-clustering via l’assistant de topologie — modèle de plus haut niveau.
  • Auto-clustering de bases de données — équivalent pour MariaDB / MySQL / Percona.
  • Auto-clustering MongoDB — pour les charges NoSQL.