Vous n'êtes pas identifié(e).
Pages : 1
Merci pour cette réponse rapide et complète. Dommage qu'il n'y ait pas d'option pour dire au reindex de continuer en cas d'erreur.
Bonjour.
Lors d'une reindexation d'une instance (version 9.1) par un reindexdb --all, j'ai ce genre de message :
reindexdb: reindexing of database "XXXXXX" failed: ERROR: could not open relation with OID 2721209393
Ce ne pas la 1ere fois, mais avec des OID différents
question 1)
est-ce que ce message peut arriver si pendant la reindexation, une table est supprimée. L'idée serait que Postgres liste toutes les tables qu'il doit reindexer, puis parcourt sa liste en prenant les tables les unes après les autres pour les reindexer. Si une table est supprimée, lorsque PG arrive à cette table, boum message d'erreur. Est-ce que cela pourrait être l'explication ?
question 2)
est-ce que la reindexation s'arrête à la 1ere erreur : c'est l'impression que j'ai dans les logs, le message d'erreur est systematiquement le dernier dans les logs. alorq qu'avant j'ai bien les NOTICE: table "public.XXXX" was reindexed
Merci pour vos éclaircissements et bonne année à tous.
Chris
Bonjour et merci pour cette réponse rapide. Cela me conforte dans mon idée de passer par dump/restore. Bonne journée.
Bonjour.
je dois migrer des instances 9.1.6 vers du 9.5. Au passage je change de serveurs et de distribution Linux : de RedHat RHEL 5 vers Debian. Chaque serveur 9.1 aura un vis à vis en 9.5 (accès en ssh, et peut-être le port 5432 sera ouvert). J'aimerai autant que faire se peut avoir le minimum d'interruption de service.Chaque instance 9.1 a une unique base (en plus des template et de la base postgres). Volumetrie : la + grosse base fait 716 Go
1er scenario:
Il consiste à dumper la base de la 9.1 , puis à pousser le dump par scp sur l'instance 9.5 et à restaurer.
1ere question : est ce que c'est possible, j'ai quand même 4 versions d'écart ?
2eme question : la doc indique "il est recommandé d'utiliser le pg_dump de la version la + elevée". Dans mon cas il faudrait que j'utilise le pg_dump de la version 9.5. Ce qui ne m'arrange pas : je ne suis pas sûr de pouvoir installer les binaires 9.5 sur mon serveur 9.1. Je voudrai éviter de faire le dump à travers le réseau (en utilisant pg_dump de la 9.5 vers le host de la 9.1). Puis-je faire le dump avec pg_dump de la 9.1 et restaurer ce dump avec le pg_restore de la 9.5 ?
Je pense que ce scenario est peut-être le pire concernant l'interruption de service, mais c'est peut-être le plus secure pour les données.
2eme scénario : pg_upgrade
Même remarque que pour la question 1 : 4 version d'écart, ca fait beaucoup. Question subsidiaire : autant j'ai "confiance" en pg_dump+pg_restore que j'utilise beaucoup , autant je suis plus inquiet sur pg_upgrade que je n'ai jamais utilisé. Ce sera certainement beaucoup plus rapide que pg_restore, mais je vais consommer le double d'espace disque, et il faudra bien qu'à un moment je pousse le répertoire data par scp (ou rsync) et vu les volumes ce sera peut-être pire qu'un dump+restore
Voyez-vous un autre scénario , à base de réplication par exemple. L'idée serait de répliquer mon instance 9.1 sur une 9.1 debian (si je peux installer une 9.1 sur debian à côté de la 9.5, je pense que oui) pour en faire un warm standby, puis d'arrêter le maitre et d'utiliser pg_upgrade sur debian. C'est peut-être comme cela que je minimiserai l'interruption de service : j'économise le temps à faire le dump, le temps de pousser le dump par scp.
Cordialement
C'est vrai :-) . Pour l'instant on reindexe nos bases 1 fois par semaine (le dimanche car faible activité) sans trop se poser de questions sur les bons conseils de la doc (http://docs.postgresql.fr/9.1/routine-reindex.html) On pourrait certainement amélioré ce process en ne reindexant que les tables qui en ont besoin. Le tout est de savoir quand elles en ont besoin : taux de fragmentation et/ou nombre de pages gaspillées et/ou espace disque gaspillée.
A priori, les nouveaux index auront sensiblement la même taille que les anciens, donc on doit pouvoir avoir une bonne approximation en calculant la taille totale des index actuels en faisant :
select pg_size_pretty ((select sum(T.size)::bigint from (select pg_total_relation_size(oid) as size from pg_class where relkind='i')T)) as total_index_size;
En rajoutant une marge de 20% pour prendre en compte les tris et autres, on doit pas être loin.
Bonjour.
Version de PG : 9.1
Y-a-t-un moyen de savoir quel quantité d'espace disque un reindexdb --all va consommer (en fonction peut-être de la taille des index avant le reindex ?)
J'ai vu qu'en fonction du paramètre maintenance_work_mem, je pouvais diminuer les fichiers temporaire de pgsql_tmp, et j'ai fait en sorte de maximiser ce paramètre. Mais cela n'est pas suffisant.
Exemple, j'ai une base qui fait 42 Go, sur un filesystem (Linux) qui est taillé à 62 Go, dont 13 Go de disponibles. reindexdb --all consomme entièrement ces 13 Go sans aller au bout.
L'idée, serait de mettre en place un check Nagios permettant de détecter à l'avance que l'espace disque restant est insuffisant pour le prochain reindex.
Merci
Bonjour.
Merci pour ces précisions.
Bonjour.
Si j'ai bien compris, la zone wal_buffers (en mémoire partagée) sert à éviter à postgres d'écrire directement les modifications dans les WAL tant que le commit n'a pas été demandé par le client. Une fois le commit envoyé, l'écriture est faite dans le WAL courant et si synchronous_commit=on et wal_sync_method=fsync, le client attendra que les données soitent réellement écrites sur disque.
1) Les écritures dans les WAL sont elles toujours effectuées par le wal_writer ?
2) avec synchronous_commit=on, c'est le commit envoyé par le client qui réveille le wal_writer qui va a) écrire les données dans le WAL et b) faire un fsync
3) dans le cas où synchronous_commit=on le paramètre wal_writer_delay ne sert pas
4) dans le cas où synchronous_commit=off, le paramètre wal_writer_delay est pris en compte, et le wal writer process se reveille tous les wal_writer_delay, il parcourt les wal_buffers et écrit sur disque + fsync toutes les transactions committées qu'il trouve.en outre , on a la garantie que les transactions seront effectivement écrites sur disque au plus tard 3 x wal_writer_delay après que le commit aura été envoyé par le client.
Est ce que j'ai tout bien saisi, notamment le point no 3 ?
Petite précision, je suis en 9.1
Merci.
C'est vrai, zut j'aurai dû le voir :
template1=# select max_val from pg_settings where name='maintenance_work_mem';
-[ RECORD 1 ]-------
max_val | 2147483647
C'est quand même dommage avec les serveurs 64 bits que l'on a désormais de ne pas pouvoir dépasser 2 Go.
J'imagine qu'il n'y a pas d'autres solutions ?
Bonjour.
Sur une instance postgres 9.1.6, je crée un index sur une table.
Cela prend 374629.339 ms et génére 3 fichiers temporaires :
temporary file: path "base/pgsql_tmp/pgsql_tmp15890.3", size 1073741824
temporary file: path "base/pgsql_tmp/pgsql_tmp15890.4", size 1073741824
temporary file: path "base/pgsql_tmp/pgsql_tmp15890.5", size 359014400
Malgré des augmentations successives de maintenance_work_mem à 2GB, puis 4GB et enfin 11GB, je n'arrive pas à créer cet index sans fichier temporaire. C'est comme si le paramètre maintenance_work_mem n'était pas pris en compte. Or un SHOW montre bien 11GB.
Des idées ?
Merci
Merci pour ces précisions.
Je ne manquerai pas de critiquer - de manière constructive 
- vos articles.
A bientôt.
Christian
Merci Guillaume pour cette réponse rapide. Petite précision : Imaginons qu'avec un shared_buffer à 256 Mo le résultat de la 1ere requête me donne environ 99 % . Si j'augmente de manière significative le shared_buffer, est ce que le pourcentage diminuera aussi de manière significative ?
Quels seraient les symptômes si mon shared_buffer était trop petit ?
Je suis en train de potasser votre article paru dans Linux Mag 107 : vraiment très bien. J'apprends beaucoup de choses. Je vais aussi bientôt attaquer le linux Mag consacré à la version 9.
Christian
Bonjour.
Suite à un changement d'infrastructure où initialement on avait un serveur dédié à une unique instance de postgres qui hébergeait une centaine de bases (je sais c'est beaucoup), je me retrouve avec une instance de postgres par base hébergée par un unique serveur. Du coup je ne peux plus utiliser la méthode qui consiste à allouer (par défaut) 1/4 de la RAM. Je dois donc allouer à chaque instance de postgres (une centaine) un certaine quantité de RAM pour le shared_buffer. Je pars avec un défaut de 256 Mo. Existe t-il une méthode qui me permette de savoir si ,pour une instance donnée, mon shared_buffer est bien taillé ? En effet mon serveur physique dispose de 16 Go que je dois mutualiser entre la centaine de zone postgres qu'il héberge.Après de nombreuses recherches sur le web je me sers actuellement de la requête suivante :
select blks_hit*1.0 / ( blks_hit + blks_read ) * 100 as percent from pg_stat_database where datname='MABASE'.
Cela me retourne un % qui si j'ai bien compris doit être le plus proche de 100 %.
J'utilise aussi cela :
SELECT count(*) * 100 / ( select count(*) from pg_buffercache) AS "% utilise du cache" FROM pg_buffercache WHERE relfilenode IS NOT NULL;
Est ce correct ? Existe-t-il d'autres méthodes ? Petite précision je suis en 8.2.15
Pages : 1
