Vous n'êtes pas identifié(e).
Bonjour,
J'aurai une petite question concernant les tablespaces quand on est dans un contexte master-slave par une réplication hot standby sur des serveurs PostgreSQL 9.0 (installés via les backports Debian Squeeze).
J'ai une nouvelle partition SSD sur mes 2 serveurs que j'aimerai bien utiliser pour y placer par exemple les indexes de mes tables (afin de profiter de la rapidité de l'accès en lecture de cette partition).
En lisant les docs j'ai bien vu que les tablespaces étaient bien "transmis" dans les WAL (sous contrainte d'avoir la même location sur le master et le slave), cependant j'ai quelques doutes sur l'opération d'alter qui va me permettre de bouger mes indexes sur cette nouvelle location:
* est ce bien transmis ? à priori oui mais je n'ai pas vu d'indication ferme sur le sujet
* et pendant le alter est ce que ma base sera toujours accessible au moins en lecture ? je m'explique... j'ai remarqué que lorsque que je faisais des "reindex" sur mon master et que je lançais un select sur la même base sur mon slave, mon select restait en "waiting" le temps du réindex... et je n'arrive pas bien à comprendre pourquoi et vu qu'on est sur de la prod j'aimerai éviter ce genre de cas pour mon alter
Si vous avez des pistes pour ces questions je suis preneur!
Merci d'avance,
/Erwan
nota: je comprends encore moins le souci du REINDEX quand je lis dans la doc ceci:
REINDEX is similar to a drop and recreate of the index in that the index contents are rebuilt from scratch. However, the locking considerations are rather different. REINDEX locks out writes but not reads of the index's parent table. It also takes an exclusive lock on the specific index being processed, which will block reads that attempt to use that index.
si je comprends bien c'est censé être bon pour de la lecture seule sur mon standby...
Bonjour Marc,
Merci pour ce retour rapide !
Effectivement tu as raison le contenu de pg_stats est bien repliqué du coup je me faisais du souci pour rien 
J'ai plus qu'à chercher le pourquoi j'ai l'impression que mes perfs ne sont pas au top alors !
encore merci !
Bonjour,
J'aurai une petite question concernant les vacuum et autre analyze lorsqu'on a une réplication de type hot standby sur des serveurs PostgreSQL 9.0 (installés via les backports Debian Squeeze).
Sur mon master j'execute un vacuum analyze ( avec une commande de type : su postgres -c "vacuumdb -U postgres -a -z" ) et je peux ensuite constater qu'il y a bien des stats qui sont calculées sur les tables de mes bases comme on peut le voir ici :
myplopDB - master=# select * from pg_stat_all_tables where relname='paloup';
-[ RECORD 1 ]----+------------------------------
relid | 37271
schemaname | public
relname | paloup
seq_scan | 16
seq_tup_read | 5537792102
idx_scan | 2858383
idx_tup_fetch | 2062859095
n_tup_ins | 346406962
n_tup_upd | 290225
n_tup_del | 0
n_tup_hot_upd | 29040
n_live_tup | 346852072
n_dead_tup | 22496
last_vacuum | 2011-04-06 00:48:17.670045+02
last_autovacuum |
last_analyze | 2011-04-06 00:50:54.966283+02
last_autoanalyze | 2011-03-23 17:03:41.917984+01Je sais qu'on ne peut pas executer ce type de vacuum sur le slave (à cause du mode recovery comme on peut le lire dans la doc), cependant j'esperai que les statistiques soient répliquées sur le slave mais ce n'est pas le cas comme on peut le constater ici :
myplopDB - slave=# select * from pg_stat_all_tables where relname='paloup';
-[ RECORD 1 ]----+-----------
relid | 37271
schemaname | public
relname | paloup
seq_scan | 13
seq_tup_read | 4501342601
idx_scan | 17652
idx_tup_fetch | 2497364528
n_tup_ins | 0
n_tup_upd | 0
n_tup_del | 0
n_tup_hot_upd | 0
n_live_tup | 0
n_dead_tup | 0
last_vacuum |
last_autovacuum |
last_analyze |
last_autoanalyze |Je pense que je suis passé à côté de qqchose mais je trouve peu de retours sur le sujet
Je me sers de mon slave pour toutes mes lectures et donc fatalement sans les stats je perds beaucoup en perf surtout sur des requêtes compliquées...
Y a t'il un moyen de calculer ces stats sur les slaves ?
Si vous avez des pistes je suis preneur !
Merci d'avance,
/Erwan
Super je teste ça de suite, je verrai lors du cron nightly si mon dump se fait comme il faut !
Merci pour ces conseils.
Bonjour Marc,
Merci pour ta réponse rapide.
J'ai effectivement vu que le trigger n'était pas designé pour faire ce que je voulais mais j'avais l'impression que ça pouvait m'aider à m'en sortir mais vu ton commentaire je pense que je vais éviter de jouer les apprentis mécaniciens
Je vais tester le -1 (surtout qu'un reload suffit pour la prise en compte) pour les options max_standby_*_delay . J'imagine qu'il n'y a aucun souci même si mon dump dure 4heures ? tant que les WAL sont bien copiés sur le slave il sera capable de reprendre comme il faut après ? (c'est ça qui me fait un peu peur - sûrement à tort).
En cherchant un peu je suis tombé sur ce genre de post : http://www.chesnok.com/daily/2011/02/10 … nd-resume/ , ça annonce des choses intéressantes pour ce genre de problématique mais c'est pas pour tout de suite peut être que cela t'intéressera
Bonjour tout le monde !
J'aurai une petite question concernant les dumps lorsqu'on a une réplication de type hot standby sur des serveurs PostgreSQL 9.0 (installés via les backports Debian Squeeze).
Je voulais profiter de cette architecture pour réaliser les dumps sur mon slave afin de ne pas charger plus mon master.
Comme une de mes bases est vraiment énorme, forcément j'ai été confronté à l'erreur suivante:
pg_dump: la commande SQL a échoué
pg_dump: Message d'erreur du serveur : ERROR: canceling statement due to conflict with recovery
DETAIL : User was holding a relation lock for too long.En parcourant ce forum et d'autres thread j'ai pu voir qu'on pouvait s'en sortir avec les valeurs des options max_standby_*_delay et/ou vacuum_defer_cleanup_age.
Cependant je suis dans un cas où l'aspect asynchrone me convient parfaitement et je peux largement me permettre de mettre en pause la réplication le temps de faire mes backups.
En gros je peux faire:
1 - mettre en pause
2 - faire mes backups/dump sur le slave
3 - reprise de la réplication... les wal continuant d'étre copié sur le slave
J'avais l'impression que l'option -t (Specify a trigger file whose presence should cause recovery to end whether or not the next WAL file is available) de pg_standby pouvait convenir mais j'ai l'impression que la réplication ne repart pas lorsque ce dernier a été effacé, je me trompe peut être ?
Avez vous des idées pour répondre à ce genre de problématique ? Ca me gène un peu de jouer avec les options citées avant car si un jour ça met plus de temps que prévu mon dump ne marchera pas...
Merci d'avance !
/Erwan