AWS Aurora MySQL Manual Failover Instructions – Demote Writer instance to Reader instance

This article is for you if…

  • You are using Aurora MySQL on Amazon Web Services (AWS).
  • You have one Writer instance and one Reader instance.
  • You would like to perform a manual failover (so that your Writer instance is demoted to a Reader instance).

I needed to do this recently, but could not find clear instructions anywhere. Here are step-by-step instructions with screenshots.

  1. Login to your AWS Console
  2. Go to the RDS Console and select your Aurora MySQL Cluster
  3. Highlight your Aurora MySQL Writer Instance, choose Failover from the Actions menu

    Comment: Highlighting a specific instance may not be important. I believe if you have multiple Reader instances, the failover will use the “Failover priority” (e.g. “tier-0”, “tier-1”, … “tier-15”) to determine which Reader to promote to Writer. When I added a temporary 2nd Reader with “Failover priority” of “tier-0” and performed failover, that Reader was promoted to Writer. Please post a comment at the bottom of this page if you can confirm how failover is handled with multiple Reader instances! If the “Failover priority” is used to select which Writer instance will be promoted, please confirm if “tier-0” is indeed considered first when promoting a Reader to a Writer and I will update these instructions.

4. Confirm you would like to failover the cluster.

5. Go to the RDS Console and select your Aurora MySQL Cluster. The page will not show any changes for a few seconds.

6. Go to the RDS Console and select your Aurora MySQL Cluster (or refresh the page). Repeat until the page shows that the Writer instance has been demoted to a Reader instance.

7. Failover complete!

In my experience, the failover occurs within 10-15 seconds after submitting the failover request. Our application is aware of the separate reader and writer instances. We have not noticed any application read errors during the manual failover process. However, we have noticed temporary write errors during the failover process. Our application is designed to handle brief write failures and retry the writes, so this was not an issue.

Did you find this helpful? Let me know by sending me a comment. I tend to update and maintain posts more frequently if I know others find them helpful. Thanks for visiting!

Hosting Static Web Assets on S3 with CloudFront SSL

Follow this guide to host a static asset in an S3 bucket and deliver the asset to end users through CloudFront with the default SSL hostname (e.g. http://d29ob8ckmhh7kh.cloudfront.net/).

Follow the second section of this guide to configure S3 + CloudFront SSL with a custom domain name (e.g. https://example.logicforte.com/).

Pricing

CloudFront cost is based on traffic. We use a similar setup for low traffic websites at a cost of about $0.03-$0.08/month. We have not encountered any fixed or minimum fees related to CloudFront, SSL, S3. We do pay $0.50/month to host our DNS zone in Route 53, but that is not required for this configuration.

Benefits

Delivering S3 content via CloudFront has several advantages over serving directly from S3:

  • It is not currently possible to configure a custom SSL hostname when serving directly from S3.
  • If you have a high traffic website, serving assets from CloudFront is less expensive than serving directly from S3 since CloudFront bandwidth rates are currently lower than S3 bandwidth rates.

Hosting static assets on S3 and CloudFront with the default SSL hostname

S3 – Create bucket and upload file.

  1. Create S3 bucket “logic-example-cloudfront”. Accept defaults.
  2. Upload a file (e.g. sonic.png). Accept defaults.

CloudFront – Create WEB distribution with these settings

  1. Origin Domain Name: Choose your S3 bucket (e.g. “logic-example-cloudfront.s3.amazonaws.com”)
  2. Restrict Bucket Access: YES (optional, but recommended)
  3. Grant Read Permissions on Bucket Policy? YES
  4. Price Class: ONLY US, CANADA, EUROPE (other options can be expensive)

Lookup the default CloudFront URL on the EDIT distribution page

e.g. http://d29ob8ckmhh7kh.cloudfront.net/

Verify you can access your custom image via the default CloudFront URL

http://d29ob8ckmhh7kh.cloudfront.net/sonic.png

Hosting static assets on S3 and CloudFront with a custom SSL hostname

Certificate Manager (ACM) – Request a custom SSL certificate via these steps

  1. Request a Certificate
  2. Domain Name (e.g. “example.logicforte.com”)
  3. Validation – DNS Validation is recommended
  4. Confirm and Request
  5. Follow DNS validation instructions. (If hosting with Route 53, click “Create Record in Route 53” button. Validation will complete almost immediately.)

CloudFront – Update settings for your existing WEB distribution

  1. GENERAL – Alternate Domain Names (CNAMEs): (e.g. “example.logicforte.com”)
  2. GENERAL – Custom SSL Certificate: Select Certificate created in ACM above (e.g. “example.logicforte.com”)
  3. GENERAL NOTE: Be sure you do NOT change the setting for “Custom SSL Client Support” from FREE (aka SNI) to $600/month (aka dedicated IP address). Our hosting company moved all customer websites to SNI in mid-2017. Those websites receive millions of visits per month and have not had any of their customers or end users report problems.
  4. BEHAVIOR – Viewer Protocol Policy: Redirect HTTP to HTTPS

Route53

  1. Create CNAME record (e.g. “example.logicforte.com”) that points to the “Domain Name” of your CloudFront WEB distribution (e.g. “d29ob8ckmhh7kh.cloudfront.net”).

Verify you can access your custom image via your custom CloudFront URL

https://example.logicforte.com/sonic.png

PRO TIP: It can take CloudFront 30+ minutes to deploy changes. If you request your custom SSL certificate from ACM and validate the request before you create your CloudFront WEB distribution, you can configure the CloudFront SSL settings when you initially create your CloudFront WEB distribution.