Vous n'êtes pas identifié(e).
J'ai en effet trouvé des requêtes sur pg_lock et pg_stat_activity, mais comme le problème n'arrive pas à heure fixe, ce n'est pas évident d'arriver à les exécuter en même temps que le lock...
Bon déjà, je peux dire aux développeurs que le problème n'est pas du tout lié à Postgres !
Bonjour,
Depuis quelques jours et sans modification de paramètres Postgres ni d'application (mais après un arrêt brutal de notre appplication métier), nous avons beaucoup de "process still waiting for ShareLock on transaction " ou de "Deadlock".
Exemple de log :
2012-05-21 11:02:48 CEST [3872]: [7-1] LOG: process 3872 still waiting for ShareLock on transaction 12371183 after 1000.083 ms
2012-05-21 11:02:48 CEST [3872]: [8-1] CONTEXT: SQL statement "SELECT 1 FROM ONLY "public"."t_if_import" x WHERE "id_if_import" OPERATOR(pg_catalog.=) $1 FOR SHARE OF x"
2012-05-21 11:02:48 CEST [3872]: [9-1] STATEMENT: INSERT INTO t_if_stat (id_if_import, lib_if_stat, phase_stat, metier_stat, type_stat, etiquette_stat, compteur_stat, info_stat, id_if_stat, date_creation) VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10)
Premièrement, est ce que cela peut venir de notre version de Postgres 9.1.1 ?
Une mise à jour en 9.1.3 est prévue, mais peut être avancée si le problème est connu en 9.1.1.
Deuxièmement, y a-t-il un moyen de logguer plus d'information sur ces locks ? ou sur les transactions ?
Comment savoir à quoi correspond la transaction 12371183 ?
Car là nous voyons que l'insert est bloqué, mais on ne sait pas par quelle requête il est bloqué...
Il sagirait de trouver des éléments pour régler le problème...
Merci
ok merci, donc si on utilise des order sur une colonne, c'est bien de garder son index normal.
Merci pour toutes ces informations, c'est vrai qu'avant nous étions en 8.2.14 et que nous avions pris l'habitude de créer 2 indexs sur les colonnes où nous utilisions des LIKE et des EQUAL.
Bonjour,
je suis en Postgres 9.1.1, j'ai un index en varchar_pattern_ops sur une colonne, je pensais qu'il n'était utilisé que pour les LIKE.
Mais là j'ai fait une requête avec un = et je vois dans mon explain qu'il utilise mon index!
ça me va très bien, mais c'est normal?
Est ce que c'est uniquement parce que la table ne contient pas beaucoup d'enregistrement (53 000) ?
Ou alors le varchar_pattern_ops fonctionne pour les LIKE et les = ?
Car sur d'autres tables ( beaucoup plus volumineuses) nous avons créé 2 indexs sur la même colonne, l'un en varchar_pattern_ops et l'autre sans pour les cas où nous utilisons un LIKE ou un equal.
Merci pour vos réponses
Moi j'ai un superbe script maintenant pour mon archive_command 
Alors si la copie ne se passe pas bien sur un des deux esclaves, le maitre reçoit un code retour autre que 0 donc il recommence la copie et ça sur les 2 car il ne sait "que" refaire tout son archive_command.
Je te dirai qu'en effet le serveur esclave qui l'avait bien reçu ne s'en offusque pas et sait qu'il l'a déjà traité.
Lors de mes tests, j'ai souvent eu l'erreur car sur un des deux esclaves mon répertoire où il devait copier les WAL, n'existait pas.... oups! ou n'avait pas les droits en écriture....re oups!
Et l'autre esclave ne m'a jamais fait part d'un mécontentement....
ça fonctionne!
ah oui on a une navette entre nos 2 sites! je pourrai essayer...
Merci et bon week end
En effet, je suis si déçue!
ok donc sur l'esclave je lance :
/usr/pgsql-9.1/bin/pg_basebackup -h IP_MAITRE -D /data -U replication_role –v
j'essayerai dès lundi, en arrêtant un de mes standbys!
Pour le week end, je vais les laisser se reposer.
ah donc sur l'esclave je dois faire
/usr/pgsql-9.1/bin/pg_basebackup -D /data/ -U replication_role –v
et il sait tout seul où est son maitre! mais quel homme !
Vous parlez dans le "archive _command" ou dans le "rsync" pour la première syncro?
J'ai un standby qui n'a pas de problème de réseau car sur le même site et l'autre qui en effet peut en pâtir.
j'ai donc mis dans mon archive commande pour le standby de l'autre site :
rsync -az %p 192.168.10.xxx:/data/archives_xlog/%f
avec le z il compresse
et quand je fais le rsync pour la 1ère syncro :
rsync -avz -e ssh /data/ IP_serveur_esclave:/data/ --exclude postmaster.pid --exclude postgresql.conf --exclude pg_hba.conf --exclude save/ --exclude logs/ --exclude files/ --exclude pg_log/
Quand il n'y a que quelques fichiers de 16Mb ça va, mais comme notre base fait 20Giga, quand il doit tout rappatrier sur Paris, ça lui prend du temps. Je pourrai peut être lui faire prendre le tgv!
/usr/pgsql-9.1/bin/pg_basebackup -D 192.168.13.36:/data/ -U replication_role –v
J'ai exécuté cette commande sur le maitre
l'ip est celle d'un standby
le répertoire où il doit copier est "/data"
l'utilisateur de réplication est replication_role
ok merci pour tous ces renseignements!
Hier soir, j'ai voulu lancé le rsync du standby qui n'est pas sur le même site (après le start) et j'ai pu voir que sans l'option "-z" de compression mon réseau n'est pas content, contre 3h de transfert en compression , là en 12h il n'avait pas fait grand chose, j'ai même dû le stopper pour ne pas pénaliser le réseau!
Cette nuit, je le remets avec l'option de compression
Et je testerai les temps pour tous les types de maintenance !
Oui il faut que je trouve la bonne valeur du wal_keep_segment, 1000 c'était vraiment trop!
Du coup, si le standby prend 3h à traiter ses fichiers WAL et qu'il vient demander au maitre les nouveautés et que le wal demandé n'est plus disponible, alors mon Standby est "mort". il faut le reconstruire?
Si c'est le cas, j'ai intérêt à trouver un wal_keep_segment parfait, vu le retard que prend mon standby dès qu'il y a une opération de maintenance!
Cela vous semble normal que le reindex sur le maitre a pris autant de temps à se répercuter sur serveur en Standby (qui n'est pas sur le même site) soit 3h, que la remontée d'une sauvegarde (qui prend aussi 3h pour finir sur le standby)?
C'est l'opération de maintenance la plus gourmande?
J'ai testé le pg_basebackup pour éviter de faire le start, le rsync et le stop, mais ce n'est pas possible dans mon cas car mon maitre et mes standby sont sur des serveurs différents et le pg_basebackup croit que l'ip que je lui donne est un répertoire en local!
Je crois que ça ne peut fonctionner que si le maitre et le standby sont sur le même serveur, non?
d'accord donc si le Standby met 3h à intégrer ses fichiers WAL, tant qu'il reçoit toujours les nouveaux fichiers WAL envoyer par le archive_command du maitre, cela ne pose aucun soucis d'intégrité de base du Standby.
La base sera ok quand il aura rattrapé son retard.
Quand est ce que l'esclave va parler avec le Maitre alors?
Que s'il s'ennuie car il n'a pas de fichiers WAL à traiter ? (il deviendrait alors sadomasochiste 
)
Le maitre est passif, mais fait quand même l'archive command donc la copie du fichier WAL vers le Standby?
En fait le standby vient lui demander des WAL quand il n'en a plus dans son répertoire d'attente (pour moi archive_xlog)?
Je pense que le Standby ne faisait que traiter les fichiers WAL de archive_xlog vers son pg_xlog...
ça m'arrange!
ah ok, donc si le maitre réussi l'achive command il fait le passage de .ready en .done .
Et le Standby lui ,il va bien dire des mots doux au maitre non? car l'autre jour le maitre écrivait dans ses logs qu'un des standby lui parlait d'un fichier WAL qui avait été supprimé....
Merc je note!
J'espère qu'ne production cela n'arrivera jamais
Donc si je résume :
Le maitre écrit ses fichies WAL dans son répertoire pg_xlog
Les copies en même temps par le biais de la commande "archive_command" donc moi des rsync
Et n'en garde dans son répertoire que le nombre que l'on a mis dans "wal_keep_segment"
Ensuite quand il veut en archiver un, il créé un fichier vide portant le même nom dans "pg_xlog/archive_status/" en mettant comme extension ".ready".
Et quand le serveur en standby vient lui dire "c'est ok pour le fichier nommé "xxxxx" alors il le renomme en xxxxx.done (au lieu de ready).
Et le Standby fait la même démarche de "archive_status" et renommage ?
Il sait qu'il doit attendre 2 confirmations dans il a deux Standby?
Que ce passe-t-il si le standby est en retard et ne vient dire que très longtemps plus tard que c'est ok pour lui ?
Merci Marc,
Heureusement il y a une explication : j'ai précisé au début que suite à la remonter d'une sauvegarde dans une 2ème base de donnée (pour un test de réplication avec wal_keep_segment à 1000 ), l'espace disque s'est saturé sur le serveur maitre.
Je ne pouvais pas agrandir l'espace disque car c'est un disque physique.
Je n'ai pas eu d'autre choix que de supprimer des fichiers dans le répertoire pg_xlog sinon impossible de redémarrer postgres qui manquait de place!
J'ai donc ensuite vu que 1000 c'était trop pour ce paramètre....
ah ça marche! trop bien, merci!
c'est surtout pour les cas où ça arriverai en production!
ok et s'il n'y avait pas eu d'erreur de place sur le disque, il aurait bien compris qu'il n'avait plus de standby ?
non.... ce n'est pas bon tout ça?
un peu quand même , vu ce que je lui fais faire en ce moment, le pauvre!
oui en prod on nele ferai qu'une seule fois, le jour J ensuite normalement y aura pas de problème!
là justement je suis en test donc je tue souvent mes bases et mes réplications pour tout refaire!
