使用 AWS re:Post 即表示您同意 AWS re:Post 使用條款

Database Cluster Blue/Green Deployment on Unsupported Instance Type in Aurora MySQL

0

Issue Overview:

Current Setup: My database cluster is currently running on db.r4.large instance type. and Aurora (MySQL 5.7) 2.11.2
Upgrade Target: I aim to upgrade to Aurora MySQL version 8.0.mysql_aurora.3.06.0.
Challenge: The db.r4.large instance type is not supported for this Aurora MySQL version. My plan was to switch to db.r5.large during the Blue/Green Deployment.

Attempted Solutions and Challenges:

Blue/Green Deployment Strategy: I attempted to use a Blue/Green Deployment approach to mitigate risks associated with direct upgrading. However, I'm unable to specify the db.r5.large instance type during the deployment process.
AWS CLI Efforts: I also tried to specify the db.r5.large instance type for the cluster using AWS CLI, but this approach didn't allow for the change in instance type either.

Enter image description here

Questions:

Are there any known workarounds or strategies to specify a different instance type (db.r5.large) during a Blue/Green Deployment for Aurora MySQL?
Is there an alternative approach or best practice that would allow the instance type change while minimizing risks associated with the upgrade?


Thank you in advance for your support!

已提問 8 個月前檢視次數 177 次
1 個回答
0

There are a few options to consider for changing the instance type during a blue/green deployment for an Aurora MySQL cluster:

Take a snapshot of the existing cluster and restore it to a new cluster with the desired instance type. Then perform a switchover to route traffic to the new cluster. This avoids downtime but requires twice the resources during the transition.

Use the AWS Database Migration Service (DMS) to migrate the database from the existing cluster to a new one configured with the target instance type. DMS can minimize downtime during the migration.

If the target instance type is a larger one, scale out the existing cluster by adding instances before performing the switchover. This allows leveraging the existing data without restoring from a snapshot.

For non-production environments, an in-place upgrade is possible by taking an outage during the instance type change. However, this is not recommended for production databases due to the risks.

The best approach would depend on your specific environment and requirements around downtime. AWS documentation provides more details on performing upgrades, migrations and switchovers for Aurora clusters.

profile picture
專家
已回答 8 個月前

您尚未登入。 登入 去張貼答案。

一個好的回答可以清楚地回答問題並提供建設性的意見回饋,同時有助於提問者的專業成長。

回答問題指南