Overview

AWS RDS Blue/Green Deployment provides a streamlined solution for migrating databases with minimal downtime. The Blue/Green deployment model enables the creation of a duplicate RDS environment (Green), where updates can be tested before switching traffic from the current environment (Blue) to the new one.

This document will walk through the process of creating a Blue/Green deployment for AWS RDS and executing database migrations on the Green environment before switching traffic. We’ll also cover rollback strategies if issues arise.

This is is why a Blue/Green deloyment approach is suitable when we try operations that might cause the interruption of our service, like:

• Upgrading the db engine

• Changing databases or tables with the ALTER statement

• Running large and complex queries

How Blue/Green works?

Blue/Green deployment is about considering the original database as the Blue, then we create a copy named Green, all changes made to the Blue are replicated though logical replication, so all new data written into Blue, will be present in Green as well. The key concept here is that we can perform any sort of operations on Green without the risk of messing things up.

We can perform engine upgrades, or run large time-consuming alter statement without risk of locking the table (actually, the green table might be locked, but the blue one is safe, the replication will catch up when green table is unblocked again)

Finally when changes are done and we want to send traffic to the Green database, we can perform a database renaming, in order to use the Green as the new current production database (here we preserve the DB endpoint, so no changes are needed in the app side)

Blue/Green Architecture

AWS RDS has a feature called Blue/Green Deployment which facilitates the process of :

1. Creating the Green Environment

2. Setting up the replication

3. Performing the switchover

This are the steps to use this feature effectively:

Parameter Configuration

First we need to tweak the configuration on the binlog replication

On the current production database, ensure you have sufficiently large binlog retention. I recommend a minimum of 24 hours

If this is unset or has a lower value, we can correct that with the following:

CALL mysql.rds_set_configuration('binlog retention hours', 24);

If using a default parameter group, we need to create a custom one, since binlog changes are required:

• binlog_format to ROW

• binlog_checksum to None

Since binlog_format parameter is a static one, we also need to reboot the instances to take effect.

Creating the Blue/Green Environment

Once every parameter is configured, the next thing is to create, this is the easiest part since AWS facilitates it with a single button:

This will guide us to a form where we can name our Blue/Green Deployment, specify the green engine version and the parameters groups

AWS Creating the Blue/Green environment

This feature gives us the endpoint to connect to the green database, there we can run any query

Once we are done, we can do the switch from the console, select the Blue/Green Deployment -> Actions -> Switch over

Conclusions

Now Database migrations seems a fairly easy task, I would like to mention some use cases other than migration:

• Running large queries using real production data, but without affecting production workload

• Generate a production-wise environment to let teams testing app changes

And remember, if Green turns “dirty” or the replication stops, we can always delete it and recreate it from scratch.

---

Stay Tuned!

Be sure to follow and subscribe for more updates and upcoming blogs.