Vous n'êtes pas identifié(e).
Bonjour,
Je voudrais avoir vos lumières sur les bonnes pratiques concernant la gestion des archives WAL dans une configuration MAITRE/ESCLAVE avec streaming Replication.
Notamment la configuration des paramètres archive_command sur le maitre dans le postgresql.conf et restore_command dans le recovery.conf sur l'esclave.
Je pars du principe qu'il n'y a pas de ressource partagée donc toutes les opérations se font via scp.
Quelle est la bonne pratique à utiliser?
Faut il envoyer via scp les archive_WAL depuis le maitre vers le standby via archive_command (en plus de l'archivage local des WAL sur le maitre)? Dans ce cas, que vaut le paramètre restore_command?
ou
Faut il seulement archiver sur le maitre en local via archive_command et récupérer les archives_WAL depuis le standby via scp dans la restore_command du recovery.conf du slave?
ou
les deux solutions se valent. Mais quels sont les avantages et inconvénients de telle ou telle configuration.
Auriez vous un exemple simple pour illuster en prenant en compte que le host du maitre pgprmy et le host du standby est pgstdby?
Une autre question bonus sur la gestion du lag avec la streaming replication :
Les archives WAL sont ils utilisés pour remonter un gros gap dans le cadre d'une réplication par flux?
Admettons j'arrête le standby un temps. je génère du WAL sur le primaire. Je redémarre le standby.
Comment se comporte le standby pour remonter le gap? Récupère t il les WAL et les appliquent d'abord. Puis une fois remonté, il repasse en mode stream?
ou
Remonte il le gap directement par la réplication en flux sans passer par les WAL?
Je vous remercie d'avance pour les réponses que vous pourrez m'apporter.
Hors ligne
Bonjour,
L'esclave quand il est en phase streaming n'a plus besoin des wal archivés puisqu'il utilise le flux des wal du master.
Mais personnellement je préfère conserver l'envoie des wal archivés du master vers le slave pour avoir une copie supplémentaire des archives au cas où.
'Par exemple, vous perdez totalement le serveur qui heberge le master, étant donné que vous avez les wal archivés sur le serveur du slave, vous pourrez faire de la restauration PITR).
Donc ce que je fais la plupart du temps c'est un archive_command sur le master qui archive à la fois en local sur le master et à distance sur le slave (donc 1 commande cp et une autre scp ou rsync).
Plutôt que scp je préfère utiliser rsync pour plusieurs raison que je vous laisserai découvrir vous même dans les docs de cet outil.
Pour le lag, je me trompe peut être mais d'expérience si le lag est trop important le streaming est HS et le slave ne pourra plus récupérer le retard.
Exemple : le master est au niveau wal n°10, le streaming est interrompu sur le slave. Pendant ce temps le wal n°10 est archivé, il n'est donc plus dans pg_xlog (du master). Le slave reprend le streaming où il en était mais le wal n°10 n'est plus disponible donc le slave ne pourra jamais récupérer le retard (message clair dans les traces).
La seul solution est donc de reconstruire le slave avec une copie du master (start_backup, rsync, stop_backup, etc...).
Cordialement,
Sébastien.
Hors ligne
Il est essentiel de conserver l'archivage des journaux de transactions. Si l'esclave est très en retard par rapport au maître, ce dernier peut ne plus avoir les journaux nécessaires pour mettre à jour l'esclave. Dans un tel cas, l'esclave bascule de lui-même en restauration des archives. Si jamais l'archivage n'est pas fait, l'esclave ne pourra pas rattraper son retard.
Il existe bien le paramètre wal_keep_segments qui permet de s'assurer que le maître conserve un lot de journaux en cas de lag... mais ça ne fait que repousser le risque. Le seul moyen de s'en affranchir est de conserver l'archivage.
Guillaume.
Hors ligne
Désolé de répondre aussi tardivement à vos réponses.
Vos réponses confirment la vision que j'avais du fonctionnement.
Par contre pour la gestion des archives WAL sans ressources partagées.
Mieux vaut il faire le scp vers le secours depuis le primaire via un script déclaré dans l'archive_command ou vaut il mieux effectuer le scp depuis le secours via la restore_command qui va récupérer l'archive WAL sur le primaire?
Merci pour vos réponses.
Hors ligne
Bonjour,
Il vaut mieux prendre la première solution : scp (rsync c'est mieux) vers le secours depuis le primaire via un script déclaré dans l'archive_command
Cordialement,
Sébastien.
Hors ligne
