requested WAL segment 0000000100000005000000BE has already been remove

albourg · 05/03/2018 12:34:03

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)

gleu · 05/03/2018 13:07:01

Vous regardez dans quel répertoire ?

albourg · 05/03/2018 14:21:45

là où les wal sont archivés sur le primaire:
/var/lib/pgsql/9.6/wal

rjuju · 05/03/2018 14:47:24

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.

albourg · 05/03/2018 15:13:03

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?????

rjuju · 05/03/2018 15:34:26

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.

albourg · 05/03/2018 15:38:01

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?

rjuju · 05/03/2018 15:44:53

albourg a écrit :

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.

albourg · 05/03/2018 15:51:36

"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.

rjuju · 05/03/2018 15:53:33

Comme expliqué juste avant, il faut configurer une commande pour archive_commande capable de récupérer les données sur le serveur distant.

albourg · 05/03/2018 16:07:25

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?

rjuju · 05/03/2018 16:08:20

Pardon, je voulais dire restore_command.

albourg · 05/03/2018 16:17:00

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????

albourg · 05/03/2018 16:19:45

restore_command cherche les fichiers sur le standby, pas sur le primaire!!!!!! cfr message plus haut!!!!

gleu · 05/03/2018 16:25:47

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.

rjuju · 05/03/2018 16:26:25

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.

#1 05/03/2018 12:34:03

requested WAL segment 0000000100000005000000BE has already been remove

#2 05/03/2018 13:07:01

Re : requested WAL segment 0000000100000005000000BE has already been remove

#3 05/03/2018 14:21:45

Re : requested WAL segment 0000000100000005000000BE has already been remove

#4 05/03/2018 14:47:24

Re : requested WAL segment 0000000100000005000000BE has already been remove

#5 05/03/2018 15:13:03

Re : requested WAL segment 0000000100000005000000BE has already been remove

#6 05/03/2018 15:34:26

Re : requested WAL segment 0000000100000005000000BE has already been remove

#7 05/03/2018 15:38:01

Re : requested WAL segment 0000000100000005000000BE has already been remove

#8 05/03/2018 15:44:53

Re : requested WAL segment 0000000100000005000000BE has already been remove

#9 05/03/2018 15:51:36

Re : requested WAL segment 0000000100000005000000BE has already been remove

#10 05/03/2018 15:53:33

Re : requested WAL segment 0000000100000005000000BE has already been remove

#11 05/03/2018 16:07:25

Re : requested WAL segment 0000000100000005000000BE has already been remove

#12 05/03/2018 16:08:20

Re : requested WAL segment 0000000100000005000000BE has already been remove

#13 05/03/2018 16:17:00

Re : requested WAL segment 0000000100000005000000BE has already been remove

#14 05/03/2018 16:19:45

Re : requested WAL segment 0000000100000005000000BE has already been remove

#15 05/03/2018 16:25:47

Re : requested WAL segment 0000000100000005000000BE has already been remove

#16 05/03/2018 16:26:25

Re : requested WAL segment 0000000100000005000000BE has already been remove

Pied de page des forums

PostgreSQL.fr

À propos

Nous contacter

Groupes Locaux

Réseaux Sociaux