- Newest
- Most votes
- Most comments
Hi,
To learn the best strategy to perform the version upgrade from v13, feel free to refer to the following document. This document has a list of all possible ways to perform the upgrade from v13 for Amazon Aurora PostgreSQL, such as In-place upgrade, Amazon RDS blue/green deployment, Logical replication, and AWS Database Migration Service (AWS DMS). Depending upon your requirement and downtime you can handle, the strategy will vary.
| Approach | Downtime | Complexity | Best For |
|---|---|---|---|
| Snapshot Restore | Yes | Low | Isolated, risk-free testing environment. For production upgrades, requires downtime and a data gap strategy — snapshots are point-in-time and do not include writes after the snapshot |
| In-Place Upgrade | Yes | Low | Simple to execute, but require downtime |
| Logical Replication | Minutes | High | Provides near zero downtime. Native PostgreSQL, with flexible version compatibility. Can be used as fallback option |
| AWS DMS Homogeneous Migration | Near-zero | High | Cross-account, cross-region, or self-managed to RDS/Aurora with near-zero downtime |
| Blue/Green Deployment | Minutes | Medium | Managed feature with controlled switchover, near zero downtime |
Regarding your error 'Creation of blue/green deployment failed due to incompatible parameter(s): max_logical_replication_workers', this suggests that the value of this parameter 'max_logical_replication_workers' is not set correctly for your Aurora Cluster. You should set this parameter value to the number of databases, plus some reserve for the table synchronization workers and parallel apply workers. Refer following document for the same.
Make sure you have correctly set the following parameters in order to successfully handle the Blue/Green Deployment with respect to incompatible parameter(s).
- max_replication_slots
- max_wal_senders
- max_logical_replication_workers
- max_worker_processes
Hello.
Have you reviewed the explanation in the following document?
This page contains troubleshooting steps for the same error message you are experiencing.
https://repost.aws/ja/knowledge-center/rds-postgresql-blue-green-deployment-error
To migrate an Aurora PostgreSQL instance from version 13 to version 16, AWS recommends using Amazon RDS Blue/Green Deployments as the best approach for achieving near-zero downtime during major version upgrades.
Blue/Green Deployment Process:
The Blue/Green deployment provisions a synchronized replica (green) of your production (blue) database. You can make updates to the replica without impacting the original database. Once changes are complete and replication has fully caught up, you can switch over to the green environment with minimal downtime.
Regarding Your Error:
The error you're encountering with the max_logical_replication_workers parameter indicates a compatibility issue between your source and target parameter groups. To resolve this:
-
Enable logical replication on your source cluster - This is a prerequisite for Blue/Green deployments. Note that enabling the logical replication parameter requires a reboot of the writer instance.
-
Create a compatible cluster parameter group for PostgreSQL 16 with logical replication enabled:
- Create a new cluster parameter group for the aurora-postgresql16 family
- Enable the
rds.logical_replicationparameter in this new parameter group - Ensure parameter values are compatible between your PG13 and PG16 parameter groups
- Verify version support - Confirm that your Aurora PostgreSQL 13 version supports Blue/Green deployments. If not, you may need to perform a one-time in-place minor version upgrade first.
Alternative Approach:
If you need more control over the upgrade process, you can use logical replication with fast cloning. This involves creating a publication on your current database, cloning it, upgrading the clone to the new version, and setting up a subscription for replication. However, Blue/Green deployments provide a more streamlined and AWS-managed approach.
Make sure all parameter groups are properly configured and compatible before recreating the Blue/Green deployment.
Sources
Using logical replication to perform a major version upgrade for Aurora PostgreSQL - Amazon Aurora
Implement a rollback strategy for Amazon Aurora PostgreSQL upgrades using Amazon RDS Blue/Green deployments | AWS Database Blog
How Wiz achieved near-zero downtime for Amazon Aurora PostgreSQL major version upgrades at scale using Aurora Blue/Green Deployments | AWS Database Blog
ok thanks , a good configuration of the parameter group solve the issue
Now , i have a migration problem because of columns Large Objects : (in FR)
The Aurora PostgreSQL 13 → 16 migration via Blue/Green deployment (VPPL-692) is blocked by logical replication, which does not support PostgreSQL Large Objects (pg_largeobject). Two entities in the database use @Lob byte[], forcing Hibernate to use lo_create()/lo_get().
The Blue/Green deployment switches to REPLICATION_DEGRADED and blocks the switchover as soon as a write operation occurs on these tables.
Relevant content
- asked 3 years ago
- asked 4 years ago
ok thanks , a good configuration of the parameter group solve the issue
Now , i have a migration problem because of columns Large Objects : (in FR)
The Aurora PostgreSQL 13 → 16 migration via Blue/Green deployment (VPPL-692) is blocked by logical replication, which does not support PostgreSQL Large Objects (pg_largeobject). Two entities in the database use @Lob byte[], forcing Hibernate to use lo_create()/lo_get().
The Blue/Green deployment switches to REPLICATION_DEGRADED and blocks the switchover as soon as a write operation occurs on these tables.
As also stated in the table in the following document, unfortunately, large objects cannot be used in Blue/Green deployments. Therefore, if the contents of the tables cannot be changed, I believe an in-place upgrade will be necessary. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments-considerations.html#:~:text=Logical%20replication%2Dspecific%20limitations%20for%20blue/green%20deployments