Vous n'êtes pas identifié(e).
en complément, c'est documenter aussi (en français ;-) ) dans la doc officielle :
https://docs.postgresql.fr/15/kernel-re … OVERCOMMIT
bonne lecture.
(mais en dehors de ça, il ne faut pas être trop gourmand avec le paramètre -j de pg_dump et pg_restore, c'est vraiment en fonction des ressources du serveur)
Bonjour,
plus d'info ici :
https://www.kernel.org/doc/Documentatio … accounting
mais il faut regarder :
/proc/sys/vm/overcommit_memory
This file contains the kernel virtual memory accounting mode.
Values are:
0: heuristic overcommit (this is the default)
1: always overcommit, never check
2: always check, never overcommit
si ta valeur est à 0 alors tes process peuvent être tués par oom killer.
Bonjour,
n'y aurait-il pas un problème d'oomkiller ?
Par exemple le système linux qui tue des process postgresql par manque de ressources (à cause notamment d'un trop grand nombre de jobs par pg_restore (l'option -j)).
Que valent les paramètres overcommit.xxx sur votre nouveau serveur ? par rapport à l'ancien ?
bonjour,
vous pouvez très bien utiliser une version mineure différente pour déplacer votre instance d'un serveur à un autre.
Dans votre cas la dernière est la 12.15. Vous profitez ainsi en plus d'un nouveau serveur, des derniers patchs de sécurité et des corrections de bugs.
Attention à la fin de support de la v12 qui interviendra dans environ 18 mois.
Bien vu ! merci d'avoir partagé ce cas concret, c'est très intéressant.
avant toute chose, voici la doc d'installation d'entreprisedb pour postgresql sous windows :
https://www.enterprisedb.com/docs/suppo … d/windows/
Si vous avez fait tout comme ci-dessus, alors vous devriez avoir une instance démarrée.
bonjour je ne connais pas bien windows avec postgresql mais avez-vous à un moment donné créé une instance avec initdb.exe ?
Bonjour, il ne manquerait pas le "set" dans votre commande ?
update test.fleuve set
round(tx_uti_sch, 2)
from test.fleuve ;
oui il est tout à fait possible d'avoir un replica avec du retard paramétré :
avec le paramètre recovery_min_apply_delay
(dans patroni.yml)
de plus j'ajouterai que le fait d'avoir un replica vous protège d'un crash du serveur leader mais ne vous protège pas d'une perte de données (delete malheureux, ou truncate par erreur) : en effet ces erreurs seraient répercutées via la replication sur le replica.
Si vous vouliez revenir en arrière, dans votre cas il faudrait importer le dump et donc perdre x heures de données.
Je vous conseile également d'avoir un deuxième replica pour la résiliance (en cas de perte de votre leader, vous n'auriez qu'un seul noeud, ce qui peut entrainer quelques sueurs froides...)
dans ce cas vous pouvez mettre archive_command='/bin/true'
Comme ça : pas d'archivage du tout.
Mais bon si j'étais vous je ne ferais pas comme ça.
Tout dépend de vos RPO RTO.
si vous supprimez ces archives, vous ne pourrez plus faire de restoration PITR.
Donc soit vous prenez ce risque et vous supprimez les archives (mauvaise idée en production)
soit vous déplacez ces fichiers dans un repertoire distant.
Et il vous faudrait une politique de sauvegarde avec durée de rétention des backups et des archives (c'est la base d'un système de sauvegarde de production).
Bonjour,
les fichiers temporaires sont générés par des requêtes SQL (typiquement opérations de tri qui ne tiennent pas dans la RAM).
on ne peut pas les supprimer.
Pour les journaux il ne faut surtout pas y toucher. PostgreSQL gère tout seul.
Le volume et la quantité de WAL dépend de l'intensité de l'activité SQL dans l'instance.
Si c'est intense, le nombre de wal sera important, mais ils seront recyclés au fil de l'eau.
Si ça prend trop de place, il faut augmenter l'espace disque dédié.
Qu'avez vous mis dans "archive_command" ?
Les wal archivés sont-ils stockés ailleurs, sur un autre disque/FS ?
Bonjour,
Quand vous dites 90% des 500GB : on parle de quoi ? la taille des fichiers de données ? la taille des bases visible dans psql ?
Que contient votre PGDATA ? les fichiers de données + les journaux de transactions + les fichiers temporaires ? En gros avez-vous répartis ces différents fichiers et repertoires dans plusieurs FS ou tout va t'il au même endroit ?
Si tout est en même endroit, c'est sans doute normal que la taille varie entre le leader et le replica :
- les WAL sont générés sur le serveur leader, pas le replica
- les fichiers temporaires sont générés sur le leader uniquement (sauf si vous utilisez aussi le replica en lecture seule pour requêter)
L'idée serait de comparer la taille des différents fichiers du leader et du replica.
Mais tout ce que je viens de dire peut être balancé à la poubelle si les 90% des 500GB sont la taille des bdd vu par psql...
La section bootstrap n'est utilisée qu'une fois : lors de la création initiale du cluster.
Ensuite ce sont les autres sections qui sont utilisées (dont celle qui s'appelle create_replica_method)
essayez de vider le /bases/pgsql/14/data/ du noeud 2
de faire un arrêt de patroni du noeud 2
et de faire le reinit ensuite (du noeud 2 bien sûr).
bonjour,
En plus de checker etcd, vous pouvez faire ceci pour tenter d'avoir un leader opérationnel dans le cluster :
arrêt de patroni sur les 2 noeuds.
Sur le 1er noeud : vérifier que l'instance est bien arrêtée, supprimer tous les fichiers qui ne devrait pas être là (postmaster.pid, standby.signal). Démarrer l'instance avec pg_ctl et voir si elle démarre correctement (voir les traces postgresql le cas échéant). Si elle démarre bien, vérifier si elle est bien en status primary (select pg_is_in_recovery(); >> doit renvoyer "f"). Si tout est ok : arrêt de l'instance avec pg_ctl. Relance patroni sur ce noeud et voir l'état avec patronictl list (devrait être en leader). Sinon voir les traces postgresql + patroni de ce noeud pour voir ou ça coince.
pourriez-vous essayé de faire ceci sur le 1er noeud :
patronictl -c /etc/patroni/patroni.yml restart --role master clusterig9 ig9-cluster1
Le deuxième noeud ne peut pas être recréé et réintégré dans le cluster tant qu'il n'y a pas de leader identifié.
ah... je viens de voir que rjuju avait répondu dans ce sens.
Que vous donne la commande "patronictl -c /etc/patroni/patroni.yml list" ?
et les traces patroni sur le replica en echec (2ème noeud) ? >> je viens de voir le massage plus haut de patroni.log.
Il faut donc bien supprimer le contenu de PGDATA avant de relancer patroni sur le 2ème noeud.
bonjour,
Il faut détruire le PGDATA du replica et normalement patroni devrait la recréer automatiquement selon ce que vous avez mis dans patroni.yml dans la section create_replica_methods (pg_basebackup par défaut).
Donc en gros, vous identifiez votre leader et votre replica.
sur le replica vous arrêtez patroni (systemctl stop patroni).
sur le replica vous supprimez le contenu de PGDATA et vous relancez patroni sur ce noeud.
Bonjour, en complément on peut ajouter que c'est tout à fait possible si les 2 instances n'ont pas le même port et pas le même PGDATA
Bonjour,
avez-vous essayé d'installer l'extension btree_gin dans la base de données cible ?
bonjour,
et en désactivant tout simplement le firewall pour voir s'il n'y a pas un problème sous-jacent ?
sinon vous pouvez toujours compiler les sources etcd et installer sur RHEL8 directement mais ce n'est pas conseillé car vous n'aurez pas accès aux mises à jour automatiques (via yum update par exemple).
Il faudra donc dans ce cas surveiller toutes les nouvelles mises à jour des sources et les installer à chaque fois.
A déconseiller sur un site de production.
Bonjour,
Nous avons dans notre entreprise la même problématique.
Et les paquets pour etcd ne sont pas disponibles (pour le moment et selon redhat c'est pas pour tout de suite...) dans les repo RHEL8.
Donc ce que nous faisons :
des serveurs RHEL8 pour postrgresql et patroni
des serveurs RHEL7 pour etcd.
Dans cette architecture, ça fonctionne très bien.
