Vous n'êtes pas identifié(e).
Pages : 1
Bien sur c'est pas idéal comme arrivée sur un forum, je sais, mais bon...
Je suis assez nouveau sur PostGreSQL , je viens de l'adopter en passant sur Django pour le developpement web
Lors de la migration d'un schéma de données vers un autre sur un site fraichement lancé, piloté par une application sous django (south), j'ai fait une grosse betise , un return de trop
et non, pas de sauvegarde.....débile total, je suis d'accord à 100%
je viens de stopper le serveur PGSQL, commencé à chercher fébrilement sur Google, et suis carrément perdu
j'ai compressé les dossiers base, pg_xlog et pg_clog parceque apparemment c'est par là que ça se passe, mais ensuite ?
Pour être plus précis sur ce que j'ai fait : effacement d'une douzaine de colonnes sur une table.
Ça a supprimé les données correspondantes sur 2000+ lignes. la table est toujours en place
Auriez-vous des experiences identiques, des pointeurs, ou des spécialistes prêts à m'aider
éventuellement contre rémunération, au point ou j'en suis, je vais avoir des problemes si je ne remet pas ces données en place
merci d'avance
Dernière modification par quinode (23/02/2011 21:25:02)
Hors ligne
Une suppression de colonne (ALTER TABLE...DROP COLUMN...) demande la réécriture de la table. Ce n'est pas du tout comme la mise à jour (UPDATE) ou la suppression (DELETE) d'une ligne qui n'est, après tout, que l'ajout d'une information comme quoi la ligne est supprimée. Bref, dans votre cas, la table est réécrite. Autrement dit, vous ne retrouverez pas les données dans le fichier de la table. Les données sont peut-être encore disponibles dans les journaux de transactions mais 1. il y a de fortes chances que tout n'y soit pas, 2. ça demanderait tellement de boulot de tenter une récupération que ça n'en vaudrait pas le coup financièrement.
Pour la faire courte, laissez tomber, c'est mort.
Guillaume.
Hors ligne
merci pour votre réponse
Les données sont peut-être encore disponibles dans les journaux de transactions mais 1. il y a de fortes chances que tout n'y soit pas, 2. ça demanderait tellement de boulot de tenter une récupération que ça n'en vaudrait pas le coup financièrement.
Tout doit y être, les fichiers archivés dans pg_xlog datent de l'heure de l'effacement (19:00) et l'un deux à l'air encore plus ancien (17:00)
le truc maintenant, c'est peut-on lire /extraire de ces fichiers des requêtes SQL ?
si j'arrive à ouvrir ces fichiers de cette manière, je pourrais retrouver mes petits
Hors ligne
Vous n'y trouverez pas de requêtes SQL. C'est seulement des blocs de données à coller dans tel ou tel fichier, voire des morceaux de blocs. Je ne peux pas vous empêcher de tenter mais ne vous faites aucun espoir.
Guillaume.
Hors ligne
Je suis en train d'essayer d'installer cet outil :
http://xlogviewer.projects.postgresql.org/
qui devrait pouvoir me ressortir des requetes SQL à partir des xlog
Mais je galère sur le Makefile qui veut pas se lancer...
Hors ligne
Je documente ma galère :
après un
apt-get install libreadline6-dev
j'ai pu suivre les instructions du site et installer l'outil
A première vue , ça marche pas sur les fichiers, mais je viens de tomber sur cette note :
"In this initial version you need a database connection is needed to decode the data contained int the transactions logs, but the next release will read the database files directly."`
Ce qui veut dire que je dois relancer mon serveur pour utiliser cet outil.
Ma question est : si je relance mon serveur, est-ce qu'il va "purger" les fichiers xlog ou autres , ou est-ce que je peux faire ça sereinement (il n'y a personne d'autres sur le serveur, le site est coupé du coup)
Hors ligne
Je ne voudrais pas sembler pessimiste pour la troisième fois mais ce n'est pas possible. Y compris ce projet, connu depuis un bon moment pour être abandonné, ne changera rien à la situation. D'après un rapide coup d'œil au CVS, xlogdump n'a pas changé depuis deux ans et xlogviewer n'a pas changé depuis quatre ans. Inutile de vous dire que le format des journaux de transactions a énormément changé depuis. Donc, à moins d'utiliser une version 8.2 ou antérieure, de toute façon, cet outil ne comprendra rien au format du journal de transaction de versions plus récentes. Donc il n'y a pas que le Makefile qui posera problème. Le code lui-même devra être revu. Et de toute façon, le gars lui-même indique que l'option qui permet de créer les fausses instructions SQL est en version très très alpha.
Guillaume.
Hors ligne
Si vous relancez PostgreSQL, ce dernier peut très bien décider de recycler les journaux de transactions, y compris sans activité autre.
Guillaume.
Hors ligne
Alors, effectivement, en relançant le serveur, PG a effacé un des trois segments (le plus vieux) et en a recréé un.
Mais de toute façon, xlogdump , que ce soit en mode fichjier ou en mode "host", a buté sur les mêmes erreurs, comme vous disiez par email, le format des logs binaires a du évoluer depuis deux ans. N'empêche qu'un outil comme ça serait utile !!
J'ai réussi à reconstituer à peu près toutes les données du client en croisant une ancienne sauvegarde + un log utilisateur sur l'application qui notait quand meme les PKID... c'est pas la cata totale. Juste 24h de fou...
Merci gleu en tout cas, et à bientot avec des questions moins stress!
Hors ligne
De rien. Bien content que vous ayez pu rétablir la situation au mieux (au mieux étant donné le contexte). Mais bon, votre boulot immédiat, c'est de mettre en place la sauvegarde. Aucune dérogation possible.
Guillaume.
Hors ligne
C'est bizarre, mon client m'a dit la même chose... (ok j'arrete)
par contre : j'ai déjà fait de la replication sous MySQL,
sous PostGreSQL j'avais l'impression que ce genre de backup (streaming) c'était plus simple depuis la version 9 : c'est le cas ?
Hors ligne
Oui, c'est le cas. Mais la réplication, ce n'est pas de la sauvegarde.
Guillaume.
Hors ligne
Pages : 1
