We're running out of room on our hard drive, and we're forced to move our postgis database to a new linux redhat machine. When our IT person copies the directories over to the new machine, I assume the entire database structure won't copy over perfectly.
We are running Red Hat 6 on the old and new machine. The postgresql version is 9.4.9 and the postgis version is 2.1.8.
Do you have suggestions for steps to take to successfully move our postgis-enabled PostgreSQL database to the new machine, keeping of course all data, structure, tables, etc.
I have seen some tutorials on this, but nothing really recent online.
Thanks for any help!
If the architecture is the same on both machines (e.g., both are x86_64), the PostgreSQL version is the same (the third digit can be different) and the RedHat version is the same (so that the same version of glibc guarantees that the collations are the same), you can simply copy the data directory (and all tablespaces) to the new machine and you are good.
Otherwise, use pg_dumpall to dump the old cluster and restore to the new machine.
Related
Good day. I just finished upgrading my AWS RDS database engine from 9.6.22 to 10.17. I used these steps to make the upgrade using the AWS Console:
Create snapshot of target database to upgrade
Restore snapshot
Upgrade the restored snapshot's (which is now a new instance) DB Engine version.
After I did all of this, everything seems fine but when I access the database, this warning message appears
WARNING: psql major version 9.6, server major version 10.
Some psql features might not work.
I did not continue on my testing because I want to know what is the meaning of this first. Because I am fairly new in AWS as a whole. Thanks!
The meaning is that just because you are connecting to an upgraded database on some machine run by Amazon, the PostgreSQL installation on your local machine was not magically updated. psql from version 9.6 doesn't know what metadata tables were changed in v10, what features were removed and so on.
It would be a good idea to install a more recent version of PostgreSQL on your machine. By the way, upgrading to v10 was not the smartest move, as that version will go out of support in less than a year. You should upgrade to the latest version that your service provider offers.
The client program psql you are using to connect to the database is from an older version than the database it is connecting to. Some of the introspection features might not work. For example, psql from 9.6 won't know how to do tab completion for commands that were added to the server after 9.6.
This is generally not a major problem for psql (unless the server wants to use SCRAM authentication), but for optimal experience it would be good to install a newer client. Other tools like pg_dimp might not with at all against a server newer than they are.
Before migrating from an old laptop I created dumpfiles for all of my postgresql/postgis databases using pg_dump. However after migrating I'm having problems with a lot of errors on import to the new database. I've realized that my old and new machine are running different versions of postgresql/postgis. The dumps were created on a machine running postgresql 9.3.13 and postgis version 2.1; I'm trying to recreate the databases on a machine running postgresql 9.5.4 and postgis version 2.2
Any suggestions for getting the data from my dumps to load without problems? Or for creating new dumps on the old machine which will work across versions?
In my old server, Postgresql 9.1 is installed and it contains a large scale of data. Now, I have got a new server and installed the latest version of Postgresql which is 9.2. I want to migrate the whole data from the old server to the new server. I looked at Postgresql documentation and there is a command to upgrade but it seems to explain upgrading in the same server. How could I approach for this matter?
I would be very careful about changing both hardware and major versions of PostgreSQL at the same time. If something goes wrong, it will greatly complicate figuring out what the problem is.
I do this as a two step process, first restore the database to the new server as the same version, then run pg_upgrade. That means you have to have both versions of the software installed on the new server simultaneously.
Dump the database with pg_dump and load it at the new server with psql. I think pg_upgrade is better as an in place procedure.
I'm trying to install PGSQL 8.3 (and 8.4 and 9.0) on my work laptop. At the end of the installation, the installer complains it can't init the cluster. Investigating more, I noticed that the service is not even installed. I did use the "OneClick Installer", not the pgAdmin stand alone install. I tried installing as Administrator and as a regular user. In all the cases, the pgsql system account is created and the files copied, but the service is not.
I successfully installed PGSQL many times on my home PC. Both the laptop and desktop use Windows 7 64 bits (former is Professional, later is Ultimate). The only differences I can think of are that the laptop is part of an Active Directory and uses McAfee, while the desktop is only on a workgroup and uses Windows Security Essentials.
Are you sure the postgres user is allowed to create files in the data directory? The installer defaults to putting the data directory where the binaries are installed (e.g. c:\Program Files) which is usually not writeable by a regular user (and I never understood why the installer contains such an idiotic default).
McAffee could be an issue though. I have heard several stories about virus scanners infering with the Postgres (or other DBMS). Can you turn McAffee off - at least for the data directory?
Another problem could be that the installer is not able to create the postgres windows user (that is used to run the service).
If you are a local administrator on that machine, try to create the user before the installer does it. The installer will then not try to create the user account.
As a last ressort, you could install PostgreSQL without the installer (this is what I usually do).
Download the ZIP file from http://www.enterprisedb.com/products-services-training/pgbindownload
Unzip it into a convenient location
Run initdb (make sure you do that using the postgres user account - the one that is used to run the service later!)
run pg_ctlr register to create the Windows service
If any of those steps fails you'll see a proper error message which is not always the case with the installer.
Anti-virus is a well known issue:
http://wiki.postgresql.org/wiki/Running_&_Installing_PostgreSQL_On_Native_Windows#Antivirus_software
PostgreSQL connection problems
(answer is from one the core developers)
Postgresql 8.4 and BitDefender 11
With earlier versions of PostgreSQL, I found I had to delete the user "postgres" before reinstalling would work. Not sure what versions had that problem, though.
I want to backup Development and restore it in test and vice-versa.
So when I do a backup of the db (in PGAdmin III), it backs it up. But
when I restore it, all primary key information is gone and no data is
in the tables.
Any help would be much appreciated. Thanks.
pgAdmin uses the client programs pg_dump for making backups and pg_restore for restoring (it's only a GUI). Try to dump and to restore with these programs directly and see if you get any errors or warnings.
Offtopic: Support for version 8.1 ends this year, you should upgrade to a newer version.