Vous n'êtes pas identifié(e).
Pages : 1
A priori, le développeur a trouvé un paramètre TrustCertificate dans a chaine de connexion a passer à true (driver npgsql). Je reste prudent, j'ai encore vu passer des FATAL: connection to client lost suivi de LOG: could not receive data from client: An existing connection was forcibly closed by the remote host.
Je vais encore investiguer et prendre le temps d'installer un pgbouncer.
Pour le moment, je n'ai pas de visibilité à ce sujet, on m'a refilé le problème un peu brutalement. Je vais me renseigner là-dessus. A priori, c'est une application web interne à un service.
On prévoit aussi de mettre en place un pgBouncer.
Finalement, je suis arrivé à avoir le développeur qui garde la session ouverte côté application. Il va changer le comportement et fermer les sessions une fois utilisées.
Merci de la réponse.
Bonne idée, même si l'application est dans Azure aussi, mais, je vais vérifier.
J'espère aussi avoir des informations sur la gestion des connexions dans l'application.
Bonjour,
J'ai une serveur PaaS Azure Postgresql en version 9.5 (!). Aléatoirement, j'ai des logs (avec une application web comme client) qui m'indique "LOG: could not send data to client: An existing connection was forcibly closed by the remote host."
Je soupçonne une connexion idle qui est fermée par le serveur (mal gérée, peut être, côté applicatif). Est-ce que j'ai un moyen de confirmer cela en évitant de tracer le réseau (avec wireshark où je ne comprends rien) ?
Quelqu'un a une expérience à ce sujet sur du Azure Postgresql single server ?
A priori, je pense qu'en dehors d'une révision des gestions de connexions, qu'un pgBouncer pourrait régler ce problème. Que puis-je proposer de plus ?
Merci.
Je crois que notepad++ l'indique mais je n'en sais guère plus que ça. Mes connaissances sont Windows ne sont plus ce qu'elles étaient.
Pour Notepad++, l'encodage est indiqué dans la barre d'état en bas à droite et il y a un menu "Encodage" dans la barre de menu qui donne l'information et permet de transcoder.
J'ai eu ce problème d'accent après un copy que j'ai réglé en passant le fichier en UTF8 (je me rappelle plus si c'était avec ou sans BOM) depuis Notepad++.
Merci. En effet, je découvre barman et aussi que je n'ai pas assez d'espace disque si je loupe une journée de backup 
.
Je suis en cours de remonter la réplication avec un script qui encapsule les étapes repmgr.
Dommage qu'il ne crée par le slot de réplication sur le master.
Je ferme ce sujet.
A priori, avec le reuse-link il n'y a pas de copie complète, juste les fichiers modifiés. J'ai testé sur une base de dev
Je me suis emballé un peu. Si je change latest par le nom du backup, j'ai pu supprimer le backup failed.
Cela m'a libéré 200 Go de disque.
Je comprends que la commande barman backup --reuse-link xxx utilise le précédent backup et fait des liens fichiers pour gagner de la place.
Cependant sur l'échec, j'avais la même taille dans les 2 répertoires (celui en échec et le vieux).
Est-ce qu'il faut temporairement un espace suffisant pour toute la base et ensuite les links se font pour gagner de place ? C'est-à-dire avoir à minima la taille de toutes les bases soit 300 Go dans mon cas ? Ou est-ce parce que tous les fichiers de ma base ont été modifiés (et dans ce cas, j'aurais forcément 300 Go).
Bonjour,
J'ai un backup en erreur (suite à un problème d'espace disque) avec barman.
La commande barman utilise la commande "barman backup --reuse-backup=link xxx" qui est ordonnancée le soir et sur laquelle je n'ai pas accès.
La politique de redondance est de 1.
J'ai deux backups dans le dossier base/
un vieux de dimanche qui a fonctionné et celui de cette nuit qui a planté.
barman delete xxx latest me dit
WARNING: Skipping delete of backup 20210511T114006 for server xxx due to minimum redundancy requirements (minimum redundancy = 1, current redundancy = 1)
ERROR: Cannot delete backup
Est-ce que je peux supprimer en rm -R le dossier du backup 20210511T114006 (celui en échec) et la commande barman de ce soir recréra un backup correct (l'espace disque manquait un peu de place, c'est corrigé si je supprime ce backup - je n'ai pas assez de disque pour 2 backups).
Vaut-il mieux de tout supprimer et lancer un barman backup xxx puis la commande du soir mettra à jour ?
Merci.
Merci de cette réponse. Je n'y avais pas songé.
C'est ce que j'ai fait et effectivement ça a débloqué la situation barman.
Je n'ai pas d'explication sur la perte de ce répertoire.
Je vais essayer de relancer la réplication avec repmgr.
Merci beaucoup de votre aide.
Concernant barman, j'ai un soucis. Les opérations que je tente sur barman (backup, archive ...) me donne une erreur :
-bash-4.2$ barman backup xxxx-pgsql-vipw-01
EXCEPTION: [Errno 2] No such file or directory: '/var/run/barman/.xxxx-pgsql-vipw-01-backup.lock'
Les wal s'accumument dans mon répertoire incomming de sauvegarde.
Le problème est décalé sur barman et je suppose quand le disque sera plein sur le serveur barman, l'archive_comande ne fonctionera plus.
Je n'ai pas de /var/run/barman
Quelqu'un a une idée pour régler ce problème barman avant que je relance la réplication ?
Merci.
erreur ne pas ternir compte
A priori, sur le secondaire, je n'ai pas de log postgresql à la date du 9 mai. Je pense que le serveur a du stopper et que cela a provoqué l'accumulation des wal.
J'ai déenregistré le secondaire avec repmgr et supprimé le slot et archive_command (avec pg_drop_replication_slot, je n'ai pas trouvé la commande qui le fait avec repmgr) a fait le ménage, l'espace est retrouvé.
il me reste à relancer la réplication.
Bonjour,
J'ai un soucis sur un serveur principal qui a accumulé des wal dans pg_xlog. Le log de postgresql indique des erreurs rsync. A cours de disque, le service postgresql s'est éteint.
Pour débloquer la prod, des wal censés être traités (marqué .done dans archive_status/) ont été déplacés, ce qui a permis de remonter le service postgresql (et permettre des traitements de nuit).
La réplication est maintenant HS et les wal continuent à s'accumuler.
Je pense que ce problème est connu et trivial, mais je n'ai pas les compétences pour le gérer.
Le détail de l'environnement :
- 2 serveurs postgresql 9.6 répliqués par repmgr (streaming), base de 300 Go, la commande archive_command est un rsync sur un serveur de sauvegarde avec barman
- le serveur barman qui doit recevoir les wal du primaire
- la réplication est hs (pg_stat_replication ne donne rien), le slot est toujours présent
- les wal s'accumulent toujours
Comment puis-je nettoyer le pg_xlog et remonter la réplication ?
- est-ce que je dois supprimer le slot de réplication puis recréer la réplication ?
Eventuellement, notre équipe est prête à accepter une petite prestation pour nous aider (me contacter en privé).
Merci.
Pages : 1
