Vous n'êtes pas identifié(e).
Société rattachée à un grand groupe, Recherche DBA postgreSQL.
------
Profil recherché:
Diplômé(e) d’une formation Bac +2, vous justifiez d’une expérience significative sur les bases de données PostgreSQL et NOSQL (MongoDB, Cassandra........).
Vous maitrisez les requêtes SQL (PL/SQL, PL/PgSQL)
Des connaissances en langage de programmation (PHP, Java, Python, Perl, Bash) seraient un plus.
------
Localisation: Marseille
Démarrage ASAP
-----
contact: 0495057662
Merci,
c'est clair.
Bonjour,
(postgreSQL 9.1, Linux Debian)
J'aimerai savoir quels sont les moyens pour évaluer le nombre de transactions/jour ou transactions/seconde dans un cluster postgresql.
Merci
Merci,
Je voudrai juste savoir si le fait de trop tracer peut affecter les performances de postgreSQL ?
Ci-joint une cartographie de mon système pour des requêtes tracées au dessus de 20ms:
Number of unique normalized queries: none
Number of queries: 770,566
Total query duration: 2d10h10m16.12s
First query: 2013-04-01 06:25:05
Last query: 2013-04-02 06:07:31
Query peak: 201 queries/s at 2013-04-01 20:48:44
Number of events: 371
Number of unique normalized events: 13
Total number of sessions: 1655
Total duration of sessions: 76d14h27.16s
Average duration of sessions: 1h6m38.08s
Total number of connections: 1787
Dans mon cas, si je trace tout, le nombre de requêtes peut être multiplier par 100 (par exemple).
Merci.
Bonjour,
Utilisant postgreSQL 9.1 sur Linux Debian,
Je souhaiterai savoir si le fait de tracer un nombre important de requêtes poserai des problèmes de performance,
sachant que le fichier de trace est sur un disque séparé: Les traces étant gérée par syslog.
Merci.
Super ça marche!
Merci Marc
ci-dessous la Config postgres:
lc_messages = 'en_US.UTF-8' # locale for system error message
# strings
lc_monetary = 'fr_FR.UTF-8' # locale for monetary formatting
lc_numeric = 'fr_FR.UTF-8' # locale for number formatting
lc_time = 'fr_FR.UTF-8'
Bonjour,
quelques soucis avec pgbadger. Je n'arrive pas à visualiser les requêtes. Je n'ai pas le menu associé (Most Frequent Queries par ex.).
La commande est la suivante:
/root/pgbadger/pgbadger /var/log/psql.log -o index.html --title server1 -f syslog
pgbadger 2.1
postgresSQL 9.0
config postgresql.conf:
log_destination = 'syslog'
log_min_messages = debug1
log_min_error_statement = debug1
log_min_duration_statement = 50
log_checkpoints = on
log_connections = on
log_disconnections = on
log_duration =on
log_line_prefix = '%t [%p]: [%l-1] user=%u,db=%d '
log_lock_waits = on
log_statement = 'all'
log_temp_files = 0
Merci.
ok,
ca confirme que je dois avoir quelques erreurs de conf. Je me met à leur recherche.
merci pour votre intervention.
si tu as bien compris ma question 
,
cependant j'arrive toujour pas a me connecter via cette methode
sur postgresdatabaseserver :
----------
psql -p5435 postgres -h pgbouncerserver -U postgres
psql: ERROR: Auth failed
.pgpass:
pgbouncerserver :5435:*:postgres:es
j'ai l'impression que pgbouncer n'arrivepas à décoder les paramètres de connexions.
ok,
mais le soucis c'est que tous mes scripts sont sur la machine ou tourne la base de donnees, cependant bien qu'étant sur la meme machine, je suis obligé, afin de respecter les procedures, d'utiliser le pooler distant (application cliente:psql).
Le pooler quant a lui n'utilise pas d'application cliente postgreSQL (mais un string de connexion en utilisant le fichier texte userlist.txt).
ca ne pose pas de problème?
pour la suite:
est-il possible de se connecter via pgbouncer en utilisant un fichier d'authentification pgpass (ou pgpass est il lié a la libpq+psql)?
Merci
merci, c'était ca, en redemarrant ca a effectivement changé, je voulais en etre sur avant d'effectuer un redémarrage en prod.
Bonjour,
j'ai quelques soucis de sécurité via pgbouncer. J'utilise pgbouncer comme pooler. Etant le DBA, Dès que je cree un utilisateur dans la base avec mot de passe, l'admin pgbouncer n'est pas forcer de tenir compte de ce mot de passe pour se connecter. Il lui suffit de mettre dans son fichier mot de passe de pg_bouncer le mot de passe qu'il souhaite. et il arrive a se connecter. Est-ce normal?
je souhaiterai authentifier les utilisateurs entre la connexion pgbouncer--->postgreSQL.
sur pgbouncer:
-------------------
pgbouncer.ini:
postgres= host=postgresdatabaseserver dbname=postgres port=5435
auth_type = md5
userlist.txt:
"postgres" "postgres"
sur le serveur de base:
-----------------------------
pg_hba.conf
host all all pgbouncerserver/32 md5
psql> alter user postgres password 'es';
ALTER
A partir d'un client:
1)
psql -h pgbouncerserver -Upostgres
Password:postgres (l'utilisateur reussi à se connecter avec le mot de passe de pgbouncer alors que son mot de passe dans la base est 'es')
2)
psql -h pgbouncerserver -Upostgres
Password:es
psql: ERROR: Auth failed (l'utilisateur ne peut pas se connecter avec le mot de passe de la base )
Environnement:
postgreSQL 8.4.4
pgbouncer 1.3.4
Merci.
1) Par contre quelqu'un saurait il dans quel cas on peut se retrouver avec un postmaster.pid vide ou corrompu qui empeche le démarrage de postgres?
Tout arrêt brutal de la base de données (kill du pid sous linux par exemple). En somme ne pas laisser le temps au serveur de supprimer le fichier postmaster.pid
2) Pour ma part, je pense avoir peut être éteint brutalement la machine sans arréter le service PostGres correctement. Est-ce que cela peut en être la cause?
Oui
3) Si je supprime automatiquement le postmaster.pid au démarrage, après ce type plantage par exemple, je risque de perdre des données dans ma base?
cause directe, Non, par répercussion oui, un arret brutal de la base de données peut créer une incohérence dans les fichiers (l'écriture d'un fichier de données qui s'arrête en plein milieu par ex.), ce qui met la base de données en mode récovery (il n'est pas dit que la restauration se terminera correctement).
Parfait,
c'était tout a fait ça.
Merci
Pourquoi cette table ne devrait plus exister ?
testifr=# \c mayo2
psql (8.4.4)
Vous êtes maintenant connecté à la base de données « mayo2 ».
mayo2=# select * from pg_tables where tablename ='asset_rights_OLD';
schemaname | tablename | tableowner | tablespace | hasindexes | hasrules | hastriggers
------------+------------------+------------+------------+------------+----------+-------------
public | asset_rights_OLD | mayo | | t | f | t
(1 ligne)
mayo2=# \d asset_rights_OLD
Aucune relation nommée « asset_rights_OLD » n'a été trouvée.
mayo2=#
elle a été supprimée ? comment ?
oui, je l'ignore
Sauf que lorsque j'ai voulu exécuter un script qui récupère l'ensemble des tables pour faire des GRANT j'ai eu cette erreur:
mayo2=# select pg_grant('view_4_mview_user','select','%','public');
ERROR: relation "public.asset_rights_old" does not exist
CONTEXTE : SQL statement "GRANT select ON public.asset_rights_OLD TO view_4_mview_user"
PL/pgSQL function "pg_grant" line 11 at EXECUTE statement
mayo2=#
ci-joint le script:
CREATE FUNCTION pg_grant(TEXT, TEXT, TEXT, TEXT)
RETURNS integer AS '
DECLARE obj record;
num integer;
BEGIN
num:=0;
FOR obj IN SELECT relname FROM pg_class c
JOIN pg_namespace ns ON (c.relnamespace = ns.oid) WHERE
relkind in (''r'',''v'',''S'') AND
nspname = $4 AND
relname LIKE $3
LOOP
EXECUTE ''GRANT '' || $2 || '' ON '' || $4||''.''||obj.relname || '' TO '' || $1;
num := num + 1;
END LOOP;
RETURN num;
END;
' LANGUAGE plpgsql SECURITY DEFINER;
par contre, J'ai eu a faire une migration de cette BD 8.1.15 => 8.4. il y'a quelque temps deja
Ci-joint la réponse du select.
-[ RECORD 1 ]--+----------------------------------
relname | asset_rights_OLD
relnamespace | 2200
reltype | 17572
relowner | 16534
relam | 0
relfilenode | 17570
reltablespace | 0
relpages | 4545
reltuples | 501125
reltoastrelid | 0
reltoastidxid | 0
relhasindex | t
relisshared | f
relistemp | f
relkind | r
relnatts | 9
relchecks | 0
relhasoids | f
relhaspkey | t
relhasrules | f
relhastriggers | t
relhassubclass | f
relfrozenxid | 1513
relacl | {mayo=arwdDxt/mayo,homsys=r/mayo}
Bonjour,
j'utilise postgreSQL 8.4 sous linux. La table pg_class continu de référencer une table qui n'existe pourtant plus. comment le mettre a jour. J'ai fait un VACUUM (sans FULL, car en prod) et un ANALYZE. Rien n'y fait.
Merci d'avance
C'est ce que je pensai aussi, mais j'espérai que ce soit plus simple que ça, vu que je suis en prod.
Merci, marc
Merci marc,
cependant je l'avais déjà fait, c'est la le soucis:
base=# select * from pg_ts_cfg;
ts_name | prs_name | locale
-----------------+----------+--------------
default_russian | default | ru_RU.KOI8-R
simple | default |
default | default | en_US.UTF-8
la locale en_US.UTF-8 est bien celle que je souhaite, je l'ai obtenu en mettant à jour la table pg_ts_cfg (ie: update pg_ts_cfg set locale = 'en_US.UTF-8' where ts_name = 'default').
quant à to_tsvector il fait ce que je veux en faisant le select "set_curcfg('default')" avant, sinon "ERROR: could not find tsearch config by locale".
Merci marc,
en faisant le select "set_curcfg('default')", ca fonctionne effectivement à partir de la console. Mais cepandant, la migration doit être invisible pour les applis, y'a t'il un moyen de le rendre effectif pour toute les sessions, sans toucher au code des applis?
oups!!
je rajoute
serveur1:
base=# SHOW lc_collate;
lc_collate
-------------
en_US.UTF-8
(1 row)
serveur2
base=# SHOW lc_collate;
lc_collate
------------
fr_FR
(1 ligne)
bonjour,
lors d'une migration de base entre deux serveur dump/restore (serveur1-> serveur2) j'ai rencontré le problème suivant avec la contrib tsearch: sachant que tout les GRANTont été accordés sur les tables pg_ts*, et le serveur à été redémarré. Est-ce un problème du à la différence des locales, si oui y'a t'il un moyen de les forcer?
serveur 1:
[root@serveur1 readonly]# uname -a
Linux serveur1 2.6.18-8.1.10.el5 #1 SMP Thu Aug 30 20:43:28 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux
[root@serveur1 readonly]# locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
version postgreSql(8.1.15)
base=# select * from pg_ts_cfg;
ts_name | prs_name | locale
-----------------+----------+--------------
default_russian | default | ru_RU.KOI8-R
simple | default |
default | default | en_US.UTF-8
(3 rows)
base=# SELECT to_tsvector('TEST TS SEARCH');
to_tsvector
----------------------------
'ts':2 'test':1 'search':3
(1 row)
serveur 2:
-bash-3.1$ uname -a
Linux serveur2 2.6.18-8.1.10.el5 #1 SMP Thu Aug 30 20:43:28 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux
-bash-3.1$ locale
LANG=fr_FR.UTF-8
LC_CTYPE="fr_FR.UTF-8"
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"
LC_MESSAGES="fr_FR.UTF-8"
LC_PAPER="fr_FR.UTF-8"
LC_NAME="fr_FR.UTF-8"
LC_ADDRESS="fr_FR.UTF-8"
LC_TELEPHONE="fr_FR.UTF-8"
LC_MEASUREMENT="fr_FR.UTF-8"
LC_IDENTIFICATION="fr_FR.UTF-8"
LC_ALL=
version postgreSql(8.1.15)
base=# select * from pg_ts_cfg;
ts_name | prs_name | locale
-----------------+----------+--------------
default_russian | default | ru_RU.KOI8-R
simple | default |
default | default | en_US.UTF-8
(3 lignes)
Merci
base=# SELECT to_tsvector('TEST TS SEARCH');
ERROR: could not find tsearch config by locale
