Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
#26 Re : Général » Log POstgreSQL » 14/03/2016 13:05:59
Bonjour,
la date serveur est:
lundi 14 mars 2016, 12:00:08 (UTC+0100)
le parametre log_timezone est
log_timezone = 'Europe/Paris'.
Je ne suis pas sûre que c'est par rapport à ça car à la suite il reprend la bonne date (voir la dernière ligne du log). En revanche à un moment donnée (lors de l'arrêt brutal, Postgresql ( se mélange les pinceaux par rapport à l'incident system ) puis il reprend. Je dis ça car je n'arrive pas à donner une explication à ceci et c'est le but de mon post.
Merci ruizsebastien.
#27 Re : Général » Log POstgreSQL » 14/03/2016 11:52:15
Merci Guillaume pour ta réponse.
En effet, je veux bien comprendre qu'est les logs du 06/03 viennent faire dans mon nouveau fichier log?
Pourquoi cette date et pas une autre??!!
Une explication SVP ou un URL ...
Merci encore
#28 Général » Log POstgreSQL » 14/03/2016 11:36:17
- lemjid
- Réponses : 7
Bonjour,
Suite à un reboot (accidentel) d'une machine esclave PostgreSQL (Streaming replication), je trouve dans le log des lignes correspondant à une date antérieure.
Je précise on est sur le fichier log du 14/03/2016 et à un moment donner des lignes avec la date du 06/03/2016 s'incrustent dans le log.
Voile ma version Postgesql et OS:
PostgreSQL 9.3.5 on x86_64-unknown-linux-gnu, compiled by gcc (Debian 4.4.5-8) 4.4.5, 64-bit
Et voici la partie étrange (que je ne comprend pas du fichier LOG):
2016-03-14 03:32:33 CET (56e622c1.23b0 1) [unknown]@[unknown] LOG: connection received: host=xx.xx.xx.xx port=41874
2016-03-14 03:32:33 CET (56e622c1.23b0 2) xx.xx.xx.xx superdba@MABASE LOG: connection authorized: user=superdba database=MABASE
2016-03-14 03:32:33 CET (56e622c1.23b0 3) xx.xx.xx.xx superdba@MABASE LOG: statement: SELECT 'SELECTION,' || type_report_partiel FROM list_slt_type_r
eport_partiel_calcul(13691, NULL)
2016-03-14 03:32:33 CET (56e622c1.23b0 4) xx.xx.xx.xx superdba@MABASE LOG: duration: 6.768 ms
2016-03-14 03:32:33 CET (56e622c1.23b0 5) xx.xx.xx.xx superdba@MABASE LOG: disconnection: session time: 0:00:00.008 user=superdba database=MABASE h
ost=xx.xx.xx.xx port=41874
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@am, nom_team, type_abonnement, type_abonnement_categorie, nb_se
conde_abo_expiration, ar_type_droit_fonctionnel, is_calcul_algo_ok, kv_utl_config, quota_export_contact_used, quota_export_contact_nb FROM utilisateur.ret_
utilisateur_gal(2461) -- DISPATCHER_INFO:NOM_FUNCTION=>utilisateur.ret_utilisateur_gal
2016-03-06 13:02:55 CET (56dc1bee.1ad7 58) xx.xx.xx.xx eco_usr@MABASE LOG: duration: 1.704 ms
2016-03-06 13:03:04 CET (56dc1bee.1ad7 59) xx.xx.xx.xx eco_usr@MABASE LOG: statement: SELECT id_utilisateur, id_client,.......
2016-03-06 13:03:04 CET (56dc1bee.1ad7 60) xx.xx.xx.xx eco_usr@MABASE LOG: duration: 2.195 ms
2016-03-06 13:03:10 CET (56dc1bee.1ad7 61) xx.xx.xx.xx eco_usr@MABASE LOG: statement: SELECT id_utilisateur, id_client, id_l2016-03-14 03:47:27 CET (
56e6263f.1390 1) @ LOG: database system was interrupted while in recovery at log time 2016-03-14 03:21:53 CET
2016-03-14 03:47:27 CET (56e6263f.1390 2) @ HINT: If this has occurred more than once some data might be corrupted and you might need to choose an earlie
Est ce que quelqu'un à une idée SVP.
Par avance merci.
#29 Re : Réplication » Upgrade Postgresql 9.4 sans interruption de service. » 22/10/2015 15:21:33
Merci Guillaume ta réponse.
#30 Re : Réplication » Upgrade Postgresql 9.4 sans interruption de service. » 22/10/2015 09:17:22
Du coup la nouvelle machine n'au aucune valeurs ajouté en ce qui concerne la diminution de temps d'interruption?!
#31 Re : Réplication » Upgrade Postgresql 9.4 sans interruption de service. » 21/10/2015 21:22:38
Merci pour ta réponse.
Du coup quels sont les grandes lignes (étapes) pour réaliser cette migration avec un temps de coupure la plus courte possible.
#32 Réplication » Upgrade Postgresql 9.4 sans interruption de service. » 21/10/2015 18:25:37
- lemjid
- Réponses : 6
Bonjour,
Pour un environnement Streaming réplication en version 9.3 avec Debian 8.
J'ai 1 maître (M) et un esclave (S) avec trois autres esclaves en cascade (r1), (r2) et (r3).
Les trois esclaves sont rattachés (chacun) à (S) "recovery.conf/primary conninfo".
L'opération est de passer en PostgreSQL 9.4
je devrai avoir une nouvelle machine (même config et même version OS). Elle devra remplacer au final le maître(M).
Le maître (M) passera en (S) et l'esclave (S)partira au recylcage. Je revient avec la même architecture du départ avec la version 9.4.
Avez vous une idée pour faire la bascule de la version 9.3 à 9.4 sans interruption de service voir une micro interruption.
Sachant qu'il y a aussi des traitements (en lecture bien évidemment) sur les machines (S),(r1),(r2) et (r3).
Merci D'avance
#33 Re : Général » lire journaux transactions archive » 07/07/2015 18:21:40
Bonjour,
Merci gleu pour ta réponse et désolé pour ce retard faute de disponibilité. Merci encore
#34 Re : Général » lire journaux transactions archive » 12/06/2015 15:47:08
Ok Julien,
Je cherche comme indiqué à savoir comment fonctionne le mécanisme pour créer un fichier backup comme il le fait.
Peut être il faut que j'expose le problème que j'ai rencontré:
J'ai été confronté à un crach d'une base PostgreSQL 9.0. Lors de la restauration PosgeSQL me réclame un wal manquant . Après restauration il manque des données qui on été insérées.
La date des données insérées correspondent à la date de du WAl xxxxxxxxxxEC alors que le PITR demandé se trouve dans le WAL xxxxxxxxxxED. Chose que je n'arrive pas à comprendre. C'est pour cela j'ai demandé comment fonctionne le mécanisme (la logique des choses).
J'espère que j'ai été claire
Merci d'avance
#35 Re : PSQL » Compatibilité ascendante du connecteur psql » 11/06/2015 18:04:44
Merci Guillaume;
J'entends bien alors que la compatibilité ascendante et descendante est assurée (en tout cas à ce jour) pour les connecteurs "java, ecpg et bien sûre psql".
D'avance MERCI.
#36 Re : Général » lire journaux transactions archive » 11/06/2015 15:25:28
Merci Guillaume,
La réponse est claire.
J'aurai bien aimer savoir (voir la question initiale) sur quel mécanisme s'appuie PostgreSQL pour faire comme il fait pour le nommage des fichier backup_label et "nom_fichier.backup"?
D'avance merci
#37 Re : Général » lire journaux transactions archive » 10/06/2015 13:33:02
Merci Guillaume,
désolé de ne pas être claire, néanmoins je essayer de m'expliquer:
\! cat /var/lib/postgresql/9.4/main/backup_label
START WAL LOCATION: 9/CF000028 (file 0000000100000009000000CF)
CHECKPOINT LOCATION: 9/CF000028
BACKUP METHOD: pg_start_backup
BACKUP FROM: master
START TIME: 2015-06-10 12:14:04 CEST
LABEL: test-test
********
postgres=# \! ls -al /var/lib/postgresql/9.4/main/pg_xlog/
total 1033468
drwx------ 3 postgres postgres 4096 10 juin 12:18 .
drwx------ 18 postgres postgres 4096 10 juin 12:18 ..
-rw------- 1 postgres postgres 16777216 10 juin 12:10 0000000100000009000000CE
-rw------- 1 postgres postgres 16777216 10 juin 12:14 0000000100000009000000CF
-rw------- 1 postgres postgres 298 10 juin 12:18 0000000100000009000000CF.00000028.backup
...
*********
postgres=# \! cat /var/lib/postgresql/9.4/main/pg_xlog/0000000100000009000000CF.00000028.backup
START WAL LOCATION: 9/CF000028 (file 0000000100000009000000CF)
STOP WAL LOCATION: 9/D0000050 (file 0000000100000009000000D0)
CHECKPOINT LOCATION: 9/CF000028
BACKUP METHOD: pg_start_backup
BACKUP FROM: master
START TIME: 2015-06-10 12:14:04 CEST
LABEL: test-test
STOP TIME: 2015-06-10 12:18:29 CEST
==>
Visiblement Postgresql prend le dernier fichier Wal (start wal location) et il rajoute le checkpont ID (pg_current_xlog_location et un point backup comme suffix.
Autrement dit est ce qu'on peut modifier le nom fichier ".backup" et avoir un autre nom en sortie comme (date et heure sur le nom) tout en pensant à l'exploitabilité du fichier après lors de la restauration?
#38 Re : PSQL » Compatibilité ascendante du connecteur psql » 10/06/2015 09:03:00
Bonjour,
Merci Guillaume pour ta réponse.
Admettant qu'on utilise psql sur une machine (A) avec un PostgreSQL v8.4(pour éxagerer 8.1) pour attaquer des machines (B, C...) dont le serveur postgresql est en 9.x. Est ce que un jour on ne peut plus se connecter pour cause de compatibilité entre version(s).
#39 PSQL » Compatibilité ascendante du connecteur psql » 09/06/2015 16:26:25
- lemjid
- Réponses : 4
Bonjour,
Pour ce 3 types de connecteurs client (jave, ecpg et psql) quel type de compatibilité peuvent en bénéficier. C'est à dire on peut estimer combien de temps avant que le connecteur client sera obsolète dans la mesure on on a un connecteur client sur une machine qui agit sur plusieurs bases de différentes machines avec des différentes versions de PostgreSQL.
Merci d'avance.
#40 Re : Général » lire journaux transactions archive » 09/06/2015 09:16:53
Bonjour,
Est ce que quelqu'un pourra m'aiguiller SVP?
Merci
#41 Re : Général » lire journaux transactions archive » 05/06/2015 09:17:33
Bonjour
Mais comment PostgreSQL renseigne le fichier "backup_label" pour devenir <nom du WAL de début de backup>.<offset>.backup ?
mais aussi, comment bien déterminer le nom du fichier "backup_label" après son renommage à partir des informations présentes
dans le fichier backup_label renseignées par le pg_start_backup?
D'avence Merci
#42 Re : Général » Problème opérateur LIKE sur le type DATE et TIMESTAMP » 04/06/2015 09:37:51
Bonjour,
Merci beacoup Julien! En effet (ça ressemble un peut), j'ai constaté après que la colonne en question été déclaré en char(50) ce qui contient bien évidemment plus que mes caractères recherchés.
Merci encor pour ta réactivité
#43 Re : Général » Problème opérateur LIKE sur le type DATE et TIMESTAMP » 03/06/2015 11:45:37
Quelqu"un à une isée SVP?
#44 Re : Général » Problème opérateur LIKE sur le type DATE et TIMESTAMP » 03/06/2015 10:55:44
Bonjour,
Je reprend cette discussion car j'ai aussi un souci avec l'opérateur "LIKE".
Je suis en version 9.1.7 de postgresql sur redhat5. Je trouve dans la doc section 9.7.1 que l'operateud "LIKE" sans "%" se comporte comme "=" equal. alors qu'il ne me donne rien sur une recherche de chaie de 9 caractères alors que ça marche avec "%". Est ce que ceci a un rapport avec les indexes utilisés et/ou le type encodage????
Merci d'avance.
#45 Re : Optimisation » lenteur de lecture sur les foreign tables. » 20/11/2014 15:22:01
Le besoin initial est d'avoir un serveur Postgresql pour le reporting. Une architecture de hot-standby à été mise en oeuvre master/slave. Le reporting s'effectue sur l'esclave. Le problème c'est que l'application de reporting fait "CREATE UNLOGGED table from t1, join, where...", comme sur l'esclave ce n'est pas possible de faire des DDL on a choisit de faire une base avec FW pour le besoin de l'appli. Voila l'origine du problème.
Bien à toi
#46 Re : Optimisation » lenteur de lecture sur les foreign tables. » 20/11/2014 10:30:40
Bonjour,
Merci pour les réponses et l'aide que vous m'avez apporté. Pour (gleu), je sais bien que le temps de réponse ne soit le même, ce que j'essaye c'est d'optimiser ce temps là le maximum (si c'est possible bien sûre). Pour (uruvela), le choix d'un ETL est judicieux le seul problème c'est que la MAJ des donnée ne soit pas au temps réel.
Merci encore à vous et j'attend l'avis de rjuju.
#47 Re : Optimisation » lenteur de lecture sur les foreign tables. » 19/11/2014 18:18:20
Bonjour,
Voici les tests fait:
ifconfig eth0 | grep -Eo "MTU:[0-9]+"
MTU:1500 ==> Pour les deux machines donc latence 7,7772ms
==
dd if=/dev/zero of=test bs=100M count=1; scp test usertest@xxxxx1:/dev/null;
1+0 records in
1+0 records out
104857600 bytes (105 MB) copied, 0.297704 s, 352 MB/s
test 100% 100MB 50.0MB/s 00:02
===========
Est ce que je devrai fournir d'autres metriques?
Bien à toi
#48 Re : Optimisation » lenteur de lecture sur les foreign tables. » 19/11/2014 13:32:06
J'ai lu attentivement la doc officiel de la page que tu m'as communiqué (merci).
Mon problème initiale c'est le temps de réponse des requêtes SQL lancé sur la base ou les tables sont "wrappées", quand je lance la même requête (exactement la même) sur les tables d'origine du serveur maître j'ai un rapport de 10 voir plus sur le temps de réponse. (voir exemple)
==
Table d'origine
=========
explain analyze select pays_id, accord_groupe_id from dw_fait_indice_net where pays_id = '82';
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------
Seq Scan on dw_fait_indice_net (cost=0.00..92.90 rows=1352 width=16) (actual time=0.017..0.913 rows=1352 loops=1)
Filter: (pays_id = 82::bigint)
Total runtime: 1.138 ms
(3 rows)
====
Foreign table:
=========
Foreign Scan on dw_fait_indice_net (cost=100.00..219.94 rows=1352 width=16) (actual time=2.486..20.993 rows=1352 loops=1)
Total runtime: 21.642 ms
(2 rows)
Du coup avec des requêtes plus compliquées le temps de réponse risque d'être interminable.
Est ce qu'il y a un moyen de réduire ce coût? sachant que je ne peut pas créer d'index.
#49 Re : Optimisation » lenteur de lecture sur les foreign tables. » 18/11/2014 19:22:00
Bonjour,
Merci rjuju d'avoir redonner vie à mon post.
Tu pourras me dire le valeur qu'il faut mettre: true or false.
Merci d'avance.
#50 Re : Optimisation » lenteur de lecture sur les foreign tables. » 18/11/2014 11:06:40
Bonjour tout le monde,
Je suis vraiment dans une impasse et je suis à court d'idées, donc si quelqu'un pourra m'aiguiller ça sera sympa.
Bien à vous