déplacement d'une grande base de données PostgreSQL / PostGIS

Je dois déplacer et mettre à niveau une très grande base de données PostGIS (~ 320 Go) de server1 (PostgreSQL 9.1, PostGIS 1.5) vers server2 (PostgreSQL 9.3, PostGIS 2.1).

Le processus de mise à niveau est bien documenté . Le problème est que je n'ai pas assez d'espace sur server1 pour y vider le fichier, le contrôler, puis le copier sur server2 et vérifier les sommes. J'ai essayé:

Canalisation du vidage de server1 vers server2 à l' aide de nc.
Écrire un fichier de vidage directement sur un système de fichiers server2 qui est monté sur server1 en utilisant sshfs.

Les deux fois, le fichier de vidage semble avoir été corrompu. pg_restores'est cassé à différents endroits avec des erreurs comme celle-ci:

pg_restore: [compress_io] could not uncompress data: incorrect data check

Quelqu'un peut-il suggérer une meilleure façon de réaliser ce mouvement et cette mise à niveau?

MISE À JOUR: A essayé NFS (et a donné à SSHFS un autre essai). Il est clair que ces systèmes de fichiers distants ne peuvent pas transférer de manière fiable autant de données . Des blocs sont visiblement manquants dans le fichier SQL résultant, provoquant des erreurs de syntaxe comme celle-ci lors de l'importation:

ERROR:  invalid input syntax for integer: "8266UPDATE spatial_ref_sys o set auth_name = n.auth_name, auth_srid = n.auth_srid, srtext = n.srtext, proj4text = n.proj4text FROM _pgis_restore_spatial_ref_sys n WHERE o.srid = n.srid;"

postgresql migration postgis

— kontextify
source

La deuxième option semble bonne, mais pourquoi n'utilisez-vous pas NFS? Il y a peut-être une petite interruption qui n'est pas bien gérée par sshfs. 320 Go est un fichier assez volumineux.

— Marco

Acheter un disque plus gros? 1 To ne coûte presque rien de nos jours.

— Colin 't Hart

Il s'avère que NFS n'est pas aussi fiable que SSHFS pour transférer autant de données. Mise à jour de la question.

— kontextify

Je recommanderais de vider la base de données 9.1 de votre nouveau serveur 9.3 comme ceci:

pg_dump -h remoteserver -U remoteuser remotedbname -Fc -f my_old_server_backup.dump

Je recommande d'utiliser le 9.3 pg_dumpcar il pg_dumpest toujours rétrocompatible, mais pas compatible en amont. En d'autres termes, le plus récent pg_dumpprendra en charge toutes les modifications de syntaxe que le nouveau serveur requiert et que l'utilitaire plus ancien ne connaît pas.

Assurez-vous que votre pg_hba.confet listen_addressesin postgresql.confsont configurés pour vous permettre de vous connecter et de vider à distance de manière appropriée également.

Si vous vouliez essayer un vidage et restaurer en une seule étape, vous pouvez également essayer ceci:

pg_dump -h remotehost -U remoteuser remotedbname | psql -U localuser localdbname

J'espère que cela pourra aider. =)

— Kassandry
source

Le "vidage et restauration en une seule étape" ne fonctionnera probablement pas en raison des différences entre les versions de PostGIS, mais l' exécution du vidage à distance à partir du serveur de réception et sa restauration ont fonctionné! C'est clairement mieux que d'utiliser des systèmes de fichiers réseau. Merci, j'ai maintenant une base de données qui fonctionne!

— kontextify

Est-ce un processus performatif? Il me semble que cela prendra quelques jours. Alors pgdump créera-t-il un fichier de vidage avec ~ 300 Go si je n'utilise pas de sauvegarde à distance de serveur à serveur?

— deFreitas