Vous n'êtes pas identifié(e).
Bonsoir,
Merci pour votre réponse et vos conseils, je comptais tester PoWA très prochainement, j'en profiterai pour tester aussi pgstats.
Bonsoir,
J'aimerais avoir votre retour sur l'outil pgstatspack.
Sur pgfoundry, la dernière version de cette contribution date d'octobre 2011, peut-on toujours l'utiliser avec les versions 9.x ?
L'idée est de récupérer, un peu comme avec les rapports Oracle AWR, le nombre de lectures/écritures logiques/physiques et la liste des objets les plus accédés sur une période donnée ou entre 2 "clichés".
Auriez-vous un autre outil sinon à me conseiller ?
Merci pour vos retours.
C'est effectivement ce que je comptais tenter pour cette fin de journée.
Merci !
Bonjour,
Je suis en version 9.1.3 et je cherche un moyen d'exprimer le retard de l'esclave sur le maitre en octets.
Je pensais pouvoir utiliser la fonction "pg_xlog_location_diff()" mais elle n'existe pas dans ma version.
Est-ce qu'il y a un autre moyen de calculer ce retard en nombre d'octets ?
Merci pour votre aide.
Parfait ! Merci pour votre réponse
Bonjour,
Je m'interroge sur "la durée de vie" des statistiques contenues dans la vue pg_stat_database_conflicts et la colonne "conflicts" de la vue pg_stat_database.
Est-ce qu'elles contiennent des statistiques cumulées depuis la création du cluster ?
ou est-ce que les statistiques sont remises à zéro périodiquement ?
Merci pour votre aide
C'est bien ça pour le paramètre "standby_mode" :-)
Et c'est OK pour les autres points.
Merci beaucoup !
Bonjour Guillaume,
Encore une fois, merci pour votre réactivité et vos explications !
C'est OK pour les explications sur pg_basebackup.
Par contre :-)... pour pg_standby, j'ai du mal à comprendre pourquoi il ne faut pas l'utiliser pour du Hot Standby ?? Quels sont les risques ?
Par rapport à la commande "cp", dans les tests que j'ai fait en warm standby, j'ai effectivement constaté dans les logs du serveur en warm standby des erreurs (en boucle) concernant le prochain WAL attendu sur ce serveur :
cp: cannot stat `/home/postgres913/warm_standby/archive_wals/000000020000000F000000FB': No such file or directory
mais la réplication n'a pas été arrêtée et le secondaire n'est pas devenu primaire... Pouvez-vous m'en dire plus svp ?
Par conséquent, pour le Hot Standby, si pg_standby et cp ne sont pas conseillés, que reste-t-il ?? rsync ?
Merci.
Bonjour,
J'ai bien lu la doc sur le paramètrage du Hot Standby et je me pose une question concernant les "outils" de récupération à utiliser.
Dans le fichier "recovery.conf", est-ce que l'appel à "pg_standby" dans "restore_command" est recommandé, même avec PostgreSQL 9.1 ?
J'ai fait des essais avec un simple "cp" et cela fonctionne mais je ne comprends pas ce qu'apporte en plus pg_standby.
Dans le même genre, est-il recommandé d'utiliser pg_start_backup/pg_stop_backup ou pg_basebackup ?
Par avance merci.
Merci à vous deux, vous m'avez aider à clarifier les notions.
Merci Guillaume pour votre réponse.
Donc si je "résume", la SR n'est pas forcèment associée au Hot Standby mais lorsque les 2 mécanismes fonctionnent, cela permet d'avoir un delta entre le serveur maitre et esclave beaucoup plus faible et donc 2 bases synchronisées.
Est-ce correct ?
Merci pour votre retour.
J'avais lu effectivement dans la doc PostgreSQL au chapitre 25.2.2. que le Hot Standby et la SR étaient liés dans la récupération des infos provenant des WAL mais je n'avais pas compris jusqu'à quel point.
Il me reste une question par rapport à ce que vous m'avez dit : si j'utilise la réplication sans le mécanisme de Hot Standby, est-ce que je pourrais promouvoir l'esclave en tant que maitre si ce dernier n'est plus accessible ?
Bonjour,
Je suis novice sur la fonctionnalités de Streaming replication de PostgreSQL 9.1 et j'ai dû mal à comprendre l'utilisation du Hot Standby couplé avec la Streaming Replication.
Je m'explique : si le serveur esclave est en Hot Standby et que la réplication est activée, les WAL seront archivés par le mécanisme de Hot Standby et en plus les modifications seront directement récupérées du maître via une connexion TCP via le streaming replication.
Est-ce correct ?
D'où mes questions :
- Est-ce que le serveur esclave doit forcément être en Hot Standby ?
- A quoi sert l'archivage des WAL, sachant que la base de standby est mise à jour par le mécanisme de réplication ?
- Dans quel cas est-il utile de réappliquer les WAL archivés sur le serveur esclave ?
Dans le Wiki "PITR, Warm Standby, Hot Standby, and Streaming Replication", j'ai lu que : "Streaming replication does not require log shipping in normal operation. It may, however, require log shipping to start replication, and can utilize log shipping in order to catch up standbys which fall behind. " mais ces lignes ont ajoutées de la confusion à la confusion et j'espère que vous pourrez m'aider à bien comprendre les notions de Hot Standby et Streaming Replication.
Par avance merci.
En fait, lorsque les logs contiennent le mot "DÉTAIL", pgfouine_vacuum.php ne semble pas s'en sortir et les colonnes "Deleted pages" et "Removed row versions" dans le report HTML sont à zéro. Mais je n'ai pas tracé l'exécution du script pgfouine_vacuum.php car ces colonnes sont renseignés lorsque le mot "DETAIL" est bien en anglais mais je me trompe peut-être.
Merci d'avoir continué à investiguer.
J'ai fait de même de mon côté, et j'ai aussi reproduit le problème sur une seconde VM SLES avec le français en langue d'installation.
L'idée étant de pouvoir utiliser pgfouine, je vais me contenter de positionner la variable OS "LC_MESSAGES" au préalable.
Ben oui, c'est bien ce que je pensais et qui m'inquiète un peu...
Je viens de résoudre mon problème mais j'ai dû mal à comprendre pourquoi cela fonctionne...
J'ai vérifié les locales de mon système et voici ce que j'avais :
postgres@PostgreSQL-2:~> locale
LANG=fr_FR@euro
LC_CTYPE="fr_FR@euro"
LC_NUMERIC="fr_FR@euro"
LC_TIME="fr_FR@euro"
LC_COLLATE="fr_FR@euro"
LC_MONETARY="fr_FR@euro"
LC_MESSAGES="fr_FR@euro"
LC_PAPER="fr_FR@euro"
LC_NAME="fr_FR@euro"
LC_ADDRESS="fr_FR@euro"
LC_TELEPHONE="fr_FR@euro"
LC_MEASUREMENT="fr_FR@euro"
LC_IDENTIFICATION="fr_FR@euro"
LC_ALL=
J'ai positionné ma variable LC_ALL à en_US.UTF-8 :
export LC_ALL=en_US.UTF-8
Puis sous psql, j'ai lancé un VACUUM VERBOSE et là, plus de problème de traduction du mot clé "DÉTAIL :" ??!!
INFO: vacuuming "public.item"
INFO: index "pk_item" now contains 100000 row versions in 276 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "item": found 0 removable, 0 nonremovable row versions in 0 out of 1271 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 0 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
VACUUM
Auriez-vous une idée sur la corélation entre LC_ALL et les messages sous psql ?
Par avance merci.
Oui, je parle bien des traces du serveur.
J'ai redirigé les logs de vacuumdb dans un fichier spécifique.
J'ai fait des essais directement sous psql, et j'obtiens exactement le même résultat, à savoir "DÉTAIL :" en français :-(
J'ai essayé de modifier sous psql les paramètres lc_* mais cela ne change rien.
Voici la configuration que j'ai :
lc_messages=en_US
lc_collate=fr_FR.UTF-8
lc_ctype=fr_FR.UTF-8
lc_monetary=fr_FR.UTF-8
lc_numeric=fr_FR.UTF-8
lc_time=fr_FR.UTF-8
client_encoding=UTF8
Merci pour votre aide, je vais retourner sur le wiki.
Bonsoir, désolée de vous déranger encore une fois :-(
Pour vérifier la configuration, j'ai été jusqu'à arrêter et redémarrer le serveur PostgreSQL.
Je ne comprends pas que certains messages soient en anglais et d'autres en français seulement dans les traces du VACUUM ?!
Que puis-je tester à votre avis ?
Merci.
Bonsoir,
J'ai installé PostgreSQL 9.1.3 sur un SLES 11 SP2 qui a été installé en français.
Afin d'avoir les messages et différentes traces de PostgreSQL en anglais, j'ai positionné la variable lc_messages à en_US.UTF8" et laissé les autres paramètres lc_* à 'fr_FR.UTF-8'.
La plupart des traces sont en anglais SAUF celle du VACUUM ??!!
INFO: vacuuming "public.my_table"
INFO: scanned index "pk_my_table" to remove 384 row versions
DÉTAIL : CPU 0.00s/0.06u sec elapsed 0.07 sec.
INFO: scanned index "my_table_rand_id_idx" to remove 384 row versions
DÉTAIL : CPU 0.00s/0.07u sec elapsed 0.07 sec.
Le mot "DETAIL" est en français, ce qui propose par la suite à pgfouine.
Est-ce que quelqu'un a déjà eu le problème et a trouvé une solution ?
Par avance merci.
Merci pour ces précisions.
Pour revenir sur l'information "There were 999616 unused item pointers", avez-vous une explication à me donner svp ?
Est-ce que par hasard vous auriez une documentation à me recommenter pour comprendre les outputs du VACUUM ?
Bonjour,
Je me perds dans les traces de la commande VACUUM VERBOSE et j'aurai besoin de quelques "explications de texte" ou d'un pointeur vers la doc. Je travaille avec la version 9.1.
Je viens de mettre à jour 384 lignes (sur 1000000) et e VACUUM ANALYZE me renvoie ces informations :
entrepot=# vacuum analyze verbose my_table;
INFO: vacuuming "public.my_table"
INFO: scanned index "pk_my_table" to remove 384 row versions
DÉTAIL : CPU 0.00s/0.06u sec elapsed 0.07 sec.
INFO: scanned index "my_table_rand_id_idx" to remove 384 row versions
DÉTAIL : CPU 0.00s/0.07u sec elapsed 0.07 sec.
INFO: "my_table": removed 384 row versions in 3 pages
DÉTAIL : CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: index "pk_my_table" now contains 1000000 row versions in 5486 pages
DÉTAIL : 384 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: index "my_table_rand_id_idx" now contains 1000000 row versions in 6128 pages
DÉTAIL : 384 index row versions were removed.
1 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "my_table": found 384 removable, 502 nonremovable row versions in 4427 out of 8850 pages
DÉTAIL : 0 dead row versions cannot be removed yet.
There were 999616 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.16u sec elapsed 0.16 sec.
INFO: analyzing "public.my_table"
INFO: "my_table": scanned 8850 of 8850 pages, containing 1000000 live rows and 0 dead rows; 30000 rows in sample, 1000000 estimated total rows
D'après ces traces, je comprends que 384 rows ont été flaggés périmés ("removed"). Est-ce correct ?
Est-ce que la ligne "DETAIL : 0 dead row versions cannot be removed yet" indique bien qu'il n'y a pas de transactions en mode "pending" ou "idle" ?
Par contre, que signifie "There were 999616 unused item pointers" et "0 pages are entirely empty" ?
Que signifie "0 dead rows" dans les traces du ANALYZE ?
Merci pour votre aide.
C'est OK, merci beaucoup !
Merci pour votre réponse.
Si je comprends bien, il n'y a aucune explication ou limite permettant de comprendre pourquoi il reste 36 fichiers WAL suite au checkpoint ?
