Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
J'ai un serveur primaire avec une réplication logique définie sur un serveur secondaire.
Hier, un problème de fichier temporaire trop gros sur le primaire a bloqué la réplication du serveur secondaire, bien que le serveur primaire n'ait pas stoppé.
Dans les logs du primaire, on a les lignes suivantes :
ERROR: could not extend file "base/470081886/2605213501.244": No space left on device
ERROR: could not write to data file for XID 86374211: Resource temporarily unavailable
Et depuis, la réplication logique ne fonctionne plus.
La vue pg_stat_replication affiche bien le serveur secondaire, mais il est dans un état "catchup". La colonne sent_lsn montre que le primaire continue d'empiler les WAL, mais les colonnes write_lsn, flush_lsn et replay_lsn restent bloquées à la même valeur. Du coup, les WAL s'empilent sur le principal.
Côté secondaire, la souscription est toujours présente. En revanche, je ne vois pas, dans la liste des processus, de processus walreceiver.
Avez-vous une idée de la façon de débloquer la situation, sans avoir à reconstruire la réplication complète sur le secondaire ?
Merci d'avance pour votre aide.
Hors ligne
Quelles versions de postgres utilisez vous (primaire et secondaire) ?
Si le walreceiver n'est pas présent sur le secondaire, les logs devraient indiquer pourquoi car celui-ci devrait se relancer automatiquement.
Julien.
https://rjuju.github.io/
Hors ligne
Effectivement, j'ai oublié de préciser que les deux serveurs étaient en v10.
Sur le secondaire, on ne trouve rien dans les logs, ce qui est curieux...
Hors ligne
Effectivement, j'ai oublié de préciser que les deux serveurs étaient en v10.
quelle version mineure, sur chaque ?
Sur le secondaire, on ne trouve rien dans les logs, ce qui est curieux...
Vraiment, rien du tout depuis le problème initial ? Avez-vous vérifié qu'il s'agit du bon fichier et/ou que les logs fonctionnent encore (provoquer une erreur quelconque sur le secondaire par exemple).
Y a-t-il des messages d'erreurs spécifiques sur le primaire depuis l'incident ?
Avez-vous essayé de redémarrer le secondaire ?
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour Julien,
Ce qui est compliqué, c'est que c'est un serveur que je n'administre pas directement (support de deuxième niveau). Les versions mineures sont toutes en 10.4.
Nous avons bien redémarré les secondaires (première opération effectuée).
Mais pendant la nuit, le problème s'est résolu, après avoir passé le paramètre wal_sender_timeout à 0 sur le serveur primaire.
On a vu monter la volumétrie dans le répertoire pg_slot du serveur primaire, puis la réplication est repartie et tout le retard s'est rattrapé petit à petit.
En tout cas, merci pour l'aide.
Hors ligne
Ah oui, petite question supplémentaire : est-ce qu'on peut garder le paramètre wal_sender_timeout à 0 ?
Ou faut-il le ramener à une valeur fixe ?
Hors ligne
Pages : 1
