Vous n'êtes pas identifié(e).
Pages : 1
J'aimerais avant toute chose remercier Marc Cousin pour toute l'aide utile qu'il a pu m'apporter.
Je progresse dans la mise en place de la réplication entre 2 serveurs, et je m'interrogeais au sujet d'un paramètre ("restore_command").
On trouve un paragraphe dans le documentation postgresql ici :
http://docs.postgresql.fr/9.0/recovery-config.html
Et le passage est le suivant :
restore_command
La commande d'interpréteur à exécuter pour récupérer un segment de la série de fichiers WAL archivés. Ce paramètre est nécessaire pour la récupération à partir de l'archive, mais optionnel pour la réplication à flux continu. Tout %f dans la chaîne est remplacé par le nom du fichier à récupérer de l'archive, et tout %p est remplacé par le chemin de destination de la copie sur le serveur. (Le chemin est relatif au répertoire courant de travail, c'est à dire le répertoire de données de l'instance.) Tout %r est remplacé par le nom du fichier contenant le dernier point de reprise (restartpoint) valide. Autrement dit, le fichier le plus ancien qui doit être gardé pour permettre à la récupération d'être redémarrable. Cette information peut donc être utilisée pour tronquer l'archive au strict minimum nécessaire pour permettre de reprendre la restauration en cours. %r n'est typiquement utilisé que dans des configurations de warn-standby. (voir Section 25.2, « Serveurs de Standby par transfert de journaux »). Écrivez %% pour inclure un vrai caractère %.Il est important que la commande ne retourne un code retour égal à zéro que si elle réussit. La commande recevra des demandes concernant des fichiers n'existant pas dans l'archive; elle doit avoir un code retour différent de zéro dans ce cas.
Par exemple:
restore_command = 'cp /mnt/server/archivedir/%f "%p"'
restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
Je ne comprends pas bien ces explications.
J'ai parcouru ce tutorial ici :
http://www.dalibo.org/_media/replicatio … ql_9.0.pdf
Et ce tutorial évoque notamment, dans le cadre du streaming replication, pour le serveur esclave, l'utilisation de ce paramètre.
Si je fais le parallèle avec le paramètre "archive_command" au niveau du serveur maitre, je comprends que le archive_command effectue une copie des fichiers wal, dans un répertoire de son choix, afin d'archiver précisément les fichiers wal.
Mais côté serveur esclave, les fichiers wal (ou les modifications sur le serveur maitre) sont transmises via le protocol de communication entre les 2 serveurs, et donc à quoi sert en fait ce restore_command ??
J'aurais compris, qu'à l'image du serveur maitre, on puisse aussi avoir une copie des fichiers wal, du répertoire des journaux vers un répertoire de notre choix, mais le restore_command indique qu'il s'agit d'une copie dans l'autre sens : d'un répertoire d'archive vers le répertoire de travail de postgres.
Or à quoi cela sert il, puisque les informations transitent dans la communication entre les 2 serveurs et non pas par l'intermédiaire des fichiers d'archive.
Je ne comprends pas du tout à quoi sert ce paramètre, et d'ailleurs quand je ne le met pas dans le fichier de config, la réplication marche quand même, mais je m'interroge sur ce paramètre car je le vois un peu partout dans les exemples, dans le cadre de la mise en place d'un streaming replication.
Par avance, merci à celui qui pourra m'éclairer sur ce point.
Hors ligne
La réplication passe par ces fichiers. À partir de la 9.0, en utilisant la Streaming Replication, la réplication passe en plus par un protocole réseau spécifique.
Vous avez besoin de ce paramètre en cas de coupure de la liaison de réplication ou si l'esclave accuse un lag trop important.
Guillaume.
Hors ligne
Merci pour votre réponse
La réplication passe par ces fichiers. À partir de la 9.0, en utilisant la Streaming Replication, la réplication passe en plus par un protocole réseau spécifique.
Vous avez besoin de ce paramètre en cas de coupure de la liaison de réplication ou si l'esclave accuse un lag trop important.
Cela veut dire qu'avec la version 9.0, la réplication en mode "normal" s'effectue par le protocole réseau (communication entre le maitre et l'esclave).
Dans ce cas, si je comprends bien, le paramètre "restore_command" ne sert à rien.
C'est dans le cas d'une coupure de liaison que ce paramètre sert, mais cela veut dire que nous aurions été copié ces fichiers "à la main" du répertoire d'archivage du maitre vers le répertoire d'archivage de l'esclave, c'est en quelque sorte un mode de fonctionnement en secours ?
A travers la documentation que j'ai lu, je n'ai pas très bien compris également la notion de lag que vous mentionnez ici, et son impact précis (comme ce cas que vous mentionnez "en cas de lag trop important" de l'esclave, c'est un aspect encore confus pour moi).
En tout cas, merci pour votre aide.
Hors ligne
Ce n'est pas exactement ça. Ce qui se passe, c'est qu'en 'Streaming Replication', le maître ne peut envoyer que les journaux qu'il a en ligne à l'esclave. Et les journaux sont nettoyés suite aux checkpoints.
Ce qui se passe donc, c'est que si un esclave est trop en retard (suite à une coupure réseau par exemple), il ne pourra plus récupérer les données dont il a besoin par le mode streaming. Il faudra qu'il les récupère autrement. Et cet autrement, c'est par les archives, qui elles ne sont pas nettoyées par le fonctionnement 'normal' (c'est bien le principe des archives).
Donc à moins que vous puissiez garantir que votre esclave ne sera jamais en retard (c'est impossible), vous avez bien besoin d'une archive_command sur le maître et d'une recovery_command sur l'esclave.
Marc.
Hors ligne
Bonjour à tous,
Merci pour vos réponse.
D'accord, je commence à mieux cerner, et pour davantage comprendre ce mécanisme imaginons la situation suivante :
Le Maitre crée le fichier archive wal (disons) 19.
Mais il se passe un problème de connexion, et le serveur esclave ne récupère pas ce fichier 19 (mais celui-ci est archivé sur le répertoire d'archive du serveur maitre).
Arrive le checkpoint et le fichier 19 est supprimé du répertoire de log (de travail).
Entre temps, bien entendu le maitre a créée des autres fichiers wal (20, 21, ...).
Que se passe t-il lorsque le serveur esclave réussit à se reconnecter au serveur maitre ?
Du fait que le fichier 19 est absent, le serveur esclave reste t-il en attente du fichier 19 et n'exploite pas les autres fichiers wal suivant (20, 21,...) ?
Doit il impérativement récupérer le fichier 19 et le traiter (donc par ce mécanisme de restore) pour continuer le process de réplication ?
Et toujours à propos du mécanisme, ayant paramétré un répertoire d'archivage sur le serveur maitre (et pour poursuivre avec l'exemple ci-dessus), le serveur maitre après le rétablissement de la connexion avec le serveur esclave, sachant que ce dernier attend le fichier wal 19, ne peut il pas aller chercher dans son répertoire d'archive (au moins, faire la tentative de recherche) ce fichier wal 19, sachant qu'il sait où se trouve à priori son répertoire d'archive (de par le paramètre "archive_command") ?
Doit t-on donc aller récupérer à la main le fichier 19 et le mettre dans le répertoire restore alors que le serveur maitre peut très bien aller le récupérer (dés le rétablissement de la connexion) dans son répertoire d'archive et servir le serveur esclave qui lui demande ce fichier dans sa séquence de réplication.
PS à Marc Cousin : j'imagine que le recovery_command dont vous parlez est le restore_command, non ?
Hors ligne
Un journal de transactions n'est pas supprimé tant que l'archivage ne fonctionne pas (si l'archivage est activé évidemment). Un serveur esclave a besoin de tous les journaux de transactions. S'il en manque un, il ne peut pas restaurer les suivants.
Il n'y a pas de paramètre recovery_command. Il s'agit bien de restore_command. Je pense que Marc a confondu avec le nom du fichier (recovery.conf).
Guillaume.
Hors ligne
Évidemment, que j'ai confondu. Qui crée ces fichiers manuellement (et doit donc connaître précisément le nom des paramètres) alors qu'il y a un template ? 
Marc.
Hors ligne
Bonsoir,
Un grand merci à vous deux pour votre aide précieuse.
Hors ligne
Pages : 1
