As a DevOps engineer, you will find yourself optimizing and tinkering the RDS databases powering your workloads, you probably know the struggle with updating databases especially if you have heavy workloads depending on them. The risk of experiencing downtime during production is high. Traditional database management often leads to a catch-22 situation where you want to update your database for better performance but fear database downtime.
Well, worry no more! In this article, we will explore the AWS Blue/Green Deployment method that allows you to change your Relational Database Service (RDS) with zero downtime. Yes, you read that right: ZERO downtime, and it works like magic!
From explaining the Blue/Green Deployment strategy to providing a step-by-step guide on how you can utilize this in AWS, this article covers everything you need to know when updating your RDS database instance without compromising availability.
So, let's dive straight in!
Preparation
You need to identify a time when your dev team will not be performing any releases and also an ideal time when you have the least traffic on your workloads.
It's a good DevOps practice to notify the larger team of what time you schedule to perform such changes.
I will demonstrate downscaling DB's instance storage volume in this case while using Blue/Green deployment with zero downtime.
The same exercise can be achieved using either
- AWS RDS Console
- AWS CLI
- AWS SDK
For our exercise, we will use the AWS RDS Console
NB Before performing Blue/Green deployments for either a MySQL or Mariad-based RDS instance, please enable automated backups link
Step 1
For our demo, we will scale the storage space from 400 GB to 200 GB. Our database cluster is made up of a master and 3 replicas as shown below.
- Select the master database from the cluster
- Click on actions then click on Create Blue/Green Deployment from the drop-down menu to open the "Blue" screen
Step 2
We need to create a copy of the production environment, here referred to as the Blue environment to a staging environment referred to as Green
Give your Blue/Green deployment an identifier name, remember the identifier is case-insensitive, but is stored as all lowercase.
Step 3
The next step is configuring the Blue/Green deployment by specifying the ideal database engine and the parameter group for your Green environment.
For our case, since we are interested in downsizing the storage size, we will use the same engine version and parameter group as the Blue environment (Production DB)
Step 4
This step entails configuring your Green instance database type; for our case, we will use use the same instance as Blue.
Step 5
Our main task is focussing on downsizing the allocated storage for the Green deployment.
The configuration update on AWS console will be done on one screen and will be replicated across the entire database cluster.
Remember we are scaling down storage for the master database and it's 3 replicas as shown in the figures below.
- Side-by-side view of the Blue and Green master Deployments highlighting the updates.
- Side-by-side view of the Blue/Green database replicas highlighting the changes made
Once you confirm all is looking good, a few things to note at this stage is that the cost of the Green deployment will be shown before you hit the create button.
Blue/Green will take anything between a few minutes to hours, this is dictated by factors such as the size of the database, how busy the workloads running off the database are, and the number of replicas.
For our case, it took about 5 hours for the Green deployment to be ready and it worked like magic.
Zero downtime, only a bit of lag on the Primary cluster (Blue) environment.
A lot of the magic happens under the hood, AWS handles renaming the Green deployment's DB cluster naming convention to match Blue environment, including updating the Endpoints for the Master and Replicas.
You won't need to update your application's configuration, the most I did is notifying the dev team via Slack about this exercise.
Top comments (0)