PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 Re : Général » rapport pg_badger vide » 09/11/2021 18:36:29

Bonjour,

Merci pour la réponse.
En effet j'ai testé cela et voici ce que ça donne comme format de log:
#alter system set log_line_prefix TO '[%l-1]%t;%p;%u;%d;%e;';
#seletct pg_reload_conf();

[740-1] [801-1]2021-11-09 17:21:43 CET;31687;alisa;alisa_db;00000;LOG:  duration: 0.162 ms  parse <unnamed>: update ACT_RU_VARIABLE
==> ça me rajoute une autre colonne [xxx-xx].
En revanche si je modifie les paramètres :
alter system set syslog_split_messages TO 'off';
alter system set syslog_sequence_numbers TO 'off';
select pg_reload_conf();

Voici ce que ça donne:
2021-11-09 16:49:13 CET;17946;;;00000;LOG:  automatic analyze of table "alisa_db.alisa.act_ru_variable" system usage: CPU 0.00s/0.06u sec elapsed 0.09 sec

Donc je retrouve le format (habituelle) du log PostgreSQL mais je ne sais pas encore pour le rapport PgBadger. (pas fait le test encore).
Est ce que c'est une bonne piste?

Bien cordialement

#2 Re : Général » rapport pg_badger vide » 09/11/2021 17:13:31

Re,

Au fait je ne comprend pas pourquoi la colonne [xxx-1] est dans les logs alors que dans mon log_line_prefix, il n'y a pas '%l', j'aimerai bien savoir d'où ça peut venir?!



[89-1] 2021-11-05 16:01:37 CET;31237;postgres;alisa_db;00000;LOG:  duration: 19583.248 ms  statement: select count(*) from f_parameter;

#3 Re : Général » rapport pg_badger vide » 09/11/2021 15:45:33

Bonjour rjuju,

J'ai bien rajouté '%l' au paramètre log_lin_prefix comme ceci '%l;%t;%p;%u;%d;%e;'. j'ai fais les tests après, ça ne change pas même pire la colonne au début '[1-xxx]' existe toujours. Je pense que c'est cette colonne qui plombe la lecture des logs par pgbadger.

Par avance merci

#4 Re : Général » rapport pg_badger vide » 08/11/2021 11:01:16

Bonjour rjuju,

Merci pour ta réponse.
Voici la valeur du "log_line_prefix" ('%t;%p;%u;%d;%e;')
voici la commande lancé:
pgbadger -f syslog -p '%t;%p;%u;%d;%e;' -o /tmp/`uname -n`-$PG_SERVERNAME-`date +%Y%m%d-%H%M%S`-PgBadger.out.html /pgqdata/$PG_SERVERNAME/data/pg_log/pgxxxx.log


Par avance merci

#5 Re : Général » rapport pg_badger vide » 05/11/2021 17:58:24

Bonjour,

Je me permet de relancer le sujet car j'ai presque le même problème: (le rapport est vide).
Particularité:
log_destination='syslog'

J'ai essayé pas mal de combines dans 'log_line_prefix', ça n'a pas fonctionné. Mon problème c'est que dans le log j'ai un champ que pgbadger n'arrive pas à l'interpréter


Exemple:
[10-1] 2021-11-05 16:01:07 CET;2045;;;00000;LOG:  automatic analyze of table "alisa_db.alisa.act_ru_job" system usage: CPU 0.00s/0.00u sec elapsed 0.00 sec
[11-1] 2021-11-05 16:01:07 CET;2045;;;00000;LOG:  automatic vacuum of table "alisa_db.alisa.act_ge_property": index scans: 0
[12-1] 2021-11-05 16:01:07 CET;2045;;;00000;LOG:  automatic analyze of table "alisa_db.alisa.act_ge_property" system usage: CPU 0.00s/0.00u sec elapsed 0.00 sec
[13-1] 2021-11-05 16:01:08 CET;2045;;;00000;LOG:  automatic vacuum of table "alisa_db.alisa.act_ru_variable": index scans: 1
[14-1] 2021-11-05 16:01:08 CET;2045;;;00000;LOG:  automatic analyze of table "alisa_db.alisa.act_ru_variable" system usage: CPU 0.00s/0.07u sec elapsed 0.16 sec
[15-1] 2021-11-05 16:01:08 CET;2045;;;00000;LOG:  automatic vacuum of table "alisa_db.alisa.qrtz_fired_triggers": index scans: 1
[16-1] 2021-11-05 16:01:08 CET;2045;;;00000;LOG:  automatic analyze of table "alisa_db.alisa.qrtz_fired_triggers" system usage: CPU 0.00s/0.00u sec elapsed 0.02 sec
[17-1] 2021-11-05 16:01:08 CET;2045;;;00000;LOG:  automatic vacuum of table "alisa_db.alisa.qrtz_triggers": index scans: 1
[18-1] 2021-11-05 16:01:08 CET;2045;;;00000;LOG:  automatic analyze of table "alisa_db.alisa.qrtz_triggers" system usage: CPU 0.00s/0.00u sec elapsed 0.02 sec
[89-1] 2021-11-05 16:01:37 CET;31237;postgres;alisa_db;00000;LOG:  duration: 19583.248 ms  statement: select count(*) from f_parameter;


==> J'ai l'impression que le champ entre crochets au début de chaque ligne plante le traitement pgbadger et sort le rapport à 0 pourtant dans les logs pas mal de requ^tes de tout type (SELECT, INSERT, UPDATE...etc.

Quelqu'un à une idée.
Par avance merci.

#6 Re : Optimisation » ordonnancement pg_squeeze » 17/08/2021 11:50:30

..3) faire en sorte que la fragmentation reste sous controle ...

Pour ce qui est recherche et listing des tables fragmentées, c'est clair. Pour le pourquoi et fréquence c'est souvent des mises à jours intensives (batchs) sur les tables de la base (certaines tables plus que d'autres).
Reste le point "3", contrôler la fragmentation reste un peu vague. Comme on maitrise pas le code applicatif (les données fonctionnelles), on peut que constater après coup le fragmentation. On peut aussi connaitre la fréquence voir savoir en avance de phase qu'il y aura un batch qui va insérer X lignes sur tel ou tel tables chose qu'on ne peut pas éviter et encore moins l'interdir.
Donc à quel niveau on peu contrôler? S'il s'agit juste d'avoir les informations que j'ai cité. Permettez moi cette question terre à terre, ça me servira à quoi ce contrôle comme je l'ai cité?

Par avance merci

#7 Re : Optimisation » ordonnancement pg_squeeze » 17/08/2021 10:15:04

Bonjour,

rjuju a écrit :

....personnellement je n'ai pas confiance dans cette extension et si j'étais confronté à un problème de bloat excessif je chercherais plutôt un moyen d'éviter l'apparation de bloat trop important plutôt que risquer une corruption ou perte de données.

Au fait là on est au cœur du sujet:

Entre pg_repack qui utilse des triggers et demande d'ajouter de l'espace disque pour "défragmenter" les tables avec une complexité si la tâche s'arrête ou ne fini pas pour une raison ou pour une autre...etc
pg_squeeze qui un nouveau produit (extension) avec peu de documentation...

Comment faire mieux tout en évitant ces risques et préservant les données et leurs sécurité?
Le sujet est riche peut être mais tu pourras STP donner les grandes lignes. Le but c'est d'éviter un éventuel "lock exclusif" avec le "vacuum full" et réorganisation des tables et recupération de l'espace vide pour une meilleure optimisation.

Par avance merci

#8 Re : Optimisation » ordonnancement pg_squeeze » 17/08/2021 08:55:49

Merci Julien pour ta réponse,

Par ailleurs je te conseil si tu as la possibilité de le tester ça l'air intéressant.

Merci encore

#9 Optimisation » ordonnancement pg_squeeze » 16/08/2021 16:26:48

lemjid
Réponses : 7

Bonjour tout le monde,

Par manque de documentation je voudrai savoir si quelqu'un à un retour d'expérience avec pg_squeeze?
Le problème c'est que je ne peux pas scheduler une tâche sur une table.
Il est expliqué dans la documentation (https://github.com/cybertec-postgresql/pg_squeeze), qu'il faut renseigner la table (squeeze.tables) surtout la colonne (schedule) qui contient la paramètre de la date(jour de la semaine)/heure
du déclenchement.
Pour ma part j'ai renseigner cette table mais rien ne se passe.
Je surveille le log PostgreSQL (log_min_duration_statement='0'), je n'ai rien vu et la taille de la table bloatée est toujours le même?!
en revanche quand j’exécute la fonction "SELECT squeeze.squeeze_table('squeeze', 't_test', null, null, null);" ça fonctionne et la taille de la table diminue.
les paramètres :
squeeze.worker_autostart = 'ma_base'
squeeze.worker_role = 'postgres'
sont bien renseignés
J'ai aussi modifié ces paramètres "free_space_extra,min_size et vacuum_max_age" dans (tables) en diminuant leurs valeurs toujours rien ne se d’éclanche; en tout cas la table est toujours bloatée et je ne voit d'erreur 

Est ce que j'ai oublié une/des étapes

Par avance Merci

#10 Re : Installation » Installation postgres sur redhat 7 » 16/06/2021 09:43:01

Merci beacoups à vous pour ces informations précieuses.

#11 Re : Installation » Installation postgres sur redhat 7 » 15/06/2021 14:16:13

Merci Julien

* Pour la compatibilité logicielle, j'ai compris en revanche pour éviter une éventuelle confusion, qu'est ce que tu entends dire par "compatibilité matérielle" (entre anciens et nouveaux serveurs?)
* il faut bien la même version glibc et librairies sur l'ensemble des serveurs? (ancien et nouveaux)?
Par avance merci

#12 Re : Installation » Installation postgres sur redhat 7 » 15/06/2021 09:24:51

Merci Julien pour ta réponse et ta disponibilité.
L'idée est de faire une migration Matériel en douceur.
* Les deux serveurs actuels en streaming réplication doivent être remplacés.
* On compte brancher un NOUVEAU troisième puis un quatrième "Standby".
* Débrancher les anciens UN par UN après un FailOver sur un des des nouveaux.
==> Une idée pour limiter le temps d'indisponibilité applicatif.
Je vais poser la question autrement. Faut il prendre des mesures particulières (pendant cette période; deux trois jours) permettant de réussir au maximum cette opération.
S'il y a un retour d'expérience je suis preneur (par avance merci) et surtout si l'opération est trop risquée c.à.d. une chance sur deux de tout casser me le dire. La base est volumineuse puis une restauration en PITR pourra prendre 5h application arrêtée. 

En attente de vous lire, merci

#13 Re : Installation » Installation postgres sur redhat 7 » 11/06/2021 15:02:35

Bonjour,

J'aimerai bien rebondir sur ce sujet pour demander est ce qu'il y a un retour d'expérience pour une réplication PostgreSQL en streaming entre deux serveurs en RedHat l'un en version 7.1 et Noyau 3.10.0-514 et l'autre en 7.4 et Noyau 3.10.0-693.

Par avance merci

#14 Re : Sécurité » protocol de cryptage GSS » 19/02/2021 11:08:20

Bonjour,

Si quelqu'un a une idée, merci de bien vouloir m’aiguiller.

#15 Sécurité » protocol de cryptage GSS » 16/02/2021 20:03:25

lemjid
Réponses : 2

Bonjour,

Depuis qu'on a commencer les mises à jour PostgreSQL de 9.X vers 11.X (11.5, 11.7 et 11.9), on a constaté un message d'erreur à répétions:
"FATAL:  unsupported frontend protocol 1234.5680: server supports 2.0 to 3.0"
Ce que je peux voir, c'est que ce message vient des serveurs apache.
J'ai vu sur le net qu'il concerne la connexion avec encryption "GSSAPI" et qu'il suffit de mettre:
GSSENCMODE=disable dans les variables d'environnement PostgreSQL sinon dans la chaine de connexion à la base.
J'ai vu même que c'est faisable lors de la compilation des binaires PostgreSQL. Pour nous c'est les RPMs qu'on utilise pour l'installation de PostgreSQL.

Pour moi cette recommandation n'a pas marché! Soit je n'ai pas bien fait les choses ou j'ai manqué une étape!
Est ce que quelqu'un a une idée SVP.

Par avance merci.

#16 Re : Optimisation » Bug pg_repack » 03/02/2021 11:34:08

Donc au final si on a besoin de regagner de l'espace disque occupé par des lignes "vides" dans les tables, il faut faire un VACUUM FULL.

1- De ce fait, même avec un paramétrage bien fait de l'autovacuum, on est obligé de faire le VACUUM FULL; même avec espacement important 1 fois par mois, trimestre...?
et si l'autovacuum ralenti la vitesse du "bloat" s'il est bien paramétré?
2- Si on se concentre sur la question de l'autovacuum et le faire d'une façon optimale est ce qu'on aura le résultat attendu au niveau performance? (bien évidemment associé avec le tuning ressources matériel, moteur BDD, code SQL...etc.)

#17 Re : Optimisation » Bug pg_repack » 02/02/2021 19:09:27

Merci Guillaume merci Julien d'avoir pris le temps pour me répondre.

Par ailleurs, dans le cas d'une base volumineuse ou une autre qui devra être disponible 7/24, Comment peut-on pallier aux problème de fragmentation et l'organisation des lignes mortes des tables.
Comment prévoyez vous la récupération la récupération de l'espace disque?

@Julien, est ce que je comprend qu'une bonne configuration d'autuvacuum est capable de nous épargner tout ça?

Par avance meci.

#18 Re : Optimisation » Bug pg_repack » 02/02/2021 14:50:41

Bonjour,

Si quelqu'un pourra me dire quelque chose à ce sujet.

Par avance merci

#19 Optimisation » Bug pg_repack » 01/02/2021 16:47:40

lemjid
Réponses : 7

Bonjour tout le monde,

Tout d'abord vu la situation actuelle, j'espère que vous allez tous bien ainsi que vos entourages respectifs.

Je suis en quête d'une méthode et/ou un outil qui réorganise les relations de la base PostgreSQL et qui m'épargne les désagréments de VACUUM FULL à savoir les locks avec des bases de données de plus en plus exigeants en terme de disponibilité.
L’extension pg_repack, est un bon compromis, mais à part l'espace disque à fournir en plus pour le faire fonctionner. Ceci n'est pas très grave, le support magnétique n'est pas ce qui coûte le plus chère.

Le problème c'est qu'en cherchant, je trouve une publication de "DALIBO" disant ceci "pg_repack étant très intrusif et ayant déjà affiché des bugs de corruption de données, nous déconseillons fortement son utilisation." Fin de Citation.
A savoir que pour les versions <=1.1.8, il ne faut pas lancer des DDL au moment ou pg_repack fait sont travail car il y a un risque sérieux de corruption de données à défaut d'un rollback.

Ma question est : La recommandation de BALIBO concerne t elle les anciennes version ou elle est toujours d'actualité.

Est ce que quelqu'un utilise l’outil "pg_repack en production "surtout pour des base à grande taille >=500Go, pourra partager son/ses expérience.


Par avance merci

#20 Publications » PostgreSQL Sera t-il mangé comme MySQL?! » 15/10/2020 15:19:16

lemjid
Réponses : 1

Bonjour,

Vu dans la presse électronique:

Bruce Momjian:
https://www.postgresql.org/community/contributors/

Voici ce qu'il a déclaré:
https://www.developpez.com/actu/309521/ … e-Momjian/


Communiqué de EDB:

https://www.enterprisedb.com/news/edb-c … l-products
https://www.enterprisedb.com/blog/how-e … res-market

*** J'ai cru comprendre au début de mon expérience avec PostgreSQL 2009 que vu son organisation Il ne pourra pas subir le sors de MySQL!!! Les temps ont changés?
Si quelque pourra m'apporter (apporter aux utilisateurs PostgreSQL) une réponse.

Par avance Merci.

#21 Re : Général » Mise à jour PostgreSQL » 06/03/2020 14:48:07

Bonjour,

Merci beaucoup "rjuju, pifor et gleu". Merci pour l’intérêt, la disponibilité et merci pour les réponses.

__________________________________________

Badreddine.

#22 Re : Général » Mise à jour PostgreSQL » 05/03/2020 17:16:45

Merci Julien, c'est très intéressant ce que tu viens de dire et ça me convient parfaitement.
Si je me permet de te demander STP, je peux trouver quelque part "écrit, url...etc." ce que j'ai lu dans ton message:
(Seule la compatibilitré descendante est assurée, pas ascendante.).
Je précise que ce n'est pas pour mettre en cause ce que tu as dis bien au contraire.
Je voulais juste avoir un appui officiel pour faire valoir ceci.

#23 Re : Général » Mise à jour PostgreSQL » 05/03/2020 16:06:36

Je suis désolé, je n'ai pas bien compris la question. Mais je dirais car le "create table ...with oids;" est toujours possible avec la V11.

[dvsgdas00b00004:postgres:pgserver02]$psql smart_engagement
psql (11.2)
Type "help" for help.

localhost:5433 postgres@smart_engagement=# create table t2 (c1 int) with oids;
CREATE TABLE
localhost:5433 postgres@smart_engagement=#

En tout cas initialement je suis en quête d'arguments techniques (explications) sur les recommandations de faire le dump avant mise à jour avec l'outil "pg_dump" de la version de destination?
C'est vraiment ce que je recherche précisément.

Merci pour votre aide

#24 Re : Général » Mise à jour PostgreSQL » 05/03/2020 12:39:08

Bonjour,

Merci pour vos réponses.
Pour "rjuju", ce n'est pas la politique des M-à-J PostgreSQL que j'investigue.
J'essaie de comprendre (avec vos aides bien sur) les contraintes techniques qui nécessite cette recommandation.
Par exemple pour le V12. Je sais que la colonne OID à été enlevée. Que le "create table with OID" n'est plus possible.
Comme le pg_dump fait un select il vaut mieux faire le dump avec les binaires de la V12 pour upgrader une version inférieure. Pour moi c'est un argument claire, simple à comprendre et précis.
C'est ce que je recherche via ma requête.
Par avance Merci.

#25 Général » Mise à jour PostgreSQL » 04/03/2020 19:02:56

lemjid
Réponses : 10

Bonjour,

J'ai vu plusieurs messages sur le net y compris celui-ci de guillaume L.:

"Il est à savoir qu'il n'y a aucune garantie par la communauté PostgreSQL qu'une sauvegarde réalisée avec un pg_dump en
version X puisse être restaurée en version X-1. Il est toujours conseillé de sauvegarder avec la version sur laquelle on veut restaurer."

Dans le forum PostgreSQLFr : https://forums.postgresql.fr/viewtopic.php?id=4879

En résumé, c'est conseillé dans le cas de mise à jours majeure de faire la sauvegarde via les outils (pg_dump, et pg_dumpall) en utilisant les binaires de la version de destination.

Mon souhait, est de comprendre les arguments de ce message (recommandation). Si possible s'il vous plait de me donner le liens dans le document officiel ou quelque chose similaire (wiki postgres, planete, site developpeurs PG...etc.) car sauf erreur de ma part, je n'ai pas vu ceci (en tout cas pour la version 9.6.x).

Par avance Merci.

Pied de page des forums

Propulsé par FluxBB