Vous n'êtes pas identifié(e).
Alors si la copie ne se passe pas bien sur un des deux esclaves, le maitre reçoit un code retour autre que 0 donc il recommence la copie et ça sur les 2 car il ne sait "que" refaire tout son archive_command.
Je te dirai qu'en effet le serveur esclave qui l'avait bien reçu ne s'en offusque pas et sait qu'il l'a déjà traité.
Lors de mes tests, j'ai souvent eu l'erreur car sur un des deux esclaves mon répertoire où il devait copier les WAL, n'existait pas.... oups! ou n'avait pas les droits en écriture....re oups!
Et l'autre esclave ne m'a jamais fait part d'un mécontentement....
Hors ligne
La réponse dépend de votre archive_command (et du système d'exploitation). Donc si vous pouviez préciser ces deux points, nous pourrons aider, sans problème. Mais oui, c'est le résultat de l'archive_command dans son ensemble qui compte. Donc ça dépend beaucoup de la commande et de l'interpréteur de commande. D'où la question 
Marc.
Hors ligne
Que se passe t'il si la commande arrive à copier le WAL sur seulement un des standbys ?
Tout dépend de votre script. Généralement, on fera en sorte que le script renvoie une erreur pour que le journal finisse pas être archivé sur chaque esclave.
On peut imaginer que l'archive_command sorte avec un exit status != 0. Du coup le master tentera d'archiver à nouveau ce même WAL tant que l'archive_command ne sortira pas avec un exit status ==0 ?
Oui, c'est l'idée.
J'imagine que le standby qui avait bien récupéré le WAL attendra le prochain et ne traitera donc plus jamais le WAL renvoyé ? (ouf je sais pas si j'ai été clair)
Exact aussi.
Guillaume.
Hors ligne
Moi j'ai un superbe script maintenant pour mon archive_command
Dernière modification par lolotte35 (24/11/2011 18:11:41)
Hors ligne
Superbe est peut-être un peu fort, mais il devrait donner satisfaction
Guillaume.
Hors ligne
désolé d'avoir oublié de préciser que je suis sous une Debian 6.0 avec des postgreSQL 9.0.5.
merci à tous pour vos réponses et ça me rassure et me confirme que j'avais bien suivi ce qu'il se passait.
j'ai effectivement fait un script qui sort avec un status != 0 dès qu'il y a un soucis donc je ne devrais pas être embêté !
Hors ligne
ah si j'ai une dernière question sur le sujet, le master execute l'archive_command lorsque le archive_timeout est passé ou lorsque le wal atteint sa taille max... mais lorsqu'il y a une erreur, le master tente de renvoyer le wal à quelle fréquence ? j'ai l'impression de ne pas trouver de settings répondant à ce cas
Hors ligne
Le serveur maître exécute l'archive_command soit quand le archive_timeout est passé soit quand le journal de transactions a atteint sa taille max, suivant l'événement qui arrive en premier. Pas sûr que je sois clair là
Quant à la fréquence des tentatives, il n'y a pas de configuration là-dessus. Il essaie trois fois de suite, puis attend 1 seconde et recommence. Non modifiable sans changer le code source de PostgreSQL (dans src/backend/postmaster/pgarch.c pour les curieux).
Guillaume.
Hors ligne
si si c'est clair !
dommage qu'on ne puisse pas le configurer via une setting dans le fichier de conf... car 1 seconde ça fait un peu "bourrin" quand même 
sinon effectivmement il reste la solution de modifier le code et recompiler le postgres !
merci pour toutes ces précisions en tout cas !
Hors ligne
