Recently attempted an upgrade from 9.3 to 9.4 on an Ubuntu 14.04 Postgres installation, something went awry and the system lost power midway through the upgrade. Now the cluster won't start and when I try to move the data file to a new system and start it, there are inconsistencies in the data files and PG_VERSIONs are varied between 9.3 and 9.4.
Is there any way to recover and make consistent the files to launch under a new cluster?
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.
RDS is running on postgres version of 9.6 while my installed version is 9.3.2 and an yum update changes the postgres version to 9.6.8 while my RDS is running on 9.6.6 . Does this version mismatch is bad or should I Upgrade my server RDS from 9.6.6 to 9.6.8
I've done exactly this and it works fine. As you're updating just the client and the client is backwards compatible (especially at such a minor revision level), it should not hurt. A good rule of thumb is to always do regression testing to make sure, and have a way to roll back. There is no rule that says client and server versions have to be identical, however.
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 upgraded my Ubuntu 8.04 To Ubuntu 10.04. Unfortunately, the upgrade process also updated the Postgres 8.3 install to a Postgres 8.4 install. My feeling is that although database engine binaries have been updated, the database itself was not migrated, hence it can not be loaded by the 8.4.
Since the 8.3 data format is not compatible with 8.4 format, altering postgresql.conf is not enough, nor can I use pg_dump with my 8.4 install.
I need a way to upgrade my previous base from 8.3 to 8.4, with no access to a 8.3 engine, only a 8.4.
Any clue?
The postgres packages in Debian, and hence, Ubuntu, has a very clearly defined way of upgrading from one Postgres version to another. The procedure is documented in /usr/share/doc/postgresql-common/README.Debian as follows:
Default clusters and upgrading
------------------------------
When installing a postgresql-X.Y package from scratch, a default
cluster 'main' will automatically be created. This operation is
equivalent to doing 'pg_createcluster X.Y main --start'.
Due to this default cluster, an immediate attempt to upgrade an
earlier 'main' cluster to a new version will fail and you need to
remove the newer default cluster first. E. g., if you have
postgresql-8.2 installed and want to upgrade to 8.3, you first install
postgresql-8.3:
apt-get install postgresql-8.3
Then drop the default 8.3 cluster:
pg_dropcluster 8.3 main --stop
And then upgrade the 8.2 cluster to 8.3:
pg_upgradecluster 8.2 main
The best time to do this is before ugrading to a version of Ubuntu where the version of Postgresql you're currently running has been removed, i.e. in this example, while on a version of Ubuntu that has the possibility to install both Postgres 8.3 and Postgres 8.4. In my case, I went from jaunty to karmic, upgraded 8.3 to 8.4 and then went from karmic to lucid.
The upgrade process as described above is very smooth. The *pg_upgradecluster* command will stop the old version, migrate data, then start the new version on the same port as the old version, finally starting the old version on a new port.
If you did not migrate your 8.3 postgres data before moving to an Ubuntu version that lacks postgres 8.3, migrating is still simple. Start by adding the karmic ubuntu repository to /etc/apt/sources.list:
deb http://archive.ubuntu.com/ubuntu/ karmic main restricted universe
Install postgresql-8.3:
apt-get update && apt-get install postgresql-8.3
Drop your 8.4 cluster. Warning: This will remove data in your postgresql 8.4 installation if you have any. But if you're only doing this because you need to upgrade your 8.3 to 8.4, you will have no data in your 8.4 cluster.
pg_dropcluster 8.4 main --stop
And then upgrade the 8.3 cluster to 8.4:
pg_upgradecluster 8.3 main
Finally, remove the postgresql-8.3 package, and remove the jaunty-line from /etc/apt/sources.list, then run apt-get update again.
As usual, taking a backup of your postgres directories before doing any of the above is always a good idea.
You'll have to install PostgreSQL 8.3 in temporary location from source, copy your old data there, start Pg, dump it's data using pd_dumpall and then import this data to new Postgres.
It's impossible without installing Pg 8.3.
Make sure you backup everything before you try anything.
There is the pg_migrator project which I think will do that for you, though I'm not sure whether it needs to 8.3 applications or source code.