Vous n'êtes pas identifié(e).
Bonjour,
j'ai un postgres "primaire" qui s'est répliqué correctement sur un postgres "standby" correctement jusqu'en janvier.
Puis désastre sur le site backup.
Le site backup est de nouveau en place, j'ai restauré la config et db au moment du crash sur le site backup et je re-lance la réplication.
le log (backup) dit:
2018-03-05 10:21:27 UTCLOG: entering standby mode
2018-03-05 10:21:27 UTCLOG: started streaming WAL from primary at 5/BE000000 on timeline 1
2018-03-05 10:21:27 UTCFATAL: could not receive data from WAL stream: ERROR: requested WAL segment 0000000100000005000000BE has already been removed
2018-03-05 10:21:28 UTCLOG: started streaming WAL from primary at 5/BE000000 on timeline 1
2018-03-05 10:21:28 UTCFATAL: could not receive data from WAL stream: ERROR: requested WAL segment 0000000100000005000000BE has already been removed
2018-03-05 10:21:33 UTCLOG: started streaming WAL from primary at 5/BE000000 on timeline 1
2018-03-05 10:21:33 UTCFATAL: could not receive data from WAL stream: ERROR: requested WAL segment 0000000100000005000000BE has already been removed
2018-03-05 10:21:38 UTCLOG: started streaming WAL from primary at 5/BE000000 on timeline 1
2018-03-05 10:21:38 UTCFATAL: could not receive data from WAL stream: ERROR: requested WAL segment 0000000100000005000000BE has already been removed
2018-03-05 10:21:43 UTCLOG: started streaming WAL from primary at 5/BE000000 on timeline 1
2018-03-05 10:21:43 UTCFATAL: could not receive data from WAL stream: ERROR: requested WAL segment 0000000100000005000000BE has already been removed
=> Le log est bien celui qui manque. J'ai effacé le dossier pg_xlog du standby et relancé , sans succès
Et il est toujours sur le site primaire, bien qu'il dise le contraire!!!!!:
-bash-4.2$ ls -altr 0000000100000005000000BE
-rw-------. 1 postgres postgres 16777216 Jan 15 11:18 0000000100000005000000BE
Question: pourquoi le primaire ne l'envoie-t'il pas??? (Ca me fait peur: en cas de coupure il doit quand même pouvoir repartir)
Hors ligne
Vous regardez dans quel répertoire ?
Guillaume.
Hors ligne
là où les wal sont archivés sur le primaire:
/var/lib/pgsql/9.6/wal
Hors ligne
Avez-vous configuré un restore_command pour aller récupérer les journaux de transaction à cet emplacement ? L'erreur indique qu'une connexion en streaming replication demande au serveur primaire de fournir le fichier, qui n'est plus disponible localement.
Julien.
https://rjuju.github.io/
Hors ligne
Non. C'est un postgres 9.6, je n'ai pas vu de restore_command dans le squelette du postgresql.conf. Il s'est répliqué jusqu'en janvier sans en avoir besoin.
Je viens d'adapter mon recovery.conf sur le standby, j'ai ajouté:
restore_command = 'cp /var/lib/pgsql/9.6/wal/%f %p'
archive_cleanup_command = 'pg_archivecleanup /var/lib/pgsql/9.6/wal %r'
Le message est un peu différent:
cp: cannot stat ‘/var/lib/pgsql/9.6/wal/0000000100000005000000BE’: No such file or directory
2018-03-05 13:10:35 UTCLOG: started streaming WAL from primary at 5/BE000000 on timeline 1
2018-03-05 13:10:35 UTCFATAL: could not receive data from WAL stream: ERROR: requested WAL segment 0000000100000005000000BE has already been removed
cp: cannot stat ‘/var/lib/pgsql/9.6/wal/0000000100000005000000BE’: No such file or directory=> Le fichier est bien à cet endroit sur le primaire. S'il doit être sur le standby ca veut dire que postgres ne peut récupérer les wal du primaire?????
Hors ligne
La commande est exécutée localement sur le serveur secondaire. Vous devez donc lui fournir une commande capable d'aller récupérer le fichier en question, un rsync par exemple si le serveur est accessible via ssh. N'oubliez pas l'échange de clef etc.
Julien.
https://rjuju.github.io/
Hors ligne
Ca veut dire qu'il faut copier les fichiers du primaire sur le standby manuellement.
Cela veut dire que dans un système primaire/stanbdy, si on coupe le standby (redémarrage, maintenance, ...), il faut le remettre à jour MANUELLEMENT en rapatriant les WAL. C'est une inepsie.
Pourquoi le standby ne sait-il pas récupérer ce qui lui manque en les demandant au primaire puisqu'ils sont sur le primaire?
Hors ligne
Ca veut dire qu'il faut copier les fichiers du primaire sur le standby manuellement.
Cela veut dire que dans un système primaire/stanbdy, si on coupe le standby (redémarrage, maintenance, ...), il faut le remettre à jour MANUELLEMENT en rapatriant les WAL. C'est une inepsie.
Non, cela signifie qu'il faut dire au serveur secondaire comment les récupérer.
Pourquoi le standby ne sait-il pas récupérer ce qui lui manque en les demandant au primaire puisqu'ils sont sur le primaire?
Parce qu'il n'y a aucune garantie que le primaire dispose des fichiers localement, ce n'est pas parce que c'est ce que *vous* faites que cela doit toujours être le cas.
Au passage, archiver les WAL en local est très certainement une mauvaise idée. Si vous coupez le secondaire pour une maintenant et que vous perdez le serveur primaire au même moment, les journaux qui ont été archivés sont perdus.
Julien.
https://rjuju.github.io/
Hors ligne
"Non, cela signifie qu'il faut dire au serveur secondaire comment les récupérer."
C'est bien là le souci: Comment?
Je veux que mon serveur secondaire demande les WAL au primaire (et ils y sont toujours), sans devoir les rapatrier manuellement.
Hors ligne
Comme expliqué juste avant, il faut configurer une commande pour archive_commande capable de récupérer les données sur le serveur distant.
Julien.
https://rjuju.github.io/
Hors ligne
archive_command archive les fichiers sur le PRIMAIRE, et est configuré. Cette commane ne fait rien sur un noeud en rôle standby.
Cette commande est bien configurée et les WAL sont bien là sur le primaire.
Le standby a été coupé donc n'a pas reçu les WAL.
Je repose la question: que dois-je dire au standby ou au primaire pour qu'il expédie les wal du primaire au standby?
Hors ligne
Pardon, je voulais dire restore_command.
Julien.
https://rjuju.github.io/
Hors ligne
En fait l'erreur est sur le primaire!
Le log du primaire montre:
2018-03-05 10:14:32 UTCERROR: requested WAL segment 0000000100000005000000BE has already been removed => le primaire a bien reçu la requête.
MAIS une fois que le log n'est plus dans pg_xlog, postgres ne sait plus le renvoyer, vu qu'archive_command n'est pas analysé. A moins qu'il y ait un paramètre "archive_directory" quelque part????
Hors ligne
restore_command cherche les fichiers sur le standby, pas sur le primaire!!!!!! cfr message plus haut!!!!
Hors ligne
Déjà, merci de rester calme. Julien ne cherche qu'à vous aider.
Pour votre commande, veuillez voir du côté des commandes scp ou rsync pour faire une copie réseau. Cette commande doit être indiqué dans le paramètre restore_command du fichier recovery.conf.
Guillaume.
Hors ligne
Il n'y a pas d'archive_directory ou similaire car dans la majorité des cas les journaux ne sont pas disponibles en local. Il n'est d'aucune utilité de demander à un serveur primaire d'aller récupérer les journaux lui-même, car cela ne marcherait que dans le cas où le primaire est toujours disponible. Si les journaux archivés sont disponibles mais que le primaire ne l'est plus, il faudrait configurer une autre méthode de récupération. Donc, on utilise une méthode qui ne dépend pas de la disponibilité du serveur primaire. Si vous tenez vraiment à avoir une méthode qui dépend de la disponibilité du primaire, utilisez des slots de réplication afin de conserver dans pg_xlog tous les journaux non répliqués.
restore_command est exécuté sur le standby, et si restore_command est configuré pour utiliser rsync pour se connecter sur le serveur distant le serveur standby utilisera rsync pour récupérer les fichiers sur le serveur primaire.
Julien.
https://rjuju.github.io/
Hors ligne
