1

Is there a way to upgrade from Aurora 1 (MySQL 5.6) to Aurora 2 (MySQL 5.7) without downtime on an active database? This seems like a simple task given we should be able to simply do major version upgrades from either the CLI or the Console, but that is not the case.

We tried:

  1. Creating a snapshot of the database
  2. Creating a new cluster using Aurora 2 (MySQL 5.7) from the snapshot
  3. Configure replication to the new cluster from the primary cluster

However, because you can't run commands that require SUPER user privileges in Aurora you're not able to stop transactions long enough to get a good binlog pointer from the master, which results in a ton of SQL errors that are impossible to skip on an active database.

Also, because Aurora is not doing binlog replication to its Read replicas I can't necessarily stop replication to that read replica and get the pointer.

I have seen this semi-related question, but it certainly requires downtime: How to upgrade AWS RDS Aurora MySQL 5.6 to 5.7

Ryan Eastabrook
  • 4,085
  • 5
  • 30
  • 35
  • We have since implemented a maintenance window and completed the upgrade while offline, which is unfortunate. It seems RDS Aurora would have a straight forward path for doing this? – Ryan Eastabrook Jul 22 '20 at 17:43

3 Answers3

2

UPDATE: AWS just announced in-place upgrade option available for 5.6 > 5.7: https://aws.amazon.com/about-aws/whats-new/2021/01/amazon-aurora-supports-in-place-upgrades-mysql-5-6-to-5-7/

Simple as Modify and choose version with 2.x. :)

I tested this Aurora MySQL 5.6 > 5.7 on a 25Gb db, many minor versions behind and it took 10 min, with 8 min of downtime. Not zero downtime, but a very easy option, and it can be scheduled in AWS to happen automatically during off-peak times (maintenance window).

Additionally consider RDS Proxy to reduce downtime. During small windows of db unavailable time (eg. reboot for minor updates), the proxy will hold connections open, instead of completely unavailable, simply appearing as a brief delay/latency, only.

user3185615
  • 41
  • 1
  • 5
2

Need was to upgrade the AWS RDS Aurora MySQL from 5.6 to 5.7 without causing any downtime to our production. Being a SaaS solution, we could not afford any downtime.

Background

We have distributed architecture based on micro services running in AWS Fargate and AWS Lambda. For data persistency AWS RDS Aurora MySQL is used. While there are other services being used, those are not of interest in this use case.

Approach

After a good deliberation on in place upgrade by declaring a downtime and maintenance window, we realized that having zero downtime upgrade is the need. As without which we would have created a processing backlog for us. High level approach was:

  1. Create an AWS RDS Cluster with the required version and copy the data from the existing RDS Cluster to this new Cluster
  2. Setup AWS DMS(Data Migration Service) between these two clusters
  3. Once the replication is done and is ongoing then switch the application to point to the new DB. In our case, the micro-services running in AWS Fargate has to upgraded with the new end point and it took care of draining the old and using the new.

For Complete post please check out

https://bharatnainani1997.medium.com/aws-rds-major-version-upgrade-with-zero-downtime-5-6-to-5-7-b0aff1ea1f4

Bharat
  • 201
  • 2
  • 9
0

When you create a new Aurora cluster from a snapshot, you get a binlog pointer in the error log from the point at which the snapshot was taken. You can use that to set up replication from the old cluster to the new cluster.

I've followed a similar process to what you've described in your question (multiple times in fact) and was able to keep the actual downtime in the low seconds range.

Jeff Wright
  • 181
  • 1
  • 8