At foodora we recently switched our production RDS from mysql to Aurora. With this article we share how we did it and what we learned.

Why Aurora?

If you have been at any AWS event in the last 2 years you will have noticed that AWS is advertising Aurora like crazy. Even I couldn’t help myself as you see with the header image. “Faster, more scalable, more robust, cheaper and mysql compatible” actually sounds too good to be true. Since RDS is the biggest bottleneck and most expensive part of our infrastructure, we wanted to give it a try.

Migration

We first switched our TEST and shortly after our STAGING environment to Aurora according to the official migration guide provided by AWS. In particular the steps have been:

  • Create a Read Replica
  • Wait for the replica lag on the Aurora Read Replica to reach 0
  • Disable the security group for the old MySQL server
  • Promote Aurora Read Replica to master
  • When done change Route53 CNAME to Aurora cluster endpoint (we use a CNAME to reach the MySQL server)
  • Enable security group again

The operation took a couple of minutes and afterwards, nobody noticed any difference, problems or improvements… until we also switched live a few weeks later using the very same steps.

Impact

As you see in the following chart with Aurora the RDS performance drastically improved. While Reads perform similar to before, Writes are much faster and less responsive to load increases:

aurora_speed

 

Please be aware that we also changed the DB size, just to not take risks during this switch:

  • before: RDS mysql, db,r3.2xlarge with ~75% peak CPU load; $1574 per months in Frankfurt
  • after: RDS aurora, db,r3.4xlarge with ~27% peak CPU load; $3189 per months in Frankfurt (or $2061 after shrinking back)

(As soon as we decide to shrink back the RDS, I will post an update.)

References

Posted by on 1 Aug 2017

Head of Platform Engineering @ foodora

Leave a Reply