Application downtime reduction

There are several approaches you can consider to reduce downtime for your MySQL RDS instance during feature releases and schema changes, even with RDS Proxy configured:

1. Convert to Multi-AZ deployment: By converting your Single-AZ RDS instance to Multi-AZ, you can significantly reduce downtime during modifications. In a Multi-AZ setup, changes are applied to the standby instance first, followed by a failover. This process typically results in only 60-120 seconds of downtime, which includes the failover and crash recovery time. The conversion from Single-AZ to Multi-AZ itself doesn't cause any downtime.

2. Use a read replica for upgrades: Although you can't use Blue/Green deployments with RDS Proxy, you can still leverage read replicas to minimize downtime. This approach involves creating a read replica of your existing RDS instance, performing the necessary schema changes and upgrades on the replica, and then promoting it to become the primary instance. This method allows you to prepare and test most changes ahead of time, reducing the actual downtime during the switchover.

3. Optimize your schema change process: Ensure that your schema changes are well-planned and optimized. Some schema changes can be performed online with minimal impact, while others may require more careful handling. Consider using tools or techniques that allow for online schema changes when possible.

4. Implement a maintenance window strategy: Plan your schema changes during off-peak hours and communicate the maintenance window to your users. While this doesn't technically reduce downtime, it can minimize the impact on your users.

5. Consider Aurora MySQL: If your workload allows, you might want to explore migrating to Aurora MySQL, which offers features like fast cloning and more seamless failovers that can help reduce downtime during updates.

Remember that while RDS Proxy does limit some options like Blue/Green deployments, it provides other benefits such as improved failover times and connection management. Weigh these benefits against your downtime requirements when considering any changes to your architecture.

By combining these approaches, you can work towards minimizing the downtime for your MySQL RDS instance during feature releases and schema changes, even with the constraints imposed by using RDS Proxy.
Sources
Upgrade RDS instance with zero (minimal) downtime | AWS re:Post
Using a read replica to reduce downtime when upgrading an RDS for MariaDB database - Amazon Relational Database Service
Using a read replica to reduce downtime when upgrading an RDS for MySQL database - Amazon Relational Database Service
Targeted business outcomes - AWS Prescriptive Guidance

Hey, totally get where you're coming from. Schema changes on RDS, especially with a single-AZ deployment and RDS Proxy, can definitely create pain during deployments. The good news is there are a few ways to minimize or even eliminate downtime, even without Blue/Green.

Here are some proven approaches:

1. Switch to Multi-AZ RDS (if possible) Even though RDS Proxy doesn’t support Blue/Green, moving to Multi-AZ can help minimize impact during failover or planned maintenance. It also gives more flexibility for using certain features like replica promotion as a near–blue-green workaround (see point 4).

2. Use Online Schema Change Tools For most cases, downtime happens because of locking DDL operations (e.g., adding a column with NOT NULL, changing indexes). Use tools like:

gh-ost

pt-online-schema-change

These tools rewrite schema changes in a non-blocking, async way, and they’re widely used in production for zero-downtime migrations including with RDS.

3. Decouple schema deployment from app deployment Instead of doing schema changes during release windows: Roll out schema changes ahead of time in a backward-compatible way Deploy app features that begin to use the new schema only after validation

This “expand and contract” pattern works well:

  Phase 1: Add new nullable columns/indexes
  Phase 2: Update app to use them
  Phase 3: Clean up old columns

4. Replica + Cutover Strategy (Manual Blue/Green-ish) Even without RDS Blue/Green support via Proxy, you can manually simulate it: Create a read replica of your current DB Apply schema changes to the replica Validate your application against it Promote the replica and point your app directly (bypassing the proxy) This gives you near-zero downtime, but it does require temporary architecture adjustments.

5. Evaluate Aurora MySQL if you're open to migration. Aurora supports fast cloning, zero-downtime patching, and integrates more natively with blue-green deployments, which could simplify things in the long run — especially for microservices-style architectures.