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
Related
Last time I performed a major postgresql RDS version upgrade, the followers were really messed.
I am about to perform a minor version upgrade (something like 12.5 --> 12.6) and i cannot find any relevant documentation about if and what type of impact this may have on the followers.
Any directions towards any relevant docs?
According to AWS documentation:
There are two kinds of upgrades: major version upgrades and minor version upgrades. In general, a major engine version upgrade can introduce changes that are not compatible with existing applications. In contrast, a minor version upgrade includes only changes that are backward-compatible with existing applications.
Source
I can also mention that I've been running a few RDS PostgreSQL clusters in production, with perhaps all the possible flavors, Aurora RDS with PostgreSQL provisined, Aurora RDS serverless, RDS PostgreSQL and never had an issue when doing a minor upgrade either with master, replicas or clients, we even have the automatic minor version upgrade enabled.
Can you upgrade Postresql-server directly from 9.2 to 9.6? (Running on RHEL 7)
yes:
https://www.postgresql.org/docs/9.6/static/pgupgrade.html
pg_upgrade supports upgrades from 8.4.X and later to the current major
release of PostgreSQL, including snapshot and alpha releases.
https://www.postgresql.org/docs/9.6/static/app-pgdump.html
Because pg_dump is used to transfer data to newer versions of
PostgreSQL, the output of pg_dump can be expected to load into
PostgreSQL server versions newer than pg_dump's version. pg_dump can
also dump from PostgreSQL servers older than its own version.
(Currently, servers back to version 7.0 are supported.) However,
pg_dump cannot dump from PostgreSQL servers newer than its own major
version; it will refuse to even try, rather than risk making an
invalid dump.
ephasis mine
I've got two PostgreSQL 9.2.4 servers running on 32-bit Suse.
Failover is configured using a shared storage device.
I'd like to upgrade to 64-bit Ubuntu machines using PostgreSQL's streaming replication while keeping the database service available. To do that would mean temporarily having failover between a 32-bit and 64-bit system.
I've read a lot of documentation for PostgreSQL & PostgreSQL replication.
It's clear that PostgreSQL doesn't handle streaming replication between 32 & 64 bit systems. It's not as clear if it can handle shared storage between 32 & 64 bit systems. I'm pessimistic, but wanted to check.
Yes, you can - with the caveat that you must use a 32-bit PostgreSQL build on your 64-bit system, it must be the same major release (e.g. both 9.2 or both 9.3) and it must be compiled with the same settings for integer_datetimes etc.
Modern Debian/Ubuntu, like all 64-bit Red Hat variants, supports a multi-arch install where 32-bit and 64-bit binaries can live side by side. So you should be able to simply apt-get install the 32-bit PostgreSQL on your 64-bit system.
That said, I strongly suggest relying on streaming replication instead. Shared-storage failover is very risky - if you have any problems with fencing access and STONITH, you will get extremely severe data corruption. It also protects against fewer classes of problems.
Actually, it's even possible that 32-bit Suse's version of PostgreSQL and 32-bit Ubuntu's aren't compatible. Not likely, but it depends on what options they chose during compilation.
So - no.
If you really want to have complete availability you'll need to look at one of the trigger-based replication systems (slony / londiste / bucardo). These can replicate between different installations of PostgreSQL regardless of on-disk format.
Of course, this means having two sets of data.
It does allow you for an uninterrupted upgrade though, so you can consider switching to the latest 9.3 at the same time.
I have a production server that happens to be using a single instance of an older 32-bit version of MongoDB (2.0.0). I wanted to check a couple things before I got down and dirty with moving this data over to a separate server.
Will there be any conflicts doing a mongodump on a 32-bit install and a mongorestore to a 64-bit installation?
Is there any problems moving a 2.0 database dump to a 2.2.x installation?
I've read you are unable to do a mongodump of a 2.2 and correctly mongorestore to a 2.0, but I'm just doing a version upgrade. I've also read you can do replica sets between 32-bit and 64-bit versions of MongoDB, so I'm hoping this transition will work fine.
Just wanted to check, thanks!
Will there be any conflicts doing a mongodump on a 32-bit install and
a mongorestore to a 64-bit installation?
No, this will be fine, no problems - the BSON format will not be changed because of architecture
Is there any problems moving a 2.0 database dump to a 2.2.x
installation?
No problems here either, in fact you can just copy the data files directly if you wish (as long as the source DB is shut down at the time). That will in fact be faster because you won't have to rebuild indexes.
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.