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.
Related
Azure Postgres Single server version is 11. Is it possible to upgrade it to 13+ version using dump and restore as mentioned here:
https://learn.microsoft.com/en-us/azure/postgresql/how-to-upgrade-using-dump-and-restore
It should still remain Single Server.
Yes, you can.
The document you shared is Microsoft's official and therefore there is no doubt that you can upgrade it to any higher version using dump and restore.
Just take care of the below mentioned points:
You can upgrade your PostgreSQL server deployed in Azure Database for PostgreSQL by migrating your databases to a higher major version server using following methods.
Offline method using PostgreSQL pg_dump and pg_restore which incurs downtime for migrating the data.
Online method using Database Migration Service (DMS). This method provides a reduced downtime migration and keeps the target database in-sync with the source and you can choose when to cut-over. However, there are few prerequisites and restrictions to be addressed for using DMS.
The following table provides some recommendations based on database sizes and scenarios.
Choose the right approach based on your database configuration and it should be done without any issue.
To upgrade using pg_dump and pg_restore, you can refer Migrate your PostgreSQL database by using dump and restore.
It is not possible.
In the document, prerequisites states:
A source PostgreSQL database server running a lower version of the
engine that you want to upgrade. A target PostgreSQL database server
with the desired major version Azure Database for PostgreSQL server -
Single Server or Azure Database for PostgreSQL - Flexible Server.
The question asks about upgrading target.
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.
I am trying to upgrade Aurora RDS Postgres cluster db.r5.xlarge from version 12.7 to 13.3.
I choose Engine version 13.3, default DB cluster parameter group and DB parameter group default.aurora-postgresql13 and choose 'Apply immediately'.
Received error message:
We're sorry, your request to modify DB cluster clone-cluster has failed.
Cannot modify engine version because instance clone-cluster is running on an old configuration.
Apply any pending maintenance actions on the instance before proceeding with the upgrade
There are no any pending maintenance actions showing in AWS RDS console and I have no idea what configuration they mean.
We are on a free basic support plan no so we cannot get help from AWS. Can anyone please suggest if there's a way to upgrade the whole cluster at once?
I had this issue and contacted AWS support. They said it is a known issue for (some, or all) db.t3 instance types. In my case I was using db.t3.medium.
So the workaround is as follows:
Change instance type on the cluster to r5.xlarge or db.r6g.large.
Upgrade to PostgreSQL 13.3
Change instance type back to db.t3.medium.
Just to add to the other great answers, another possible reason for "old configuration" errors is attempting to upgrade from an old minor version.
I was trying to upgrade from Postgres 12.6 directly to 13.3, which is not supported.
Instead, I had to upgrade to 12.7 first and then upgrade to 13.3.
It's written in the docs, but I didn't notice the minor version requirement.
Hit the same issue with upgrade to a major version and here's the undocumented solution I found:
Select an instance from the cluster, and in the actions menu you should see Upgrade Now.
Do this for each instance that is part of the cluster.
Modify the cluster and you should be able to upgrade to any available 13.x version.
Even though it is shown as the same version as the Cluster, the Upgrade now action will run configuration update on the instance itself putting it in maintenance and rebooting it.
This is not correctly documented at the moment, but it is possible to check and resolve (for those of us automating the upgrade process.) The CLI aws rds describe-pending-maintenance-actions sometimes reports the status. If you know ARNs, you can filter on them, or if just a name, this seems to work:
aws rds describe-pending-maintenance-actions --query 'PendingMaintenanceActions[?contains(ResourceIdentifier, `test`)`
The maintenance can be applied programmatically using apply-pending-maintenance-action.
However...
This message also appears to occur when something about the upgrade path is invalid. In my case, I believe the case is as follows:
Source is 9.6.19 Aurora PostgreSQL
Target is 10.18. This fails.
Set target to 10.14 and upgrade occurs
In short, the UI, and other information about what versions of what are compatible is incomplete. I have reported this to AWS and they mostly shrugged, telling me to look at the doc. Pffft.
This one worked for me. In rds, select the server highlighted in the error message, go to "Configuration" and make sure that the "Recommendations" area is empty, otherwise, "Apply Now" the recommendation/s. Once all completed, "Modify" from the Global/Regional Cluster and try to upgrade again.
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
Currently, I am using MongoDB 2.4.1 in my all shard clusters. I need to upgrade to MongoDB 2.4.6.
Please help me on this.
Thank you.
If you are upgrading between point releases (for example, 2.4.x to 2.4.y), the upgrade process should just be updating the binaries. As a general rule there should be no changes in data file format, config metadata, or backward compatibility within the same major release series.
It's definitely worth reading the release notes and upgrade notes to be clear on the changes and any upgrade caveats. I would also encourage you to upgrade to the latest available production version in your release series (currently 2.4.9) as there are generally worthwhile performance and stability improvements.
Recommended steps for 2.4.x -> 2.4.y sharded cluster upgrade
The recommended steps for upgrading sharded cluster components with minimal disruption are:
Disable the balancer to avoid migration errors during the upgrade period.
NOTE: If a migration is currently in progress, it will be completed before the balancer is disabled.
Upgrade all mongos instances in the cluster, in any order.
Upgrade all 3 mongod config server instances.
NOTE: You should ideally upgrade the first server listed in the mongos --configdb
argument last (i.e. upgrade the config servers in the reverse of the order listed in your --configdb string).
Upgrade each shard, one at a time.
NOTE: You should ideally upgrade the mongod secondaries first, and then run rs.stepDown() to elect a new primary before upgrading the primary of each shard. You may wish to run rs.freeze(60) on the current primary to ensure it is ineligible for re-election.
Enable the balancer once all upgrades are complete.