Patroni : installation
Sur les machines créées précédemment :
installer PostgreSQL sur les 2 nœuds depuis les
dépôts PGDG
Si cette étape a déjà été réalisée, arrêter le service PostgreSQL et
supprimer le cluster.
# systemctl stop postgresql@16-main Activation du dépôt PGDG, à exécuter sur nœuds p1 et
p2 :
# apt update
[…]
# apt install postgresql-common
[…]
# /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh -y
This script will enable the PostgreSQL APT repository on apt.postgresql.org on
your system. The distribution codename used will be bookworm-pgdg.
Using keyring /usr/share/postgresql-common/pgdg/apt.postgresql.org.gpg
Writing /etc/apt/sources.list.d/pgdg.sources ...
Running apt-get update […]
Reading package lists... Done
You can now start installing packages from apt.postgresql.org.
Have a look at https://wiki.postgresql.org/wiki/Apt for more information;
most notably the FAQ at https://wiki.postgresql.org/wiki/Apt/FAQDésactiver la création automatique d’une instance durant
l’installation :
mkdir -p /etc/postgresql-common/createcluster.decho create_main_cluster = false > /etc/postgresql-common/createcluster.d/custom.confInstallation de PostgreSQL 16 :
# apt install postgresql-16
[…]
Setting up postgresql-16 (16.2-1.pgdg120+2) ...
installer Patroni sur les 2 nœuds
depuis les dépôts PGDG
Les dépôts PGDG fournissent le paquet patroni :
# apt install patroni
configurer et démarrer le cluster Patroni
acme sur les 2 nœuds
Avec Debian, ne pas utiliser l’intégration de Patroni dans la
structure de gestion multiinstance proposée par
postgresql-common afin de se concentrer sur
l’apprentissage.
La configuration de Patroni se déroule dans le fichier
/etc/patroni/config.yml. Dans le doute, ce fichier est
indiqué par la commande systemctl status patroni.
Sur les nœuds p1 et p2, commencer par
générer un fichier de configuration comme base de travail :
PATH = " $PATH :/usr/lib/postgresql/16/bin" patroni \ --generate-sample-config /etc/patroni/config.ymlDans ce fichier, éditer les variables suivantes :
scope: "acme" : le scope, ou nom, du cluster. Ce nom
est utilisé au sein du DCS comme préfixe de toutes les clés ;name: "<hostname>" : nom de la machine. Cette
valeur doit être différente pour chaque nœud ;log.level: INFO : dans le cadre de ce TP, il est aussi
possible de positionner le niveau de log à DEBUG ;log.dir: '/var/log/patroni/acme' : pour les besoins du
TP, afin de bien séparer les journaux de Patroni et PostgeSQL, nous
demandons à Patroni d’écrire lui-même ses journaux dans ce
répertoire ;restapi : vérifier que l’adresse IP d’écoute est
correcte pour chaque serveur ;bootstrap.dcs.postgresql.use_pg_rewind: false : il est
préférable de désactiver par défaut l’utilisation de
pg_rewind. Cette fonctionnalité ne doit être activée que
sur certains environnements.postgresql.datadir: "/var/lib/postgresql/16/main" :
emplacement du PGDATA ;postgresql.pg_hba: : vérifier la cohérence des règles
pour les clients et la réplication. Éventuellement, facilitez-vous la
vie pour le reste du TP ;postgresql.bindir: "/usr/lib/postgresql/16/bin" :
chemin vers les binaires de PostgreSQL ;postgresql.authentication.replication.password :
positionner le mot de passe à attribuer au rôle
replicator ;postgresql.authentication.superuser.password :
positionner le mot de passe à attribuer au rôle
postgres ;postgresql.listen et
postgresql.connect_address : vérifier que les adresses IP
sont correctes ;
Une fois ce modèle complété, la section dédiée au DCS doit encore
être ajoutée. Collecter les adresses IP des nœuds etcd et ajouter à la
configuration la section etcd3 sur le modèle suivant :
etcd3 : hosts : - 10.0.0.11:2379 - 10.0.0.12:2379 - 10.0.0.13:2379 Cette configuration est minimale. Libre à vous de modifier la façon
dont les instances sont créées (activation des checksums ,
collation par défaut, etc), ajouter des règles, activer
l’authentification etcd, …
Pour ce TP, comme nous plaçons les journaux de Patroni dans des
fichiers, nous recommandons de faire de même pour PostgreSQL en ajoutant
ces paramètres :
postgresql : parameters : logging_collector : on log_destination : stderr
Ce paramétrage a pour seul but de faciliter ce TP. Ce n’est pas une
recommandation pour un serveur en production. Aucune gestion de
rotation, rétention ou externalisation n’est ici en place. Il est tout
aussi possible de se reposer sur journald.
Voici un exemple de configuration obtenue sur le nœud
p1 :
scope : 'acme' name : p1 etcd3 : hosts : - 10.0.0.11:2379 - 10.0.0.12:2379 - 10.0.0.13:2379 log : format : '%(asctime)s %(levelname)s: %(message)s' level : INFO max_queue_size : 1000 traceback_level : ERROR dir : '/var/log/patroni/acme' restapi : connect_address : 10.0.0.21:8008 listen : 10.0.0.21:8008 # The bootstrap configuration. Works only when the cluster is not yet initialized. # If the cluster is already initialized, all changes in the `bootstrap` section are ignored! bootstrap : # This section will be written into <dcs>:/<namespace>/<scope>/config after initializing # new cluster and all other cluster members will use it as a `global configuration`. # WARNING ! If you want to change any of the parameters that were set up # via `bootstrap.dcs` section, please use `patronictl edit-config`! dcs : loop_wait : 10 retry_timeout : 10 ttl : 30 postgresql : parameters : hot_standby : 'on' max_connections : 100 max_locks_per_transaction : 64 max_prepared_transactions : 0 max_replication_slots : 10 max_wal_senders : 10 max_worker_processes : 8 track_commit_timestamp : 'off' wal_keep_size : 128MB wal_level : replica wal_log_hints : 'on' use_pg_rewind : false use_slots : true postgresql : authentication : replication : password : 'pass' username : replicator superuser : password : 'pass' username : postgres bin_dir : '/usr/lib/postgresql/16/bin' connect_address : 10.0.0.21:5432 data_dir : '/var/lib/postgresql/16/main' listen : 10.0.0.21:5432 parameters : password_encryption : scram-sha-256 logging_collector : on log_destination : stderr pg_hba : - local all all trust - host all all all trust - host replication replicator all scram-sha-256 tags : clonefrom : true failover_priority : 1 noloadbalance : false nosync : false Assurez-vous que ce fichier de configuration est bien accessible à
l’utilisateur postgres et créer le répertoire nécessaire
aux journaux applicatifs :
chmod 0644 /etc/patroni/config.ymlinstall -o postgres -g postgres -d /var/log/patroni/acmeNous pouvons désormais valider la configuration :
patroni --validate /etc/patroni/config.ymlLe code retour de la commande est 0 si tout est valide.
Sinon, la commande affiche les avertissements appropriés.
Il est maintenant possible de démarrer le service Patroni. Nous
commençons d’abord sur p1 pour créer l’instance :
# systemctl start patroniPuis nous démarrons le service sur p2, qui va donc créer
le secondaire :
# systemctl start patroni
observer les traces de chaque nœud Patroni
Sur p1, nous trouvons les messages suivants dans le journal
/var/log/patroni/acme/patroni.log :
Le démon Patroni démarre, choisi un serveur etcd, se saisit du
leader lock et initialise l’instance PostgreSQL locale. Les
sorties standard et d’erreur des commandes exécutées par Patroni n’est
pas capturée vers le journal de ce dernier. Ces commandes sont donc
capturées par journald et associées au service patroni.
Nous y retrouvons par exemple la sortie de initdb :
# journalctl -u patroni
[…]
patroni: The files belonging to this database system will be owned by user "postgres".
patroni: This user must also own the server process.
patroni: The database cluster will be initialized with locale "C.UTF-8".
[…]
patroni: Success. You can now start the database server using:
patroni: /usr/lib/postgresql/16/bin/pg_ctl -D /var/lib/postgresql/16/main -l logfile startSur p2, nous trouvons dans le journal
correspondant :
Comme sur p1, le démon Patroni démarre et choisi un
serveur etcd, mais il découvre le leader lock appartient déjà à
p1. L’instance PostgreSQL locale n’existant pas, Patroni
décide de la créer depuis celle de p1.
Dans les deux cas, la configuration par défaut des journaux
applicatifs de PostgreSQL les places dans le répertoire
PGDATA/log, donc ici
/var/lib/postgresql/16/main/log, équivalent à
~postgres/16/main/log.
observer la topologie de l’agrégat avec
patronictl.
L’utilisation de patronictl nécessite un fichier de
configuration permettant de déterminer le nom du cluster et idéalement
les nœuds du DCS. Sur les machines p1 et p2,
nous pouvons utiliser directement le fichier de configuration de Patroni
/etc/patroni/config.yml. La commande devient :
$ patronictl -c /etc/patroni/config.yml topology
+ Cluster: acme (7349612307776631369) -----+----+-----------+-------+
| Member | Host | Role | State | TL | Lag in MB | Tags |
+--------+-----------+---------+-----------+----+-----------+-------+
| p1 | 10.0.0.21 | Leader | running | 1 | | […] |
| + p2 | 10.0.0.22 | Replica | streaming | 1 | 0 | […] |
+--------+-----------+---------+-----------+----+-----------+-------+Nous constatons que p1 héberge bien l’instance primaire
et p2 la secondaire.
Pour simplifier cette commande, il est possible de positionner dans
votre environnement le variable PATRONICTL_CONFIG_FILE. Par
exemple :
$ export PATRONICTL_CONFIG_FILE=/etc/patroni/config.yml
$ patronictl topology
[…]Pour la positionner automatiquement, vous pouvez par exemple créer le
fichier /etc/profile.d/99-patroni.sh avec le contenu
suivant :
cat <<EOF > /etc/profile.d/99-patroni.shPATRONICTL_CONFIG_FILE=/etc/patroni/config.yml export PATRONICTL_CONFIG_FILE EOF chmod +x /etc/profile.d/99-patroni.sh
Ajouter le 3ème nœud à l’agrégat.
Répéter les étapes précédentes sur le serveur p3 :
installation des dépôts PGDG ;
installation de PostgreSQL et Patroni ;
création du fichier de configuration de Patroni ;
démarrage de l’instance sur p3.
Après l’ajout du troisième nœud, la topologie est la suivante :
$ patronictl topology
+ Cluster: acme (7349612307776631369) -----+----+-----------+------+
| Member | Host | Role | State | TL | Lag in MB | Tags |
+--------+-----------+---------+-----------+----+-----------+------+
| p1 | 10.0.0.21 | Leader | running | 1 | | […] |
| + p2 | 10.0.0.22 | Replica | streaming | 1 | 0 | […] |
| + p3 | 10.0.0.23 | Replica | streaming | 1 | 0 | […] |
+--------+-----------+---------+-----------+----+-----------+------+Il est conseillé lors des tests de garder une fenêtre répétant
l’ordre régulièrement :
$ watch -n1 patronictl topology
Déterminer le primaire via l’API Patroni en direct
avec curl.
La configuration est visible de l’extérieur :
$ curl -s http://p1:8008/patroni | jq{ "state" : "running" , "postmaster_start_time" : "[…]" , "role" : "master" , "server_version" : 160002 , "xlog" : { "location" : 50534136 }, "timeline" : 1 , "replication" : [ { "usename" : "replicator" , "application_name" : "p2" , "client_addr" : "10.0.0.22" , "state" : "streaming" , "sync_state" : "async" , "sync_priority" : 0 } , { "usename" : "replicator" , "application_name" : "p3" , "client_addr" : "10.0.0.23" , "state" : "streaming" , "sync_state" : "async" , "sync_priority" : 0 } ] , "dcs_last_seen" : 1711217105 , "tags" : { "clonefrom" : true , "failover_priority" : 1 }, "database_system_identifier" : "7349612307776631369" , "patroni" : { "version" : "3.2.2" , "scope" : "acme" , "name" : "p1" } } De manière plus précise :
$ curl -s http://p1:8008/cluster |\
jq '.members[] | select ((.role == "leader" ) and ( .state == "running")) | { name }'
Quels sont les slots de réplication sur le
leader ?
Par défaut, les slots de réplications portent le nom des nœuds
réplicas.
$ curl -s http://p1:8008/cluster | jq '.members[] | select (.role == "replica") | { name }'{ "name" : "p2" } { "name" : "p3" } On peut le vérifier en se connectant à PostgreSQL sur le serveur
primaire (ici p1) :
$ sudo -iu postgres
$ psql -c "SELECT slot_name FROM pg_replication_slots"
slot_name
-----------
p2
p3
Forcer l’utilisation du watchdog dans la
configuration de Patroni. Que se passe-t-il ?
Ajoutez la section watchdog dans le fichier de configuration de
Patroni /etc/patroni/config.yml en positionnant
mode: required :
watchdog : mode : required # device: /dev/watchdog safety_margin : 5 Il nous faut recharger la configuration de Patroni :
$ patronictl reload acme
+ Cluster: acme (7349612307776631369) --------+----+-----------+
| Member | Host | Role | State | TL | Lag in MB |
+--------+-----------+---------+--------------+----+-----------+
| p1 | 10.0.0.21 | Replica | start failed | | unknown |
| p2 | 10.0.0.22 | Replica | start failed | | unknown |
| p3 | 10.0.0.23 | Leader | running | 6 | |
+--------+-----------+---------+--------------+----+-----------+
Are you sure you want to reload members p1, p2, p3? [y/N]: y
Reload request received for member p1 and will be processed within 10 seconds
Reload request received for member p2 and will be processed within 10 seconds
Reload request received for member p3 and will be processed within 10 secondsSuite à cette modification, le cluster Patroni se retrouve sans
primaire. Dans les journaux applicatif de p3, ici
précédemment marqué Leader , nous trouvons :
Donner les droits à l’utilisateur
postgres sur le fichier /dev/watchdog. Après
quelques secondes, que se passe-t-il ?
Un simple chown sur le device /dev/watchdog
de chaque VM peut suffire, au moins le temps de ce TP. Néanmoins, il ne
survivrait pas au e de la machine.
Le fichier de service de Patroni propose de systématiquement modifier
les droits sur ce device décommentant la ligne suivante :
Une autre solution est de configurer udev afin qu’il
modifie les droits sur ce fichier automatiquement à chaque
démarrage :
cat <<'EOF' > /etc/udev/rules.d/99-watchdog.rules# give writes on watchdog device to postgres SUBSYSTEM=="misc", KERNEL=="watchdog", ACTION=="add", RUN+="/bin/chown postgres /dev/watchdog" # Or a better solution using ACL: #SUBSYSTEM=="misc", KERNEL=="watchdog", ACTION=="add", RUN+="/bin/setfacl -m u:postgres:rw- /dev/watchdog" EOF Une fois les droits positionnés, l’un des nœuds Patroni devrait
finalement réussir à activer le watchdog et ainsi devenir
leader et promouvoir son instance PostgreSQL :
Patroni : utilisation
Se connecter depuis l’extérieur à la base
postgres , d’un des nœuds.
La connexion extérieure peut se faire depuis la machine hôte des VM.
Il est nécessaire d’y installer un client PostgreSQL, par exemple
postgresql-client. Pour se connecter à l’instance
p1, utiliser l’une des commandes suivantes :
$ psql -h p1 -p 5432 -U postgres -d postgres
$ psql -h 10.0.0.21 postgres postgresEn cas de problème, il faut regarder :
les règles de firewall ;
les traces du nœud PostgreSQL concerné, plus instructives que le
simple message d’erreur du client ;
le fichier de configuration pg_hba.conf.
Comment obtenir une connexion en lecture et
écrire ?
Il est nécessaire de se connecter à l’instance primaire pour réaliser
des écritures en base. La chaîne de connexion permettant d’indiquer
plusieurs nœuds, nous pouvons y préciser tous les nœuds du cluster. Afin
de sélectionner le nœud primaire, il suffit d’ajouter le paramètre
target_session_attrs=primary ou
target_session_attrs=read-write.
Par exemple :
psql "host=p1,p2,p3 user=postgres target_session_attrs=primary" psql "postgresql://postgres@p1,p2,p3/postgres?target_session_attrs=read-write" Pour une connexion en lecture seule, nous utilisons par exemple :
psql "postgresql://postgres@p1,p2,p3:5432/postgres?target_session_attrs=prefer-standby"
Créer une table :
CREATE TABLE insertions (id int GENERATED ALWAYS AS IDENTITY,DEFAULT now(),source text DEFAULT inet_server_addr()Insérer une ligne toutes les secondes, à chaque
fois dans une nouvelle connexion au primaire.
Dans une autre fenêtre, afficher les 20
dernières lignes de cette table.
Dans la colonne source de la table créée, la valeur par
défaut fait appel à la fonction inet_server_addr() qui
retourne l’adresse IP du serveur PostgreSQL sur lequel nous sommes
connectés.
Lancer une insertion toutes les secondes :
watch -n1 'psql -X -d "host=p1,p2,p3 user=postgres target_session_attrs=primary" \ -c "INSERT INTO insertions SELECT;"' Lire les vingt dernières lignes de la table :
watch -n1 'psql -X -d "host=p1,p2,p3 port=5432 user=postgres" \ -c "SELECT * FROM insertions ORDER BY d DESC LIMIT 20"' Bien entendu, nous obtenons toujours le même nœud dans la colonne
source, ici p1 :
Stopper le nœud leader Patroni.
Que se passe-t-il dans la topologie, et dans les
requêtes ci-dessus ?
Sur p1 :
# systemctl stop patroniAprès l’arrêt de p1, p3 prend le rôle de
leader :
$ patronictl -c /etc/patroni/config.yml topology
+ Cluster: acme (7349612307776631369) ---+----+-----------+------+
| Member | Host | Role | State | TL | Lag in MB | Tags |
+--------+-----------+---------+---------+----+-----------+------+
| p3 | 10.0.0.23 | Leader | running | 2 | | […] |
| + p1 | 10.0.0.21 | Replica | stopped | | unknown | […] |
| + p2 | 10.0.0.22 | Replica | running | 1 | 0 | […] |
+--------+-----------+---------+---------+----+-----------+------+Les insertions échouent le temps de la bascule, ici pendant environ 2
secondes, puis continuent depuis l’autre nœud :
Arrêter les processus du nouveau primaire. Il ne
reste qu’un nœud actif. Que se passe-t-il ?
Le leader Patroni a changé à nouveau :
$ patronictl -c /etc/patroni/config.yml topology
+ Cluster: acme (7349612307776631369) --+----+-----------+------+
| Member | Host | Role | State | TL | Lag in MB | Tags |
+--------+-----------+--------+---------+----+-----------+------+
| p2 | 10.0.0.22 | Leader | running | 6 | | […] |
+--------+-----------+--------+---------+----+-----------+------+
Arrêter deux nœuds du cluster etcd. Que se
passe-t-il ?
Sur e1 et e2 :
Il n’y a plus de quorum etcd garantissant une référence. Le cluster
Patroni se met en lecture seule et les insertions tombent en échec
puisqu’elles exigent une connexion ouverte en écriture :
Redémarrer les nœuds etcd.
Les écritures reprennent.
Relancer un des nœuds Patroni.
Dans le cadre de cette correction p2 est l’actuel
leader , nous redémarrons donc Patroni sur p1 :
# systemctl restart patroni L’instance sur p1 se raccroche en secondaire :
$ patronictl -c /etc/patroni/config.yml topology
+ Cluster: acme (7349612307776631369) -----+----+-----------+------+
| Member | Host | Role | State | TL | Lag in MB | Tags |
+--------+-----------+---------+-----------+----+-----------+------+
| p2 | 10.0.0.22 | Leader | running | 7 | | […] |
| + p1 | 10.0.0.21 | Replica | streaming | 7 | 0 | […] |
+--------+-----------+---------+-----------+----+-----------+------+
Sur le troisième nœud (arrêté), détruire le
PGDATA. Relancer Patroni.
Le PGDATA de nos instances se trouve dans
/var/lib/postgresql/16/main. Supprimons ce
PGDATA sur p3, le nœud restant :
rm -rf /var/lib/postgresql/16/mainRelançons Patroni sur ce nœud :
# systemctl start patroni Nous observons dans les journaux de Patroni et PostgreSQL que
l’instance est recrée et se raccroche à p2 :
Le temps de la reconstruction de zéro, il est possible de voir
l’évolution de l’état de p3 de
creating replica à streaming :
$ export PATRONICTL_CONFIG_FILE=/etc/patroni/config.yml
$ patronictl topology
+ Cluster: acme (7349612307776631369) ------------+----+-----------+------+
| Member | Host | Role | State | TL | Lag in MB | Tags |
+--------+-----------+---------+------------------+----+-----------+------+
| p2 | 10.0.0.22 | Leader | running | 7 | | […] |
| + p1 | 10.0.0.21 | Replica | streaming | 7 | 0 | […] |
| + p3 | 10.0.0.23 | Replica | creating replica | | unknown | […] |
+--------+-----------+---------+------------------+----+-----------+------+
/* Après un certain temps */
$ patronictl topology
+ Cluster: acme (7349612307776631369) -----+----+-----------+------+
| Member | Host | Role | State | TL | Lag in MB | Tags |
+--------+-----------+---------+-----------+----+-----------+------+
| p2 | 10.0.0.22 | Leader | running | 7 | | […] |
| + p1 | 10.0.0.21 | Replica | streaming | 7 | 0 | […] |
| + p3 | 10.0.0.23 | Replica | streaming | 7 | 0 | […] |
+--------+-----------+---------+-----------+----+-----------+------+
Forcer un failover vers le nœud
p1.
$ patronictl failover
Current cluster topology
+ Cluster: acme (7349612307776631369) -----+----+-----------+------+
| Member | Host | Role | State | TL | Lag in MB | Tags |
+--------+-----------+---------+-----------+----+-----------+------+
| p1 | 10.0.0.21 | Replica | streaming | 7 | 0 | […] |
+--------+-----------+---------+-----------+----+-----------+------+
| p2 | 10.0.0.22 | Leader | running | 7 | | […] |
+--------+-----------+---------+-----------+----+-----------+------+
| p3 | 10.0.0.23 | Replica | streaming | 7 | 0 | […] |
+--------+-----------+---------+-----------+----+-----------+------+
Candidate ['p1', 'p3'] []: p1
Are you sure you want to failover cluster acme, demoting current leader p2? [y/N]: y
[…] Successfully failed over to "p1"
+ Cluster: acme (7349612307776631369) ---+----+-----------+------+
| Member | Host | Role | State | TL | Lag in MB | Tags |
+--------+-----------+---------+---------+----+-----------+------+
| p1 | 10.0.0.21 | Leader | running | 7 | | […] |
+--------+-----------+---------+---------+----+-----------+------+
| p2 | 10.0.0.22 | Replica | stopped | | unknown | […] |
+--------+-----------+---------+---------+----+-----------+------+
| p3 | 10.0.0.23 | Replica | running | 7 | 0 | […] |
+--------+-----------+---------+---------+----+-----------+------+
$ patronictl topology
+ Cluster: acme (7349612307776631369) -----+----+-----------+------+
| Member | Host | Role | State | TL | Lag in MB | Tags |
+--------+-----------+---------+-----------+----+-----------+------+
| p1 | 10.0.0.21 | Leader | running | 8 | | […] |
| + p2 | 10.0.0.22 | Replica | streaming | 8 | 0 | […] |
| + p3 | 10.0.0.23 | Replica | streaming | 8 | 0 | […] |
+--------+-----------+---------+-----------+----+-----------+------+
Modifier les paramètres shared_buffers
et work_mem. Si besoin, redémarrer les nœuds.
Pour modifier la configuration, nous devons utiliser
patronictl, plutôt qu’éditer directement les fichiers de
configuration. Une alternative est de modifier la configuration
statique, dans le fichier YAML “/etc/patroni/config.yml”. Cette méthode
facilite leur maintenance, mais impose que le contenu soit identique sur
tous les nœuds, ce qui est généralement le cas dans un déploiement
industrialisé.
La commande patronictl edit-config appelle l’éditeur par
défaut, souvent vi, vim ou nano.
Vous pouvez modifier la variable d’environnement EDITOR
pour pointer sur votre éditeur favori.
Éditons la configuration dynamique et ajoutons les deux
paramètres :
$ export PATRONICTL_CONFIG_FILE=/etc/patroni/config.yml$ patronictl edit-config[…] --- +++ @@ -12,6 +12,8 @@ + shared_buffers: 300MB + work_mem: 50MB Les nœuds sont à redémarrer à cause de la modification de
shared_buffers :
$ patronictl topology
+ Cluster: acme (7349612307776631369) -----+----+------+-----------------+------+
| Member | Host | Role | State | TL | Lag… | Pending restart | Tags |
+--------+-----------+---------+-----------+----+------+-----------------+------+
| p1 | 10.0.0.21 | Leader | running | 8 | | * | […] |
| + p2 | 10.0.0.22 | Replica | streaming | 8 | 0 | * | […] |
| + p3 | 10.0.0.23 | Replica | streaming | 8 | 0 | * | […] |
+--------+-----------+---------+-----------+----+------+-----------------+------+Commandons le redémarrage de PostgreSQL sur les trois nœuds :
$ patronictl restart acme
+ Cluster: acme (7349612307776631369) -----+----+------+-----------------+------+
| Member | Host | Role | State | TL | Lag… | Pending restart | Tags |
+--------+-----------+---------+-----------+----+------+-----------------+------+
| p1 | 10.0.0.21 | Leader | running | 8 | | * | […] |
+--------+-----------+---------+-----------+----+------+-----------------+------+
| p2 | 10.0.0.22 | Replica | streaming | 8 | 0 | * | […] |
+--------+-----------+---------+-----------+----+------+-----------------+------+
| p3 | 10.0.0.23 | Replica | streaming | 8 | 0 | * | […] |
+--------+-----------+---------+-----------+----+------+-----------------+------+
When should the restart take place (e.g. […]) [now]:
Are you sure you want to restart members p1, p2, p3? [y/N]: y
Restart if the PostgreSQL version is less than provided (e.g. 9.5.2) []:
Success: restart on member p1
Success: restart on member p2
Success: restart on member p3Vérifions que le paramétrage a bien été modifié :
$ for h in p1 p2 p3; do echo -ne $h:; psql -Xtd "host=$h user=postgres" -c "show shared_buffers"; done
p1: 300MB
p2: 300MB
p3: 300MBNoter que le contenu des modifications est tracé dans un fichier
patroni.dynamic.json dans le PGDATA :
$ jq . patroni.dynamic.jsonTravaux pratiques Rocky 9
(solutions)
Patroni : installation
Sur les machines créées précédemment :
installer PostgreSQL sur les 2 nœuds depuis les
dépôts PGDG
Si cette opération a déjà été réalisée précédemment, stopper le
service PostgreSQL, le désactiver et supprimer le répertoire de données
de l’instance.
# systemctl stop postgresql-16 # systemctl disable postgresql-16 # rm -Rf /var/lib/pgsql/16/data Activation du dépôt PGDG, à exécuter sur nœuds p1 et
p2 :
# dnf install https://download.postgresql.org/pub/repos/yum/reporpms/EL-9-x86_64/\
pgdg-redhat-repo-latest.noarch.rpm
# dnf install -y postgresql16-server
[…]
Installed:
postgresql16-16.2-1PGDG.rhel9.x86_64
postgresql16-libs-16.2-1PGDG.rhel9.x86_64
postgresql16-server-16.2-1PGDG.rhel9.x86_64
Complete!
installer Patroni sur les 2 nœuds
depuis les dépôts PGDG
Les dépôts PGDG fournissent le paquet patroni :
dnf install -y epel-releasednf install -y patroni-etcd
configurer et démarrer le cluster Patroni
acme sur les 2 nœuds
La configuration de Patroni se déroule dans le fichier
/etc/patroni/patroni.yml.
Sur les nœuds p1 et p2, commencer par
générer un fichier de configuration comme base de travail :
PATH = " $PATH :/usr/pgsql-16/bin" patroni \ --generate-sample-config /etc/patroni/patroni.ymlDans ce fichier, éditer les variables suivantes :
scope: "acme" : le scope, ou nom, du cluster. Ce nom
est utilisé au sein du DCS comme préfixe de toutes les clés ;name: "<hostname>" : nom de la machine. Cette
valeur doit être différente pour chaque nœud ;log.level: INFO : dans le cadre de ce TP, il est aussi
possible de positionner le niveau de log à DEBUG ;log.dir: '/var/log/patroni/acme' : pour les besoins du
TP, afin de bien séparer les journaux de Patroni et PostgeSQL, nous
demandons à Patroni d’écrire lui-même ses journaux dans ce
répertoire ;restapi : vérifier que l’adresse IP d’écoute est
correcte pour chaque serveur ;bootstrap.dcs.postgresql.use_pg_rewind: false : il est
préférable de désactiver par défaut l’utilisation de
pg_rewind. Cette fonctionnalité ne doit être activée que
sur certains environnements.postgresql.datadir: "/var/lib/pgsql/16/data" :
emplacement du PGDATA ;postgresql.pg_hba: : vérifier la cohérence des règles
pour les clients et la réplication. Éventuellement, facilitez-vous la
vie pour le reste du TP ;postgresql.bindir: "/usr/pgsql-16/bin" : chemin vers
les binaires de PostgreSQL ;postgresql.authentication.replication.password :
positionner le mot de passe à attribuer au rôle
replicator ;postgresql.authentication.superuser.password :
positionner le mot de passe à attribuer au rôle
postgres ;postgresql.listen et
postgresql.connect_address : vérifier que les adresses IP
sont correctes ;
Une fois ce modèle complété, la section dédiée au DCS doit encore
être ajoutée. Collecter les adresses IP des nœuds etcd et ajouter à la
configuration la section etcd3 sur le modèle suivant :
etcd3 : hosts : - 10.0.0.11:2379 - 10.0.0.12:2379 - 10.0.0.13:2379 Cette configuration est minimale. Libre à vous de modifier la façon
dont les instances sont créées (activation des checksums ,
collation par défaut, etc), ajouter des règles, activer
l’authentification etcd, …
Pour ce TP, comme nous plaçons les journaux de Patroni dans des
fichiers, nous recommandons de faire de même pour PostgreSQL en ajoutant
ces paramètres :
postgresql : parameters : logging_collector : on log_destination : stderr
Ce paramétrage a pour seul but de faciliter ce TP. Ce n’est pas une
recommandation pour un serveur en production. Aucune gestion de
rotation, rétention ou externalisation n’est ici en place. Il est tout
aussi possible de se reposer sur journald.
Voici un exemple de configuration obtenue sur le nœud
p1 :
scope : 'acme' name : p1.hapat.vm etcd3 : hosts : - 10.0.0.11:2379 - 10.0.0.12:2379 - 10.0.0.13:2379 log : format : '%(asctime)s %(levelname)s: %(message)s' level : INFO max_queue_size : 1000 traceback_level : ERROR dir : '/var/log/patroni/acme' restapi : connect_address : 10.0.0.21:8008 listen : 10.0.0.21:8008 # The bootstrap configuration. Works only when the cluster is not yet initialized. # If the cluster is already initialized, all changes in the `bootstrap` section are ignored! bootstrap : # This section will be written into <dcs>:/<namespace>/<scope>/config after initializing # new cluster and all other cluster members will use it as a `global configuration`. # WARNING ! If you want to change any of the parameters that were set up # via `bootstrap.dcs` section, please use `patronictl edit-config`! dcs : loop_wait : 10 retry_timeout : 10 ttl : 30 postgresql : parameters : hot_standby : 'on' max_connections : 100 max_locks_per_transaction : 64 max_prepared_transactions : 0 max_replication_slots : 10 max_wal_senders : 10 max_worker_processes : 8 track_commit_timestamp : 'off' wal_keep_size : 128MB wal_level : replica wal_log_hints : 'on' use_pg_rewind : false use_slots : true postgresql : authentication : replication : password : 'pass' username : replicator superuser : password : 'pass' username : postgres bin_dir : '/usr/pgsql-16/bin' connect_address : 10.0.0.21:5432 data_dir : '/var/lib/pgsql/16/data' listen : 10.0.0.21:5432 parameters : password_encryption : scram-sha-256 logging_collector : on log_destination : stderr pg_hba : - local all all trust - host all all all trust - host replication replicator all scram-sha-256 tags : clonefrom : true failover_priority : 1 noloadbalance : false nosync : false Assurez-vous que ce fichier de configuration est bien accessible à
l’utilisateur postgres et créer le répertoire nécessaire
aux journaux applicatifs :
chmod 0644 /etc/patroni/patroni.ymlinstall -o postgres -g postgres -d /var/log/patroni/acmeNous pouvons désormais valider la configuration :
patroni --validate /etc/patroni/patroni.ymlLe code retour de la commande est 0 si tout est valide.
Sinon, la commande affiche les avertissements appropriés.
Il est maintenant possible de démarrer le service Patroni. Nous
commençons d’abord sur p1 pour créer l’instance :
# systemctl start patroniPuis nous démarrons le service sur p2, qui va donc créer
le secondaire :
# systemctl start patroni
observer les traces de chaque nœud Patroni
Sur p1, nous trouvons les messages suivants dans le journal
/var/log/patroni/acme/patroni.log :
Le démon Patroni démarre, choisi un serveur etcd, se saisit du
leader lock et initialise l’instance PostgreSQL locale. Les
sorties standard et d’erreur des commandes exécutées par Patroni n’est
pas capturée vers le journal de ce dernier. Ces commandes sont donc
capturées par journald et associées au service patroni.
Nous y retrouvons par exemple la sortie de initdb :
# journalctl -u patroni
[…]
patroni: The files belonging to this database system will be owned by user "postgres".
patroni: This user must also own the server process.
patroni: The database cluster will be initialized with locale "C.UTF-8".
[…]
patroni: Success. You can now start the database server using:
patroni: /usr/pgsql-16/bin/pg_ctl -D /var/lib/pgsql/16/data -l logfile startSur p2, nous trouvons dans le journal
correspondant :
Comme sur p1, le démon Patroni démarre et choisi un
serveur etcd, mais il découvre le leader lock appartient déjà à
p1. L’instance PostgreSQL locale n’existant pas, Patroni
décide de la créer depuis celle de p1.
Dans les deux cas, la configuration par défaut des journaux
applicatifs de PostgreSQL les places dans le répertoire
PGDATA/log, donc ici
/var/lib/pgsql/16/data/log/, équivalent à
~postgres/16/data/log.
observer la topologie de l’agrégat avec
patronictl.
L’utilisation de patronictl nécessite un fichier de
configuration permettant de déterminer le nom du cluster et idéalement
les nœuds du DCS. Sur les machines p1 et p2,
nous pouvons utiliser directement le fichier de configuration de Patroni
/etc/patroni/patroni.yml. La commande devient :
$ patronictl -c /etc/patroni/patroni.yml topology
+ Cluster: acme (7350009258581743592) +-----------+----+-----------+------+
| Member | Host | Role | State | TL | Lag in MB | Tags |
+---------------+-----------+---------+-----------+----+-----------+------+
| p1.hapat.vm | 10.0.0.21 | Leader | running | 1 | | […] |
| + p2.hapat.vm | 10.0.0.22 | Replica | streaming | 1 | 0 | […] |
+---------------+-----------+---------+-----------+----+-----------+------+Nous constatons que p1 héberge bien l’instance primaire
et p2 la secondaire.
Pour simplifier cette commande, il est possible de positionner dans
votre environnement le variable PATRONICTL_CONFIG_FILE. Par
exemple :
$ export PATRONICTL_CONFIG_FILE=/etc/patroni/patroni.yml
$ patronictl topology
[…]Pour la positionner automatiquement, vous pouvez par exemple créer le
fichier /etc/profile.d/99-patroni.sh avec le contenu
suivant :
cat <<EOF > /etc/profile.d/99-patroni.shPATRONICTL_CONFIG_FILE=/etc/patroni/patroni.yml export PATRONICTL_CONFIG_FILE EOF chmod +x /etc/profile.d/99-patroni.sh
Ajouter le 3ème nœud à l’agrégat.
Répéter les étapes précédentes sur le serveur p3 :
installation des dépôts PGDG ;
installation de PostgreSQL et Patroni ;
création du fichier de configuration de Patroni ;
démarrage de l’instance sur p3.
Après l’ajout du troisième nœud, la topologie est la suivante :
$ patronictl topology
+ Cluster: acme (7350009258581743592) +-----------+----+-----------+------+
| Member | Host | Role | State | TL | Lag in MB | Tags |
+---------------+-----------+---------+-----------+----+-----------+------+
| p1.hapat.vm | 10.0.0.21 | Leader | running | 1 | | […] |
| + p2.hapat.vm | 10.0.0.22 | Replica | streaming | 1 | 0 | […] |
| + p3.hapat.vm | 10.0.0.23 | Replica | streaming | 1 | 0 | […] |
+---------------+-----------+---------+-----------+----+-----------+------+Il est conseillé lors des tests de garder une fenêtre répétant
l’ordre régulièrement :
$ watch -n1 patronictl topology
Déterminer le primaire via l’API Patroni en direct
avec curl.
La configuration est visible de l’extérieur :
$ curl -s http://p1:8008/patroni | jq{ "state" : "running" , "postmaster_start_time" : "[…]" , "role" : "master" , "server_version" : 160002 , "xlog" : { "location" : 50651960 }, "timeline" : 1 , "replication" : [ { "usename" : "replicator" , "application_name" : "p2.hapat.vm" , "client_addr" : "10.0.0.22" , "state" : "streaming" , "sync_state" : "async" , "sync_priority" : 0 } , { "usename" : "replicator" , "application_name" : "p3.hapat.vm" , "client_addr" : "10.0.0.23" , "state" : "streaming" , "sync_state" : "async" , "sync_priority" : 0 } ] , "dcs_last_seen" : 1711308128 , "tags" : { "clonefrom" : true , "failover_priority" : 1 }, "database_system_identifier" : "7350009258581743592" , "patroni" : { "version" : "3.2.2" , "scope" : "acme" , "name" : "p1.hapat.vm" } } De manière plus précise :
$ curl -s http://p1:8008/cluster |\
jq '.members[] | select ((.role == "leader" ) and ( .state == "running")) | { name }'{ "name" : "p1.hapat.vm" }
Quels sont les slots de réplication sur le
leader ?
Par défaut, les slots de réplications portent le nom des nœuds
réplicas.
$ curl -s http://p1:8008/cluster | jq '.members[] | select (.role == "replica") | { name }'{ "name" : "p2.hapat.vm" } { "name" : "p3.hapat.vm" } On peut le vérifier en se connectant à PostgreSQL sur le serveur
primaire (ici p1) :
$ sudo -iu postgres
$ psql -c "SELECT slot_name FROM pg_replication_slots"
slot_name
-----------
p2_hapat_vm
p3_hapat_vm
Forcer l’utilisation du watchdog dans la
configuration de Patroni. Que se passe-t-il ?
Ajoutez la section watchdog dans le fichier de configuration de
Patroni /etc/patroni/patroni.yml en positionnant
mode: required :
watchdog : mode : required # device: /dev/watchdog safety_margin : 5 Il nous faut recharger la configuration de Patroni :
$ patronictl reload acme
+ Cluster: acme (7350009258581743592) -------------+----+-----------+
| Member | Host | Role | State | TL | Lag in MB |
+-------------+-----------+---------+--------------+----+-----------+
| p1.hapat.vm | 10.0.0.21 | Replica | start failed | | unknown |
| p2.hapat.vm | 10.0.0.22 | Replica | start failed | | unknown |
| p3.hapat.vm | 10.0.0.23 | Leader | running | 6 | |
+-------------+-----------+---------+--------------+----+-----------+
Are you sure you want to reload members p1.hapat.vm, p2.hapat.vm, p3.hapat.vm? [y/N]: y
Reload request received for member p1.hapat.vm and will be processed within 10 seconds
Reload request received for member p2.hapat.vm and will be processed within 10 seconds
Reload request received for member p3.hapat.vm and will be processed within 10 secondsSuite à cette modification, le cluster Patroni se retrouve sans
primaire. Dans les journaux applicatif de p3, ici
précédemment marqué Leader , nous trouvons :
Donner les droits à l’utilisateur
postgres sur le fichier /dev/watchdog. Après
quelques secondes, que se passe-t-il ?
Un simple chown sur le device /dev/watchdog
de chaque VM peut suffire, au moins le temps de ce TP. Néanmoins, il ne
survivrait pas au redémarrage de la machine.
Le fichier de service de Patroni propose de systématiquement modifier
les droits sur ce device décommentant la ligne suivante :
Une autre solution est de configurer udev afin qu’il
modifie les droits sur ce fichier automatiquement à chaque
démarrage :
cat <<'EOF' > /etc/udev/rules.d/99-watchdog.rules# give writes on watchdog device to postgres SUBSYSTEM=="misc", KERNEL=="watchdog", ACTION=="add", RUN+="/bin/chown postgres /dev/watchdog" # Or a better solution using ACL: #SUBSYSTEM=="misc", KERNEL=="watchdog", ACTION=="add", RUN+="/bin/setfacl -m u:postgres:rw- /dev/watchdog" EOF Une fois les droits positionnés, l’un des nœuds Patroni devrait
finalement réussir à activer le watchdog et ainsi devenir
leader et promouvoir son instance PostgreSQL :
Patroni : utilisation
Se connecter depuis l’extérieur à la base
postgres , d’un des nœuds.
La connexion extérieure peut se faire depuis la machine hôte des VM.
Il est nécessaire d’y installer un client PostgreSQL, par exemple
postgresql-client. Pour se connecter à l’instance
p1, utiliser l’une des commandes suivantes :
$ psql -h p1 -p 5432 -U postgres -d postgres
$ psql -h 10.0.0.21 postgres postgresEn cas de problème, il faut regarder :
les règles de firewall ;
les traces du nœud PostgreSQL concerné, plus instructives que le
simple message d’erreur du client ;
le fichier de configuration pg_hba.conf.
Comment obtenir une connexion en lecture et
écrire ?
Il est nécessaire de se connecter à l’instance primaire pour réaliser
des écritures en base. La chaîne de connexion permettant d’indiquer
plusieurs nœuds, nous pouvons y préciser tous les nœuds du cluster. Afin
de sélectionner le nœud primaire, il suffit d’ajouter le paramètre
target_session_attrs=primary ou
target_session_attrs=read-write.
Par exemple :
psql "host=p1,p2,p3 user=postgres target_session_attrs=primary" psql "postgresql://postgres@p1,p2,p3/postgres?target_session_attrs=read-write" Pour une connexion en lecture seule, nous utilisons par exemple :
psql "postgresql://postgres@p1,p2,p3:5432/postgres?target_session_attrs=prefer-standby"
Créer une table :
CREATE TABLE insertions (id int GENERATED ALWAYS AS IDENTITY,DEFAULT now(),source text DEFAULT inet_server_addr()Insérer une ligne toutes les secondes, à chaque
fois dans une nouvelle connexion au primaire.
Dans une autre fenêtre, afficher les 20
dernières lignes de cette table.
Dans la colonne source de la table créée, la valeur par
défaut fait appel à la fonction inet_server_addr() qui
retourne l’adresse IP du serveur PostgreSQL sur lequel nous sommes
connectés.
Lancer une insertion toutes les secondes :
watch -n1 'psql -X -d "host=p1,p2,p3 user=postgres target_session_attrs=primary" \ -c "INSERT INTO insertions SELECT;"' Lire les vingt dernières lignes de la table :
watch -n1 'psql -X -d "host=p1,p2,p3 port=5432 user=postgres" \ -c "SELECT * FROM insertions ORDER BY d DESC LIMIT 20"' Bien entendu, nous obtenons toujours le même nœud dans la colonne
source, ici p1 :
Stopper le nœud leader Patroni.
Que se passe-t-il dans la topologie, et dans les
requêtes ci-dessus ?
Sur p1 :
# systemctl stop patroniAprès l’arrêt de p1, p3 prend le rôle de
leader :
$ patronictl -c /etc/patroni/patroni.yml topology
+ Cluster: acme (7350009258581743592) +---------+----+-----------+------+
| Member | Host | Role | State | TL | Lag in MB | Tags |
+---------------+-----------+---------+---------+----+-----------+------+
| p3.hapat.vm | 10.0.0.23 | Leader | running | 2 | | […] |
| + p1.hapat.vm | 10.0.0.21 | Replica | stopped | | unknown | […] |
| + p2.hapat.vm | 10.0.0.22 | Replica | running | 1 | 0 | […] |
+---------------+-----------+---------+---------+----+-----------+------+Les insertions échouent le temps de la bascule, ici pendant environ 2
secondes, puis continuent depuis l’autre nœud :
Arrêter les processus du nouveau primaire. Il ne
reste qu’un nœud actif. Que se passe-t-il ?
Le leader Patroni a changé à nouveau :
$ patronictl -c /etc/patroni/patroni.yml topology
+ Cluster: acme (7350009258581743592) -------+----+-----------+------+
| Member | Host | Role | State | TL | Lag in MB | Tags |
+-------------+-----------+--------+---------+----+-----------+------+
| p2.hapat.vm | 10.0.0.22 | Leader | running | 6 | | […] |
+-------------+-----------+--------+---------+----+-----------+------+
Arrêter deux nœuds du cluster etcd. Que se
passe-t-il ?
Sur e1 et e2 :
Il n’y a plus de quorum etcd garantissant une référence. Le cluster
Patroni se met en lecture seule et les insertions tombent en échec
puisqu’elles exigent une connexion ouverte en écriture :
Redémarrer les nœuds etcd.
Les écritures reprennent.
Relancer un des nœuds Patroni.
Dans le cadre de cette correction p2 est l’actuel
leader , nous redémarrons donc Patroni sur p1 :
# systemctl restart patroni L’instance sur p1 se raccroche en secondaire :
$ patronictl -c /etc/patroni/patroni.yml topology
+ Cluster: acme (7350009258581743592) +-----------+----+-----------+------+
| Member | Host | Role | State | TL | Lag in MB | Tags |
+---------------+-----------+---------+-----------+----+-----------+------+
| p2.hapat.vm | 10.0.0.22 | Leader | running | 7 | | […] |
| + p1.hapat.vm | 10.0.0.21 | Replica | streaming | 7 | 0 | […] |
+---------------+-----------+---------+-----------+----+-----------+------+
Sur le troisième nœud (arrêté), détruire le
PGDATA. Relancer Patroni.
Le PGDATA de nos instances se trouve dans
/var/lib/pgsql/16/data. Supprimons ce PGDATA
sur p3, le nœud restant :
rm -rf /var/lib/pgsql/16/dataRelançons Patroni sur ce nœud :
# systemctl start patroni Nous observons dans les journaux de Patroni et PostgreSQL que
l’instance est recrée et se raccroche à p2 :
Le temps de la reconstruction de zéro, il est possible de voir
l’évolution de l’état de p3 de
creating replica à streaming :
$ export PATRONICTL_CONFIG_FILE=/etc/patroni/patroni.yml
$ patronictl topology
+ Cluster: acme (7350009258581743592) +------------------+----+-----------+------+
| Member | Host | Role | State | TL | Lag in MB | Tags |
+---------------+-----------+---------+------------------+----+-----------+------+
| p2.hapat.vm | 10.0.0.22 | Leader | running | 7 | | […] |
| + p1.hapat.vm | 10.0.0.21 | Replica | streaming | 7 | 0 | […] |
| + p3.hapat.vm | 10.0.0.23 | Replica | creating replica | | unknown | […] |
+---------------+-----------+---------+------------------+----+-----------+------+
/* Après un certain temps */
$ patronictl topology
+ Cluster: acme (7350009258581743592) +-----------+----+-----------+------+
| Member | Host | Role | State | TL | Lag in MB | Tags |
+---------------+-----------+---------+-----------+----+-----------+------+
| p2.hapat.vm | 10.0.0.22 | Leader | running | 7 | | […] |
| + p1.hapat.vm | 10.0.0.21 | Replica | streaming | 7 | 0 | […] |
| + p3.hapat.vm | 10.0.0.23 | Replica | streaming | 7 | 0 | […] |
+---------------+-----------+---------+-----------+----+-----------+------+
Forcer un failover vers le nœud
p1.
$ patronictl failover
Current cluster topology
+ Cluster: acme (7350009258581743592) ----------+----+-----------+------+
| Member | Host | Role | State | TL | Lag in MB | Tags |
+-------------+-----------+---------+-----------+----+-----------+------+
| p1.hapat.vm | 10.0.0.21 | Replica | streaming | 7 | 0 | […] |
+-------------+-----------+---------+-----------+----+-----------+------+
| p2.hapat.vm | 10.0.0.22 | Leader | running | 7 | | […] |
+-------------+-----------+---------+-----------+----+-----------+------+
| p3.hapat.vm | 10.0.0.23 | Replica | streaming | 7 | 0 | […] |
+-------------+-----------+---------+-----------+----+-----------+------+
Candidate ['p1', 'p3'] []: p1
Are you sure you want to failover cluster acme, demoting current leader p2? [y/N]: y
[…] Successfully failed over to "p1"
+ Cluster: acme (7350009258581743592) --------+----+-----------+------+
| Member | Host | Role | State | TL | Lag in MB | Tags |
+-------------+-----------+---------+---------+----+-----------+------+
| p1.hapat.vm | 10.0.0.21 | Leader | running | 7 | | […] |
+-------------+-----------+---------+---------+----+-----------+------+
| p2.hapat.vm | 10.0.0.22 | Replica | stopped | | unknown | […] |
+-------------+-----------+---------+---------+----+-----------+------+
| p3.hapat.vm | 10.0.0.23 | Replica | running | 7 | 0 | […] |
+-------------+-----------+---------+---------+----+-----------+------+
$ patronictl topology
+ Cluster: acme (7350009258581743592) +-----------+----+-----------+------+
| Member | Host | Role | State | TL | Lag in MB | Tags |
+---------------+-----------+---------+-----------+----+-----------+------+
| p1.hapat.vm | 10.0.0.21 | Leader | running | 8 | | […] |
| + p2.hapat.vm | 10.0.0.22 | Replica | streaming | 8 | 0 | […] |
| + p3.hapat.vm | 10.0.0.23 | Replica | streaming | 8 | 0 | […] |
+---------------+-----------+---------+-----------+----+-----------+------+
Modifier les paramètres shared_buffers
et work_mem. Si besoin, redémarrer les nœuds.
Pour modifier la configuration, nous devons utiliser
patronictl, plutôt qu’éditer directement les fichiers de
configuration. Une alternative est de modifier la configuration
statique, dans le fichier YAML /etc/patroni/patroni.yml.
Cette méthode facilite leur maintenance, mais impose que le contenu soit
identique sur tous les nœuds, ce qui est généralement le cas dans un
déploiement industrialisé.
La commande patronictl edit-config appelle l’éditeur par
défaut, souvent vi, vim ou nano.
Vous pouvez modifier la variable d’environnement EDITOR
pour pointer sur votre éditeur favori.
Éditons la configuration dynamique et ajoutons les deux
paramètres :
$ export PATRONICTL_CONFIG_FILE=/etc/patroni/patroni.yml$ patronictl edit-config[…] --- +++ @@ -12,6 +12,8 @@ + shared_buffers: 300MB + work_mem: 50MB Les nœuds sont à redémarrer à cause de la modification de
shared_buffers :
$ patronictl topology
+ Cluster: acme (7350009258581743592) +-----------+----+------+-----------------+-
| Member | Host | Role | State | TL | Lag… | Pending restart |
+---------------+-----------+---------+-----------+----+------+-----------------+-
| p1.hapat.vm | 10.0.0.21 | Leader | running | 1 | | * |
| + p2.hapat.vm | 10.0.0.22 | Replica | streaming | 1 | 0 | * |
| + p3.hapat.vm | 10.0.0.23 | Replica | streaming | 1 | 0 | * |
+---------------+-----------+---------+-----------+----+------+-----------------+-Commandons le redémarrage de PostgreSQL sur les trois nœuds :
$ patronictl restart acme
+ Cluster: acme (7350009258581743592) ----------+----+------+-----------------+-
| Member | Host | Role | State | TL | Lag… | Pending restart |
+-------------+-----------+---------+-----------+----+------+-----------------+-
| p1.hapat.vm | 10.0.0.21 | Leader | running | 1 | | * |
+-------------+-----------+---------+-----------+----+------+-----------------+-
| p2.hapat.vm | 10.0.0.22 | Replica | streaming | 1 | 0 | * |
+-------------+-----------+---------+-----------+----+------+-----------------+-
| p3.hapat.vm | 10.0.0.23 | Replica | streaming | 1 | 0 | * |
+-------------+-----------+---------+-----------+----+------+-----------------+-
When should the restart take place (e.g. […]) [now]:
Are you sure you want to restart members p1.hapat.vm, p2.hapat.vm, p3.hapat.vm? [y/N]: y
Restart if the PostgreSQL version is less than provided (e.g. 9.5.2) []:
Success: restart on member p1.hapat.vm
Success: restart on member p2.hapat.vm
Success: restart on member p3.hapat.vmVérifions que le paramétrage a bien été modifié :
$ for h in p1 p2 p3; do echo -ne $h:; psql -Xtd "host=$h user=postgres" -c "show shared_buffers"; done
p1: 300MB
p2: 300MB
p3: 300MBNoter que le contenu des modifications est tracé dans un fichier
patroni.dynamic.json dans le PGDATA :
$ jq . patroni.dynamic.json
—