PostgreSQL 9.1 Streaming Replication rattrape-t-il son retard sans archivage WAL?

16

Le contexte:

Disons que, lors de l'utilisation de Streaming Replication / Hot Standby sur un cluster Postgres 9.1, un nœud de secours tombe en panne. Il reste inactif pendant une journée, période pendant laquelle beaucoup de DML se produit sur le maître. Le fichier recovery.conf du serveur de secours ne contient pas d'entrée «restore_command» (pour la restauration à partir de fichiers journaux WAL), mais contient une chaîne «primary_conninfo» (pour Streaming Replication).

Question:

Si je redémarre la veille après une journée de changements sur le master. Sera-t-il "rattrapé" (finira par entrer dans un état qui reflète le maître) en utilisant uniquement la réplication en streaming? Ou dois-je activer l'archivage des fichiers WAL et le laisser appliquer les fichiers archivés pendant la panne pour garantir l'actualité?

J'ai vérifié le document d'archivage / réplication de streaming WAL ici , et il est dit que vous n'avez pas à activer à la fois l'archivage WAL et la réplication de streaming, mais il n'est pas clair si le rattrapage se produira ou non sans l'archivage de fichiers WAL activé.

Merci!

postgresql replication Zac B
la source

Réponses:

9

Oui, il rattrapera son retard, en utilisant uniquement le streaming, si (et seulement si) , le nombre de segments WAL générés depuis la dernière mise à jour en veille est inférieur à la valeur de wal_keep_segments dans postgresql.conf. Ceci est couvert dans cette section de la documentation: Réplication

Matthew Wood
la source
2
Cette réponse est correcte, mais elle met en évidence le problème. Si vous passez jamais wal_keep_segments, votre réplication est morte. La configuration de la réplication basée sur les fichiers n'est pas facultative si vous voulez un système qui survivra à une longue déconnexion du maître et se rattrapera.
Greg Smith
0

sur le noeud de secours, vous pouvez définir restore_command sur recovery.conf, puis copier les fichiers maîtres pg_xlog (qui manquent en veille) dans le dossier que points restore_command. Vous pouvez facilement trouver les fichiers xlog manquants en démarrant le nœud de démarrage et en tapant

ps aux | grep postgres

vous y verrez "en attente de 000000020000005200000025" ou quelque chose comme ça, qui vous indiquera quel pg_xlog vous devriez commencer à copier du maître vers le chemin restore_command du standby.

si vous activez wal_archiving, il commencera l'archivage à partir du moment où vous avez configuré.

sftsz
la source
Je comprends qu'en utilisant l'archivage WAL basé sur des fichiers et en donnant au serveur de secours une commande restore_command pour charger les fichiers WAL, je peux m'assurer qu'il se rattrape. Ce n'est pas ma question, cependant; Je veux savoir si la veille rattrapera son retard si j'utilise uniquement la réplication en streaming (pas d'expédition de fichier WAL, juste le flux de réplication comme spécifié dans 'primary_conninfo').
Zac B
non. postgres ne fait pas ça. vous devez copier les fichiers journaux s'il y a un retard dans votre réplication.
sftsz
0

Non, j'ai mis en place une instance de réplication en streaming et elle s'est désynchronisée d'une manière ou d'une autre, je n'ai pas pu la faire fonctionner à nouveau avant d'avoir fait un manuel rsyncdes archives WAL.

xénoterracide
la source