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.

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.

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.

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.