Copie de la base de données PostgreSQL sur un autre serveur


492

Je cherche à copier une base de données PostgreSQL de production sur un serveur de développement. Quelle est la manière la plus rapide et la plus simple de procéder?

Réponses:


668

Vous n'avez pas besoin de créer un fichier intermédiaire. Tu peux faire

pg_dump -C -h localhost -U localuser dbname | psql -h remotehost -U remoteuser dbname

ou

pg_dump -C -h remotehost -U remoteuser dbname | psql -h localhost -U localuser dbname

en utilisant psqlou pg_dumppour vous connecter à un hôte distant.

Avec une grande base de données ou une connexion lente, le vidage d'un fichier et le transfert du fichier compressé peuvent être plus rapides.

Comme Kornel l'a dit, il n'est pas nécessaire de vider dans un fichier intermédiaire, si vous voulez travailler compressé, vous pouvez utiliser un tunnel compressé

pg_dump -C dbname | bzip2 | ssh  remoteuser@remotehost "bunzip2 | psql dbname"

ou

pg_dump -C dbname | ssh -C remoteuser@remotehost "psql dbname"

mais cette solution nécessite également d'obtenir une session aux deux extrémités.

Remarque: pg_dump sert à la sauvegarde et psqlà la restauration. Ainsi, la première commande de cette réponse consiste à copier du local vers le distant et la seconde de la distance vers le local . Plus -> https://www.postgresql.org/docs/9.6/app-pgdump.html


28
Il n'y a pas besoin de fichiers intermédiaires - vous pouvez utiliser un tunnel SSH compressé ou simplement un tuyau: pg_dump | bzip2 | ssh "bunzip2 | pg_restore"
Kornel

4
Si vous utilisez bzip2, désactivez la compression ssh pour accélérer le transfert!
lzap

8
Comment puis-je travailler compressé si je transfère des données de la production vers le développement? J'ai mis en place une connexion SSH du développement à la production. Le serait-il ssh remoteuser@remotehost "pg_dump -C dbname | bzip2" | bunzip2 | psql dbname?
Jeromy French

2
Je m'attendrais à ce que vous puissiez copier une base de données distante avec le nom x dans une base de données locale avec le nom y, mais la solution de @ Ferran ne fonctionne pas pour cela ... Il me semble que la solution de porneL laisse juste les fichiers bzip2 sur le serveur, ce n'est donc pas un processus en une seule étape. Cela étant le cas, je suppose que je vais supprimer la base de données y, utiliser la partie "ou" de la solution de Ferran qui restaure x, puis renommer la base de données en y.
Darin Peterson

3
Voici ce que j'ai fait: (1) pg_dump -C -h remotehost -U remoteuser x | psql -h localhost -U localuser (2) dropdb y (3) psql -U postgres -c 'ALTER DATABASE "x" RENAME TO "y"'
Darin Peterson

131
pg_dump the_db_name > the_backup.sql

Copiez ensuite la sauvegarde sur votre serveur de développement, restaurez avec:

psql the_new_dev_db < the_backup.sql

3
Quelqu'un m'a dit que cela peut être problématique - des problèmes d'autorisations provoquant la mort du vidage ou de la restauration lorsqu'il atteint un déclencheur?
Robin Barnes

17
@rmbarnes: S'il y a des problèmes - ils doivent être corrigés. Sans une connaissance détaillée de ce qu'a fait ce "Quelqu'un" - personne ne peut confirmer ou rejeter cette affirmation.

4
Utilisez l'indicateur --no-owner avec pg_dump. Cela saute le problème et la première édition de ce post l'a utilisé - mais j'ai pensé que vous pourriez avoir besoin d'une fidélité plus précise à la base de données d'origine.
démonté

4
Pour moi, l'approche ci-dessus a fonctionné de la manière suivante: pg_dump -C -h host -U username db_name> / any_directory / dump_schema_and_data_file .Et pour la restauration à partir du fichier: psql -h host -U username db_name <dump_schema_and_data_file
Ali Raza Bhayani

Cela m'a sauvé BEAUCOUP d'aggravation. J'ai utilisé Google Drive pour déplacer le fichier entre les machines. Comme j'avais déjà la base de données sur la nouvelle machine (mais vierge), j'ai eu BEAUCOUP d'erreurs de clé en double. Cependant, c'est un environnement de développement et ils n'ont rien fait de mal.
Chris Mendla

37

Utilisez pg_dump et plus tard psql ou pg_restore - selon que vous choisissez les options -Fp ou -Fc pour pg_dump.

Exemple d'utilisation:

ssh production
pg_dump -C -Fp -f dump.sql -U postgres some_database_name
scp dump.sql development:
rm dump.sql
ssh development
psql -U postgres -f dump.sql

22

Si vous cherchez à migrer entre les versions (par exemple, vous avez mis à jour postgres et que 9.1 s'exécute sur localhost: 5432 et 9.3 s'exécute sur localhost: 5434), vous pouvez exécuter:

pg_dumpall -p 5432 -U myuser91 | psql -U myuser94 -d postgres -p 5434

Consultez les documents de migration .


On me demande plusieurs fois le mot de passe (myuser91 / postgres). Existe-t-il un moyen de ne saisir le mot de passe qu'une seule fois?
Martin Weber

@MartinWeber Créez un fichier pgpass selon ce document postgresql.org/docs/9.4/static/libpq-pgpass.html
Scott Warren

que faire s'ils ont les deux mêmes ports?
ggnoredo

S'ils se trouvent sur des serveurs différents, vous pouvez utiliser -h pour spécifier les hôtes.
Haroldo_OK

16

pg_basebackup semble être la meilleure façon de le faire maintenant, en particulier pour les grandes bases de données.

Vous pouvez copier une base de données à partir d'un serveur avec la même version principale ou une version plus ancienne. Ou plus précisément :

pg_basebackupfonctionne avec des serveurs de la même version ou d'une version majeure antérieure, jusqu'à 9.1. Cependant, le mode de streaming WAL ( -X stream) ne fonctionne qu'avec la version 9.3 et ultérieure du serveur et le mode de format tar ( --format=tar) de la version actuelle ne fonctionne qu'avec la version 9.5 ou ultérieure du serveur.

Pour cela, vous avez besoin sur le serveur source:

  1. listen_addresses = '*'pour pouvoir se connecter depuis le serveur cible. Assurez-vous que le port 5432 est ouvert d'ailleurs.
  2. Au moins 1 connexion de réplication disponible: max_wal_senders = 1( -X fetch), 2pour -X stream(la valeur par défaut dans le cas de PostgreSQL 12), ou plus.
  3. wal_level = replicaou supérieur pour pouvoir régler max_wal_senders > 0.
  4. host replication postgres DST_IP/32 trustdans pg_hba.conf. Cela accorde l'accès au pgcluster à toute personne de la DST_IPmachine. Vous voudrez peut-être recourir à une option plus sécurisée.

Les modifications 1, 2, 3 nécessitent un redémarrage du serveur, la modification 4 nécessite un rechargement.

Sur le serveur cible:

# systemctl stop postgresql@VERSION-NAME
postgres$ pg_basebackup -h SRC_IP -U postgres -D VERSION/NAME --progress
# systemctl start postgresql@VERSION-NAME

11
Pourriez-vous fournir plus de détails dans votre réponse, comme un exemple?
Magnilex

7
Cela ne fonctionne cependant que lorsque les deux machines ont les mêmes versions PG.
sm

Il y a peu de chances que vous utilisiez une version de base de données différente pour le développement et la production. La dernière fois, j'ai eu une conversation désagréable avec l'un de mes coéquipiers alors qu'elle essayait de soumettre un problème selon lequel certains codes ne fonctionnaient pas avec PG 9.6 alors que nous avions utilisé 9.5 en production à ce moment-là. La sauvegarde de base est beaucoup plus rapide. Ensuite, pg_upgrade est la voie à suivre si nécessaire.
Zorg

2
Il y a de fortes chances que vous souhaitiez migrer vers une version plus récente et que vous ne souhaitiez pas arrêter PostgreSQL.
x-yuri

1
Il y a des chances que chaque fois que vous mettez à niveau votre base de données, vous la mettez à niveau lors du développement et de la mise en scène avant de la faire en production.
andrew lorien

8

Exécutez cette commande avec le nom de la base de données, que vous souhaitez sauvegarder, pour effectuer un vidage de la base de données.

 pg_dump -U {user-name} {source_db} -f {dumpfilename.sql}

 eg. pg_dump -U postgres mydbname -f mydbnamedump.sql

Scp maintenant ce fichier de vidage sur la machine distante où vous souhaitez copier la base de données.

eg. scp mydbnamedump.sql user01@remotemachineip:~/some/folder/

Sur une machine distante, exécutez la commande suivante dans le dossier ~ / certains / pour restaurer la base de données.

 psql -U {user-name} -d {desintation_db}-f {dumpfilename.sql}

 eg. psql -U postgres -d mynewdb -f mydbnamedump.sql

7

J'ai eu beaucoup de mal et finalement la méthode qui m'a permis de le faire fonctionner avec Rails 4 était:

sur votre ancien serveur

sudo su - postgres
pg_dump -c --inserts old_db_name > dump.sql

J'ai dû utiliser l'utilisateur linux postgres pour créer le vidage. J'ai également dû utiliser -c pour forcer la création de la base de données sur le nouveau serveur. --inserts lui dit d'utiliser la syntaxe INSERT () qui autrement ne fonctionnerait pas pour moi :(

puis, sur le nouveau serveur, simpy:

sudo su - postgres
psql new_database_name < dump.sql

pour transférer le fichier dump.sql entre les serveurs, j'ai simplement utilisé le "chat" pour imprimer le contenu et que "nano" pour le recréer en copypastant le contenu.

De plus, le RÔLE que j'utilisais sur les deux bases de données était différent, donc j'ai dû trouver-remplacer tout le nom du propriétaire dans le vidage.


6

Videz votre base de données: pg_dump database_name_name > backup.sql


Réimportez votre base de données: psql db_name < backup.sql


5

Permettez-moi de partager un script shell Linux pour copier vos données de table d'un serveur vers un autre serveur PostgreSQL.

Référence tirée de ce blog:

Script Bash Shell Linux pour la migration des données entre les serveurs PostgreSQL:

#!/bin/bash
psql \
    -X \
    -U user_name \
    -h host_name1 \
    -d database_name \
    -c "\\copy tbl_Students to stdout" \
| \
psql \
    -X \
    -U user_name \
    -h host_name2 \
    -d database_name \
    -c "\\copy tbl_Students from stdin"

Je ne fais que migrer les données; veuillez créer un tableau vierge sur votre serveur de base de données de destination / deuxième.

Il s'agit d'un script utilitaire. De plus, vous pouvez modifier le script pour une utilisation générique comme en ajoutant des paramètres pour host_name, database_name, table_name et autres


5

La réponse acceptée est correcte, mais si vous souhaitez éviter de saisir le mot de passe de manière interactive, vous pouvez utiliser ceci:

PGPASSWORD={{export_db_password}} pg_dump --create -h {{export_db_host}} -U {{export_db_user}} {{export_db_name}} | PGPASSWORD={{import_db_password}} psql -h {{import_db_host}} -U {{import_db_user}} {{import_db_name}}
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.