Vous n'êtes pas identifié(e).
Bonjour
J'ai installé la 9.0.1 sur 2 serveurs avec log shipping, la hot-standby étant ouverte en lecture seule (hot_standby = on)
Tout marche bien (réplication avec pg_standby, accès à la hot-standby, ...) sauf que j'ai des locks sur ma hot-standby avec le scénario suivant :
- je pose un lock sur une table du serveur maitre (LOCK TABLE ma_table)
- je force un switch du wal (select pg_switch_xlog() ) pour que le lock soit propagé sur la hot-standby
- je fais une requête en lecture sur ma hot-standby (SELECT COUNT(*) FROM ma_table) qui est en attente (lock sur ma hot-standby ce qui est à priori normal). Sauf que l'attente est infinie !
Pour débloquer cette situation le seul moyen, si j'ai bien compris, est de libérer le verrou de ma_table sur le serveur primaire, du coup ça débloquera ma requête sur ma hot-standby
J'avais cru comprendre que le nouveau paramètre max_standby_archive_delay permettait de mettre un "timeout" au bout duquel la requête sur ma hot-standby était annulée, mais ce n'est apparemment pas le cas (j'ai mis max_standby_archive_delay=3s sur ma hot-standby, et ma requête attend néanmojns indéfiniment)
Du coup c'est gênant car, si le lock de ma_table sur le serveur maître dure 1 heure, la réplication sur la hot-standby est bloquée pendant 1 heure !
Le paramètre max_standby_archive_delay permet-il vraiment de débloquer ce genre de situation ?
Si oui, comment ?
Si non, existe-il une autre solution pour éviter ces blocages ?
Merci d'avance
Hors ligne
Les paramètres max_standby_*_delay n'interviennent que pour l'application des enregistrements des transactions. Autrement dit, si des modifs ont lieu sur une table qui est lockée sur l'esclave, les locks seront dégagés au bout d'un certain temps pour enregistrer les modifs sur cette table. Les autres locks ne sont pas concernés. Et un lock peut rester des heures, voire des jours si aucune modification n'est faite sur l'objet du lock.
Guillaume.
Hors ligne
Merci pour ta réponse
En fait mon problème était de pouvoir faire des sauvegardes (via pg_dumpall) cohérentes sur la hot-standby, c'est-à-dire :
- désactiver temporairement la réplication sur la standby
- faire un pg_dumpall sur la hot-standby, et tant que la sauvegarde tourne la réplication est désactivée
- réactiver la réplication sur la standby une fois la sauvegarde terminée
Néanmoins j'arrive à une situation de bloquage irrémédiable si le backup se déclenche alors qu'un lock est présent sur mon maitre :
- le backup sur ma standby se met en attente quand il tente de backuper la table lockée
- comme sur mon secours j'ai désactivé la réplication tant qu'un backup est en cours, la réplication ne reprend jamais même si le verrou se libère sur le maitre (la standby ne réappliquera pas le WAL contenant l'ordre SQL de libération du verrou)
Du coup la réplication ne se fait plus et mon backup reste en attente
Je pensais pouvoir réussir avec la hot-standby à faire des exports cohérents (sans que les données de la base soient modifiées pendant l'export) mais à priori ce n'est pas possible (facilement du moins) :-(
Dernière modification par scheu.postgresql (04/11/2010 17:24:47)
Hors ligne
Le problème de faire une sauvegarde sur l'esclave, c'est que la sauvegarde prend du temps et qu'une des requêtes de la sauvegarde peut être annulée par la réplication. Un moyen d'éviter ça est d'augmenter les valeurs des max_standby_*_delay et/ou vacuum_defer_cleanup_age, mais le tout sans annuler la réplication.
Guillaume.
Hors ligne
