I have a DebianEtch/Postgres 8.1 setup which replicates using slony from master > slave.
These servers are being replaced by Debian Squeeze/Postgres 8.4 servers.
I've got Slony between the Squeeze servers running fine, and need to replicate from Etch.Master to Squeeze.Master before I pull the plug on the Etch boxes.
However:
./install_ms1_sqz.slonik:6: Possible unsupported PostgreSQL version (80412) 8.4, defaulting to 8.0 support
./install_ms1_sqz.slonik:6: loading of file /usr/share/slony1/slony1_funcs.sql: PGRES_FATAL_ERROR ERROR: Slonik version: 1.2.6 != Slony-I version in PG build 1.2.21
ERROR: Slonik version: 1.2.6 != Slony-I version in PG build 1.2.21
I'm guessing it's complaining about the different versions of 'something' between Etch and Squeeze servers, but not sure what.
The Etch box is a live server and cannot be disturbed, although I can install a new version of slony if need (and available), and must still replicate to Etch.Slave, although some 'downtime' is OK for this.
So, do I have a hope in hell, or must I dump/restore the relevant tables, seqs etc at switchover time?
Cheers.
The error message seems clear - you have different versions of Slony on the two servers and they aren't compatible.
I'd install both PostgreSQL and Slony from source on the squeeze server - that way you can have the same version on both machines. It's not a difficult process once you've installed the relevant development libraries.
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.
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.
When trying to get local data to Heroku, I am encountering a version mismatch between two different versions of pg_dump.
Specifically, I am getting this message:
pg_dump: server version: 9.2.2; pg_dump version: 9.1.4
pg_dump: aborting because of server version mismatch
I have found others with this problem, but do not know enough to implement the proposed solutions. (I am new to Ruby on Rails, PostgreSQL, Heroku, and the Mac! Very much at the stage of playing around the picking things up as I go.)
I was thinking I might simplify my life if I uninstalled all PostgreSQL on my local machine and started again with a clean install of PostgreSQL 9.2.2 from http://postgresapp.com/, but I don't know how to go about doing the uninstall.
I'm running Mac OS X Mountain Lion 10.8.2.
OS X 10.8 comes with pg_dump version 9.1.4 in the /usr/bin directory, along with psql and other programs that are client-side PostgreSQL tools. It does not mean that PostgreSQL as a server is installed (unless you have OS X Server Edition).
So you don't have to uninstall PostgreSQL because it's not installed and it's better not to remove these postgres client tools in /usr/bin because they belong to the system as shipped by Apple. They just need to be side-stepped.
The package provided by postgres.app comprises both the PostgreSQL server and the client-side tools of the same version as this server. These tools get installed in /Applications/Postgres.app/Contents/MacOS/bin
To use these instead of the 9.1 ones from Apple when you work in a Terminal, postgres.app documentation says to do:
PATH="/Applications/Postgres.app/Contents/MacOS/bin:$PATH"
and put it in your .profile file.
Once you have done that and you run pg_dump, you should no longer get the error that's it's the wrong version, because it would be the one that ships with postgres.app (currently 9.2.2).
I have this setup and it works OK for me.
If you only need to upgrade your pg_dump to the latest version and you have homebrew and mac, if the app has the latest version and your local pg doesn't:
brew upgrade postgresql
If you're using postgresapp 9.3.x, the path is different. The following worked for me (courtesy of http://sigmyers.com/blog/2013/3/12/postgres-pgdump-version-mismatch-error-postgresapp-postgresappcom)
export PG_BIN_PATH="/Applications/Postgres.app/Contents/Versions/9.3/bin/"
PATH=$PG_BIN_PATH:$PATH
Check here for the latest path: http://postgresapp.com/documentation/cli-tools.html
I'm running Mountain Lion Server. My PostgeSQL server is at version 9.2.1 and the default tools are at 9.1.5.
I had to use:
PATH="/Applications/Server.app/Contents/ServerRoot/usr/bin:$PATH"
to make it work.
Yep, sometimes if you run Postgres.app this may happen after upgrade. Make sure you restart your Postgres.app - it will update your PATH.
In my case I have postgresql installed via homebrew and the executables are here: /usr/local/opt/postgresql#9.6/bin
Or you copy the dump and restore executions to the /Applications/Postgres.app/Contents/SharedSupport folder
or in PdAgmin you point the PG bin Path (in properties -> binary Path) to the path of the executables of your postgre