Vous n'êtes pas identifié(e).
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
Hors ligne
Le trigger n'a rien à voir avec l'arrêt de la réplication. Enfin si, mais ça passe votre base en production, ce qui n'est évidemment pas ce que vous souhaitez faire.
À ma connaissance, il n'y a pas de mécanisme permettant de mettre la récupération en pause simplement pour le moment. Par contre, vous pouvez toujours mettre les max_standby_*_delay à -1, illimité. Le moteur attendra le temps qu'il faudra. Les paramètres peuvent d'ailleurs être modifiés à chaud (il suffit de faire un reload).
Marc.
Hors ligne
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
Hors ligne
Tant que les fichiers de WAL sont dans le répertoire d'archive, et donc accessibles à l'esclave, pas de souci. Tu pourrais en avoir si tu n'utilises que le mode streaming: là, les journaux en cours pourraient être recyclés avant la fin du dump. Mais tant qu'il y a la restore_command pour prendre le relai, pas de souci.
Marc.
Hors ligne
Super je teste ça de suite, je verrai lors du cron nightly si mon dump se fait comme il faut !
Merci pour ces conseils.
Hors ligne