Pausing logical replication on Aurora Postgresql blue/green deployment

Pausing logical replication in an Aurora PostgreSQL blue/green deployment is not directly supported, as the replication process is managed by Amazon RDS to ensure data consistency between the blue and green environments. However, there are some approaches you can consider to achieve your goal of migrating big table structures:

1. Instead of pausing replication, it's recommended to perform your schema changes and migrations on the blue (source) environment first. These changes will then be replicated to the green environment. This approach ensures that both environments remain in sync and follows best practices for blue/green deployments.

2. If you must make changes only in the green environment, be aware that attempting to pause replication can break the blue/green deployment process. The rds.logical_replication parameter is meant for the publisher (blue environment) and not the subscriber (green environment), which explains why changing it in the green environment's parameter group doesn't have an effect.

3. If you decide to proceed with changes only in the green environment, you should be prepared to handle potential replication conflicts or breaks. After making your changes, you may need to manually resynchronize the environments or create a new blue/green deployment.

4. Consider breaking down your migration into smaller, replication-compatible steps that can be applied to both environments sequentially. This approach minimizes the risk of replication issues and maintains consistency between blue and green clusters.

5. If possible, schedule your migrations during a period of low database activity to reduce the impact on replication lag and minimize potential conflicts.

6. Monitor the replication process closely during your migrations. You can use the OldestReplicationSlotLag CloudWatch metric or run SQL queries to check the replication lag and status.

Remember that modifying the replication process in a blue/green deployment can have significant implications for the deployment's integrity and the ability to perform a successful switchover. It's crucial to thoroughly test any changes in a non-production environment before applying them to your production setup.

If you find that the blue/green deployment approach doesn't suit your specific migration needs, you may need to consider alternative strategies for your database updates, such as creating a separate staging environment for your migrations and then performing a traditional migration to production.

Sources
Limitations and considerations for Amazon Aurora blue/green deployments - Amazon Aurora
Best practices for Amazon Aurora blue/green deployments - Amazon Aurora
Switching a blue/green deployment in Amazon RDS - Amazon Relational Database Service