I currently run Postgres 8.4 on Centos 6. I need to migrate to Postgres 9.1 on a Windows machine. I have my reasons for this...Anyway, what is the best way to move the data from one DB to another without interrupting service and losing any of the functionality particularly with PostGIS? The PostGIS version (2.0) that installs with 9.1 has some features that I want to take advantage of but at the same time I don't want to lose any of the features in 8.4. Can anyone provide some insight in to this?
As far as I know, the only thing that will let you upgrade without downtime is a trigger-based replication system such as Slony-I.
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.
Currently we are using microstrategy as a reporting tool 11.1 version and using Oracle DB - micro strategy metadata, Statistics , history all installed in Oracle
now we are planning to move Db from Oracle to Postgres. just wanted to check if microstrategy support Potgres DB
Here is the list of certified and supported versions: Repositories
From personal experience I can say PostgreSQL v9,v10 and v11 runs fine as metadata repository. Tested v9-v12 as DWH too, all working without problems.
As far as I remember they didn't deliver the bundled driver in one of the MSTR-versions (2019-something), but that seems to have changed in MSTR-2020 again. Not a showstopper, but something to be aware of.
I am also running PG-11 as repo for History List too, but you definitely won't get help from support for this. OT: They even made me switch from MariaDB to MySQL for a support case (don't really blame them though, it's not certified and that's that).
My last attempt at running Statistics-Repo with PG is a long while ago and it didn't really work out of the box. Don't know what the situation is there. You might have to consider moving to PlatformAnalytics and/or MySQL(/MariaDB) for this too. EM only receives bugfixes from MSTR-2020 onwards, so this seems to be future-proof (EM discontinued from 2020 onwards?)
This mostly reflects our experience, the only certified PG version for MSTR 11.1 is PG-9 and only for the MD-Repo!
AFAIK the documentation states:
In general, log shipping between servers running different major PostgreSQL release levels is not possible. It is the policy of the PostgreSQL Global Development Group not to make changes to disk formats during minor release upgrades, so it is likely that running different minor release levels on primary and standby servers will work successfully. However, no formal support for that is offered and you are advised to keep primary and standby servers at the same release level as much as possible.
But my question is: does disk format actually changes between 9.4.9 and 9.5.6?
We are currently running with:
PostgreSQL 9.4.9 on x86_64-unknown-linux-gnu, compiled by gcc (Debian 4.9.2-10) 4.9.2, 64-bit
Debian GNU/Linux 8.6 (jessie)
And the 'next' possible step would be using the version from this repo:
http://apt.postgresql.org/pub/repos/apt/
Our current DB is about 2TB, so we'd like to try a replication-like approach for a smoother transition, rather tan a using a full pg_dump, which would actually need quite a while with the db frozen.
does disk format actually changes between 9.4.9 and 9.5.6
Yes. Until the coming PostgreSQL 10, PostgreSQL used a wacky version scheme where "x.y" was the "major" version, and the 3rd number was the minor version.
So 9.4 and 9.5 are different major versions. They are definitely not on-disk compatible.
To upgrade you can:
Dump and reload
Use pg_upgrade (the officially recommended way)
Use pglogical
Use Londiste
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 phpPgAdmin as an XAMPP addon when I encountered an error because the latest phpPgAdmin supports upto PostgreSQL version 8.3.x. So I decided to install PostgreSQL 8.3.11 instead of the latest (PGSQL 8.4.x). Will this matter to my OSM application? Thanks!
There are a lot of advantages to Postgres 8.4 over 8.3, and Open Street Map / PostGIS should work on it, so I'd recommend using 8.4 for the Postgres version, and instead grabbing the latest version of phpPgAdmin from the projects github repo (http://github.com/xzilla/phppgadmin), which fully supports 8.4. That will tide you over until the next official phpPgAdmin release, which is scheduled to happen in the next few weeks.
The only link between OSM and postgresql is probably postgis.
Postgis lastest version (1.5.1) requires postgresql >= 8.3, so the answer is no, it won't matter - if, of course, I understood your question correctly.