J'ai une (production) DB Server exécutant PostgreSQL v9.0 et une machine de développement exécutant PostgreSQL V8.4. Je voudrais prendre une vidage de la production de DB et l'utiliser sur la machine de développement. Je ne peux pas mettre à niveau les postgres sur la machine DEV.
sur la machine de production, je cours: p> sur la machine de développement, je cours: p> pg_restore: [archiver] unsupported version (1.12) in file header
5 Réponses :
pg_restore est uniquement pour restaurer des décharges prises dans le format "personnalisé". Si vous faites un "texte brut", vous devez utiliser PSQL pour exécuter le script SQL généré:
Utilisation de pg_dump / pg_restore Pour passer de 9.0 à 8.4 n'est pas pris en charge - seulement le déplacement de l'avant est pris en charge.
Cependant, vous pouvez généralement obtenir les données sur (dans une décharge uniquement des données) et, dans certains cas, vous pouvez obtenir le schéma - mais c'est la plupart de la chance, cela dépend des fonctionnalités que vous utilisez.
Vous devez normalement utiliser la version cible de pg_dump et pg_restore - ce qui signifie dans ce cas, vous devez utiliser les fichiers binaires de 8.4. Mais vous devez utiliser la version même de pg_dump et pg_restore. Les deux outils vont fonctionner correctement sur le réseau. Il ne devrait donc pas y avoir besoin de copier les fichiers binaires.
et comme A_HORSE_WITH_NO_NAME dit, vous pouvez être mieux en train d'utiliser PG_DUMP en mode PG_DUMP dans le mode texte - qui vous permettra de modifier la décharge si nécessaire. En particulier, vous pouvez établir un seul schéma uniquement (avec -s) et une seule DÉCUPATION - Seul le décharge de schéma ne nécessitera probablement aucune modification.
Bonne suggestion sur le schéma de dumping séparément des données. J'ai eu quelques erreurs à l'aide de la plaine_text, mais rien n'est irrécupérable. Je ne pouvais pas essayer d'utiliser pg_dump à partir de la machine DEV lorsque le serveur de production est configuré pour interdire les connexions distantes, mais cela semble également prometteur.
Vous pouvez l'utiliser à distance tant que vous avez la possibilité d'utiliser le transfert de port SSH (ou similaire).
Si la base de données 9.0 contient des colonnes BYTEA, les problèmes plus gros attendent.
Ces colonnes seront exportées par pg_dump à l'aide de la représentation "Hex" et apparaissent dans votre fichier de vidage comme:
Sélectionner pg_catalog.lowrite (0, '\ x0a2')
Toute version du backend Postgres ci-dessous 9.0 ne peut pas grok la représentation hexagonale de BYTEA, et je ne trouve pas une option pour dire pg_dump sur le côté 9.0 de ne pas l'utiliser. Réglage du paramètre par défaut "bytea_Output" pour s'échapper pour la base de données ou l'ensemble du serveur est apparemment ignoré par pg_dump.
Je suppose qu'il serait possible de post-traiter le fichier de vidage et de modifier réellement toutes les valeurs de byTea codées hexadécédées à une maladie évoquée, mais le risque de corrompre de manière non conditionne le genre de choses normalement stockées dans une bytea (images, PDFS, etc. ) Ne m'excite pas.
Au moins en 9.2.2 Les paramètres bytea_Output sont désormais obéis à pg_dump, donc le réglage de "Escape" effectuera une décharge compatible 8,4, au moins pour les champs BYTEA. Vous obtenez toujours des avertissements sur les procédures.
J'ai résolu ceci en mettant à niveau PostgreSQL de 8.x à 9.2.4. Si vous utilisez Brasserie sur Mac OS-X, utilisez -
export PATH=/usr/local/Cellar/postgresql/9.2.4/bin:$PATH
J'ai eu le même problème. J'ai utilisé pgdump et PSQL pour exporter / importer dB.
1.SET PGPassword P> 2. 2Xport dB avec pg_dump p> psql -h <<host>> -U <<username>> -d <<dbname>> -f /opt/db.out
Vous pourriez avoir les deux 8.4 et 9,0 en parallèle (c'est ce que je fais ce que je fais, cela fonctionne bien), de cette façon, vous pouvez conserver 8.4 pour des projets locaux qui en dépendent, mais ont pourtant 9,0 pour cette application qui utilise 9: sur le Longue course, il va payer mieux que d'essayer de restaurer une décharge d'une version différente.
Exportation et importation de PostGressQl avec PGADMIN III