Vous n'êtes pas identifié(e).
Bonjour
Pendant les 36 dernières heures, je n'ai pas réussi à résoudre le problème suivant
comment faire coïncider les répertoires contenant les fichiers de données avec le répertoire renseigné dans le catalogue postgres sous linux
Bien que Postgres soit correctement lancé, je ne parviens pas à établir une connexion. Peu importe les commandes que j'exécute, je reçois systématiquement le même message d'erreur.
warning: extra command-line argument "psql" ignored
psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: No such file or directory
Is the server running locally and accepting connections on that socket?
Le serveur fonctionne correctement, le chemin du socket est correct, les permissions du répertoire sont appropriées, et le serveur utilise le port correct (qui est correctement défini par défaut).
Avez-vous une suggestion quant à la nature du problème ?
Merci par avance de votre aide
Hors ligne
Peu importe les commandes que j'exécute, je reçois systématiquement le même message d'erreur.
warning: extra command-line argument "psql" ignored
Quelle(s) commande(s) avec vous lancé ?
Le serveur fonctionne correctement, le chemin du socket est correct, les permissions du répertoire sont appropriées, et le serveur utilise le port correct (qui est correctement défini par défaut).
Comment vérifiez-vous que le serveur fonctionne et que le reste des informations est correct ?
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour rjuju
Le problème réside dans la corruption de la base de données (service + annuaire + bases), répartie sur plusieurs disques, due à la restauration d'un seul de ces disques. À ce stade, soit une commande existe capable de scanner une base pour reconstruire l'annuaire désynchronisé, soit elle n'existe pas.
Les seules commandes "limite" qui semblent avoir le potentiel de restaurer partiellement une base corrompue sont celles testées en dernier recours par mon collègue, notamment la pg_resetwal.
Le dernier essai consistait à reproduire la restauration partielle effectuée par ma collègue sur une machine Windows. Nous avons recréé une base TEST identique avec les mêmes paramètres, utilisateur, schéma, droits et tablespace (fichier physique dédié). Après avoir confirmé que cette base fonctionnait correctement, nous avons remplacé ses fichiers par ceux de nos sauvegardes, mais cela n'a rien changé.
Même après l'exécution de pg_resetwal, aucune amélioration n'a été constatée. Nos sauvegardes se comportent un peu comme des puzzles de 100 000 pièces que nous pouvons assembler facilement grâce aux numéros de référence, sauf que nous possédons les pièces (la sauvegarde) sans les numéros (les annuaires stockés sur la partition restaurée).
Après une lecture approfondie de nombreuses documentations, aucune commande n'a été trouvée pour dire à Postgres d'oublier son annuaire, de scanner les 100 000 pièces et de reconstruire son annuaire.
Il est possible qu'une commande adaptée existe ou qu'une solution tierce puisse résoudre ce problème spécifique, mais jusqu'à présent, nos recherches n'ont rien donné malgré nos nombreux essais, tels que start/stop, redirection des tablespaces, copie de fichiers sauvegardés entre anciennes et nouvelles bases, depuis Ubuntu ou Windows, avec les mêmes utilisateurs, différents utilisateurs, avec ou sans resetwal.
En résumé, nous cherchons une commande ou un outil capable de reconstruire un pgdata complet à partir du dossier d'une base de données "brute".
Hors ligne
Bonjour,
oulala ! beaucoup d'information à droite et à gauche.
déjà on ne peut pas restaurer un PGDATA linux sur une machine windows.
comment avez vous sauvegarder votre instance linux avant d'avoir le problème de disque ?
Le principe de la sauvegarde physique c'est que vous ne pouvez pas restaurer qu'une partie seulement des fichiers car les autres fichiers seront en décallage.
En fait nos réponses dépendront de la manière dont vous avez sauvegarder votre instance avant le problème.
est-ce que vous êtes en mode archive_mode=on ?
avez vous au pire une sauvegarde logique (type pg_dump) ?
et surtout avez des traces du moteur postgres lorsque vous tenter de redémarrer l'instance ?
Cordialement,
Sébastien.
Hors ligne
et par défaut le PGDATA est situé à un seul endroit.
Si ce que vous semblez dire est exact, vous avez éclaté vos fichiers sur plusieurs disques distincts, donc vous devez avoir utilisé des tablespaces ?
exact ?
Dernière modification par ruizsebastien (22/12/2023 11:15:50)
Cordialement,
Sébastien.
Hors ligne
on ne peut pas restaurer un PGDATA linux sur une machine windows
---> on a tenté, effectivement la base est inconsistante
Avez vous au pire une sauvegarde logique (type pg_dump) ?
---> non
comment avez vous sauvegarder votre instance linux avant d'avoir le problème de disque ?
snapshot ovh
Hors ligne
Bonjour ruizsebastien
pgdata linux sur windows : on a essayé quand meme (et ça marchotte)
- on a rien sauvegardé, on a juste la partition d'origine avec les tablesspaces intacte
- save physique qu'on peut pas restaurer par morceaux : c'est ce qu'on essaye pourtant de faire
- archive_mode => off
- pas de dump pg_dump
Hors ligne
donc vous avez perdu un disque que vous avez remplacé.
Pourquoi ne pas appliquer le snapshot ovh "en entier" ce qui permettrait d'avoir tous les fichiers qui seraient remis aux bons endroits par l'application du snapshot ?
et ensuite relancer l'instance (restart pour être sûr)
Cordialement,
Sébastien.
Hors ligne
le problème est que snapshot entier date du 27 novembre et pas pas du 19/12
Hors ligne
malheureusement je ne vois pas d'autres alternatives.
pas de sauvegardes, pas de restaurations.
Cordialement,
Sébastien.
Hors ligne
malheureusement la sauvegarde est corrompue, je suis vraiment dans catastrophe. Je dois rétablir ma base client.
Hors ligne
