Vous n'êtes pas identifié(e).
Bonjour,
Je suis actuellement en train d'installer un serveur de backup en version PGSQL 14.1.
Le but est d'avoir deux noeux de BDD . Un noeud master et un noeud backup en mode "hot standby"
Le serveur master est Up & running mais je ne parviens pas à créer la BDD sur le serveur de backup à partir du serveur master via la commande pg_basebackup.
Après lancement de la commande sur le serveur backup:
pg_basebackup -h <serveur master> -U replication -D /<chemin d'install>/postgres/data/14_1/db -P --write-recovery-conf --wal-method=fetch --waldir=/<chemin d'install>/postgres/backup/14_1/current_xlogLe PGSQL du serveur de backup ne démarre pas.
J'ai consulté les logs d'erreur PGSQL du serveur de master et a trouvé l'erreur :
ERROR: could not open file "pg_wal/00000003.history": No such file or directoryJe me suis alors connecté à la BDD du serveur de master et j'ai lancé :
select pg_current_wal_lsn();J'ai ensuite copié le résultat sur le serveur de backup dans un fichier /<chemin d'install>/backup/14_1/current_xlog/00000003.history
J'ai ensuite relancé la commande pg_basebackup sur le serveur de backup :
pg_basebackup -h <serveur master> -U replication -D /<chemin d'install>/postgres/data/14_1/db -P --write-recovery-conf --wal-method=fetch --waldir=/<chemin d'install>/postgres/backup/14_1/current_xloget obtiens l'output suivant :
pg_basebackup: error: could not get COPY data stream: FATAL: syntax error in history file: 171/C1000078
HINT: Expected a write-ahead log switchpoint location.
pg_basebackup: removing contents of data directory "/<chemin d'install>/data/14_1/db"
pg_basebackup: removing contents of WAL directory "/<chemin d'install>/backup/14_1/current_xlog"Pour information, j'ai testé en alimentant le contenu du fichier du serveur de backup /<chemin d'install>/backup/14_1/current_xlog/00000003.history de 2 manières différentes :
1) Avec le résultat de la commande : select pg_current_wal_lsn() du serveur master
2) Et celui de : SELECT pg_switch_wal(); du serveur master
Merci d'avance pour vos retours.
Cordialement.
Dernière modification par Imagin0s (23/03/2023 10:27:42)
Hors ligne
Bonjour,
Tout d'abord, essayer de générer des fichiers avec du contenu aléatoire n'est JAMAIS une bonne idée. Il manque beaucoup d'information pour pouvoir vous aider, mais je pense que l'erreur "ERROR: could not open file "pg_wal/00000003.history": No such file or directory" est normale et correspond à une demande du réplica qui essaye de récupérer tous les fichiers possible via la réplication. Il faudrait préciser dans les logs de quelle instance ce message a été emit, ainsi que toutes les autres erreurs du côté du standby.
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour,
Désolé si je n'ai pas été assez précis au niveau du renseignement des serveurs sur lesquels j'ai lancé mes commandes et consulté mes logs. J'ai modifié mon 1er message en y ajoutant plus de détails.
Je remarque que les erreurs ont été tracées dans les logs du serveur master (pas de traces ds les logs du serveur de backup)
L'erreur est la suivante :
2023-03-23 09:25:36.498 CET,"replication","",609470,"<IP>:46332",641c0ce4.94cbe,69,"sending backup ""pg_basebackup base backup""",2023-03-23 09:25:08 CET,34/0,0,FATAL,XX000,"syntax error in history file: 171/C1000078Pour information, je n'ai pas vraiment généré le contenu fichier 00000003.history de manière aléatoire, j'ai suivi la procédure décrite ici https://superuser.com/questions/1127360 … on-working (en adaptant une commande de la version 9.6 en version 14). Cette technique de résolution avait marché plusieurs fois sur une autre installation PGSQL en version 9.6.
Je reste à votre disposition pour toute question/remarque et vous remercie d'avance pour vos retours.
Dernière modification par Imagin0s (23/03/2023 10:37:35)
Hors ligne
J'ai du mal à croire que le lien en question ait jamais pu fonctionner, les fichiers .history ayant plus d'information qu'un simple LSN. De plus, même si le fichier était syntaxiquement correct je pense que la seule chose que vous pourriez faire serait potentiellement corrompre votre replica.
Julien.
https://rjuju.github.io/
Hors ligne
Ok, mais que me conseillez vous ?
Il y a-t-il une documentation pour gérer le contenu de ce fichier .history en version 14 ?
Hors ligne
Si le contenu de ce fichier pouvait être facilement regénéré après coup il n'y aurait pas besoin de ce fichier.
Mais plus globalement, je ne sais pas pourquoi vous voyez cette erreur ni même si elle a un rapport avec vos actions. Vous devez investiguer pour comprendre pourquoi le fichier est demandé, qui le demande, si c'est normal et vous pourrez alors résoudre (ou pas) le problème. Mais comme indiqué précédemment c'est impossible à dire avec les informations que vous avez fournies.
Julien.
https://rjuju.github.io/
Hors ligne