Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
J'ai un soucis avec la restauration de fichiers via pg_restore.
Afin de procéder à une synchronisation manuelle entre 2 bases situées sur des serveurs différents, je procède effectivement à :
- une sauvegarde des tables via pg_dump depuis la base source
- un "vidage" des données des tables sur la base destination (DELETE FROM matable)
- une restauration via pg_restore sur la base destination
Voici le type de scripts utilisés :
- sauvegarde :
C:\PostgreSQL\9.0\bin\pg_dump.exe --host %nom_serveur% --port 5432 --username postgres -t matable--inserts --file "%rep_save%matable.backup" mabase
-restauration :
C:\PostgreSQL\9.0\bin\pg_restore.exe --host %nom_serveur% --port 5432 --username postgres -t matable --data-only --file "%rep_save%matable.backup" mabase
Quand je regarde le contenu des fichiers créés via "pg_dump", ils semblent contenir la structure et les données, malgré l'usage de "--inserts".
Mais je n'arrive pas à restaurer les données. Je n'obtiens pas de message d'erreur dans mon script, mais les tables restent vides après son passage...
Une idée?
Dernière modification par Gold.Strike (25/01/2011 19:44:31)
Hors ligne
--inserts est une très mauvaise idée. C'est très lent à restaurer.
Ce que vous cherchez c'est --data-only.
Marc.
Hors ligne
Donc d'accord j'utilise "--data-only" pour ma requête de sauvegarde?
Mais pour la requête de restauration, quelqu'un pourrait m'aider à trouver la syntaxe exacte?
Hors ligne
ça va vous générer un script SQL.
Vous n'avez qu'à le faire exécuter par psql:
«\i mon_script» par exemple
Marc.
Hors ligne
Je ne suis pas sur de comprendre...
En fait je sauvegarde mes X fichiers via un batch contenant X lignes de "pg_dump" avec l'option "--data-only" :
C:\PostgreSQL\9.0\bin\pg_dump.exe --host %nom_serveur% --port 5432 --username postgres -t matable --data-only--file "%rep_save%matable.backup" mabase
Je voudrais donc pouvoir en faire de même avec un script de restauration, mais j'ai visiblement un soucis avec la syntaxe lors de l'exécution de :
C:\PostgreSQL\9.0\bin\pg_restore.exe --host %nom_serveur% --port 5432 --username postgres -t matable --data-only --file "%rep_save%matable.backup" mabase
Mais lorsque j'execute le script j'obtiens un message d'erreur :
pg_restore: [archiveur] n'a pas pu ouvrir le fichier en entrée « mabase » : No such file or directory
Aurais tu une idée?
Avec psql, il n'y a pas moyen de faire de script comme je veux le faire si?
Désolé encore si tu te répètes, mais je ne comprends pas...
Hors ligne
pg_dump, par défaut, génère un script SQL. Pas un fichier compatible avec pg_restore. Pour avoir un format compatible avec pg_restore, il faut rajouter l'option '-Fc' à pg_dump. Mais vu ce qui est demandé, le format SQL simple est suffisant.
Étant donné qu'il génère un script SQL, il suffit d'un interpréteur SQL pour l'exécuter. Donc psql.
«psql -U postgres ma_base -f mon_script_sql»
Marc.
Hors ligne
Oui mais le problème la, c'est que je génère 30 scripts comme il y a 30 fichiers à traiter.
Donc je suis obligé de taper 30 fois ta commande via psql, ce qui n'est pas pratique.
Hors ligne
Parce que tu n'as pas 30 commandes pg_dump à taper avant ? Moi on me pose la question pour une table, je réponds pour une table 
Bon plus sérieusement, vu que la question commence à dévier, si on reprenait tout à zéro ?
Que veux-tu faire exactement ? Restaurer toute la base après avoir purgé les tables qui étaient dedans avec le même nom ? Ou sélectionner une liste de tables ? Si il y a une liste, tu préfères la donner au moment de la sauvegarde ou de la restauration ?
Parce que pg_dump et pg_restore sont assez puissants de ce côté là. Mais encore faut il que je sache ce que tu veux vraiment faire.
Marc.
Hors ligne
Pourquoi ne peux-tu pas (ou ne veux-tu pas?) faire un script qui appelle psql en boucle, suivant la syntaxe donnée par Marc, comme tu as fait sans doute pour pg_dump?
Ou alors explique mieux ton problème?
Hors ligne
Alors, résumons!
Donc, j'héberge une base "maitre" sur un serveur. Via un script utilisant "pg_dump", je fais un backup quotidien de ma base sur le serveur.
Ensuite, j'ai différents clients, qui ont une base "client" hébergée sur mon serveur, ou sur un serveur à eux.
Lors de l'installation d'un client, je fais simplement un restore du dernier backup de ma base "maitre".
Nous développons actuellement un outil de synchronisation entre la base "maitre" et les bases des clients. Cette syncrhonisation récupère uniquement des données de la base "maitre", mais aucune données de la base client. En attendant que cette synchronisation soit développée, on effectue une synchronisation "manuelle", sachant que les tables étant mises à jour chez nous ne sont pas mises à jour chez le client. Par contre, d'autres tables de la base sont bien mises à jour chez le client. Ainsi, je ne peux pas utiliser un dump de la base en entier pour mettre à jour la base du client.
Comme j'utilisais déja un script pour le backup quotidien de ma base, je me suis dit qu'un script était la solution la plus adaptée à la synchronisation manuelle.
C'est pourquoi je voulais procèder de la sorte :
- sauvegarde des données des tables de la base "maitre" à mettre à jour chez le client
- suppression des données de ces tables chez le client
- restauration des données des tables de la base "maitre" sauvegardées précédemment chez le client
Pour répondre à Marc :
- vu que je passe par un script, je n'ai pas à taper 30 fois la commande "pg_dump" dans psql, mais juste à exécuter mon batch!
- il y a donc bien une liste de 30 tables, après je pense qu'il est plus "logique" de la donner au moment de la sauvegarde des données.
Merci,
Dernière modification par Gold.Strike (26/01/2011 12:54:54)
Hors ligne
- vu que je passe par un script, je n'ai pas à taper 30 fois la commande "pg_dump" dans psql, mais juste à exécuter mon batch!
=> Donc pas plus à taper psql 30 fois. Il suffit de l'appeler 30 fois avec les 30 fichiers générés.
Sinon, si c'est au moment de la sauvegarde, il est possible de faire ceci :
pg_dump -t table1 -t table2 -t table3 …
Ça générera un seul script, avec l'ensemble de toutes les tables, d'un coup.
Par ailleurs, si il y a la liste des tables en paramètre du script, rien n'empêchait de lancer dans le script psql de façon automatisée une trentaine de fois…
Marc.
Hors ligne
J'ai donc maintenant un seul script en sortie de "pg_dump" : save.sql
Mais je ne vois toujours pas comment restaurer ce script sur la base destination?
Quand j'arrive dans la conseole de psql, comment puis je spécifier le chemin du fichier save.sql???
Hors ligne
Soit vous le passez en ligne de commande à psql, avec l'option -f. Dans ce cas le script sera déroulé automatiquement, et psql se fermera à la fin de l'exécution du script.
Soit dans psql, vous faites «\i save.sql»
Marc.
Hors ligne
Je n'y arrive pas :-(
Voici la commande que je tape :
c:\PTRS_BDD\synchromanuelle\2011-1-26>C:\APPLI_BDD\PostgreSql\bin\psql.exe -U postgres base_test -f synchro.backup
Mais ca retourne une erreur:
psql: warning: extra command-line argument "-f" ignored
psql: warning: extra command-line argument "synchro.backup" ignored psql (8.4.4)
WARNING: Console code page (850) differs from Windows code page (1252)
8-bit characters might not work correctly. See psql reference
page "Notes for Windows users" for details.
Type "help" for help.
Hors ligne
Le nom de la base doit être le dernier paramètre. Mettez le -f avant synchro.backup avant …
Marc.
Hors ligne
Effectivement, ca a l'air de marcher, merci à toi!
Les séquences sont mêmes mises à jour, alors que j'étais obligé de les remettre manuellement quand je faisais une synchronisation "artisanale".
Merci encore, a bientot!
Hors ligne
Bonjour,
je rebondis sur le billet de Gold.Strike pour poser une question sur les synchros.
dans le schema d'une même base stockée sur plusieurs serveurs (chaque base etant herbergée par le client lui meme)
quelle sont les outils disponibles afin de synchroniser UNIQUEMENT les structures à partir d'une base maître ?
merci
Hors ligne
Pour la synchro uniquement des structures, à part pg_dump -s, je ne vois pas bien. Il n'y a pas de trigger sur les alter table, donc pas moyen de tracer ça pour le moment dans la base.
Marc.
Hors ligne
Pages : 1
