About SRGTechnical articleRecruitment Information
About SRGTechnical articleRecruitment Information
⚠️⚠️⚠️ STG SRG Portal ⚠️⚠️⚠️/Technical article/Trying out the B/G Deploy feature available on Amazon Aurora

Trying out the B/G Deploy feature available on Amazon Aurora

This is Onikai (@fat47) from the Service Reliability Group (SRG) of the Technology Division.
#SRGThe Service Reliability Group primarily provides comprehensive support for the infrastructure surrounding our media services, focusing on improving existing services, launching new ones, and contributing to open-source software (OSS).
This article is located within SRG.DBWGThe DB Working Group is releasing database-related materials that it provides to the entire company.
I hope this is of some help.
 

What is the B/G Load function?

These are new features available for RDS and Aurora, which were announced at the recent Re:Invent 2022.
New – Fully Managed Blue/Green Deployments in Amazon Aurora and Amazon RDS
The document isHere
 
I think this article from Classmethod is well-organized and easy to understand.
[Shocking] AWS RDS now supports Blue/Green deployments that don't result in data loss.
 
To summarize the flow of the functions:
  • You can easily create a mirrored environment (Green) from the production environment (Blue) directly from the console.
  • Logical replication is established between the Blue and Green channels, so updates are synchronized.
  • You can switch between Blue and Green from the console.
  • The endpoint that the application sees does not need to be changed; only the destination within the endpoint changes.
  • During switching, both B/G write blocks are active.
  • If the background/green light switch is not completed within the specified time, it will automatically revert back.
  • The Blue environment remains as a standalone environment after the switchover.
 
Conceptual diagram of the overall structure
[AWS公式ドキュメントから画像引用]
[Image quoted from official AWS documentation]

Please note

The following may cause the system to become unstable:
We have already reported this case to AWS and they are investigating it.
💡
Known Issues: - If the Source instance size is t3.small, the B/G environment setup stops midway. - If the Source cluster has 2AZ subnets, the B/G environment setup stops midway.

B/G environment setup procedure

This time, we'll test upgrading the MySQL version using B/G.

Enable binary logging on clusters that show as Blue.

Set "binlog_format" to MIXED or ROW in the DB cluster parameter group.
Please note that restarting the instance will be required for the changes to take effect.

Creating a Green Environment

ブルー/グリーンデプロイの作成
 
Create it by specifying the identifier and engine version of the environment that will be green.
 
Once creation is complete, it will be labeled as Blue/Green like this.

Try switching between B/G while writing to the blue environment every second.

Let's create a suitable table on the Blue side and switch between B and G while inserting data every second.
 
切り替え
 
A confirmation screen will appear displaying information for both B and G.
You can set the timeout period here. If the switchover is not completed within this time,
The setting will not be switched and will be reverted to its original state.
切り替え
 
This notification is displayed during the transition.
 
Looking at the logs of the script that was writing every second during the switch,
First, the Blue environment becomes Read Only and writing is blocked.
It appears that writing resumed approximately 2 minutes after the connection failed.

thoughts

I found it very convenient that what used to require manually setting up a separate cluster and configuring binary log replication can now be done with a single button click on the console.
The official announcement states that the switchover will be completed within one minute, but I experienced connectivity issues for about two minutes, so further investigation is needed to determine if this is due to using a t3.medium instance.
 
Personally, I think it would be great if the B/G rollback function could be applied even after the B/G switch was successfully completed. This is because problems sometimes arise some time after a version upgrade, requiring a rollback.
However, in that case, it would require a deprecated replication process going back in time from Aurora v3 to Aurora v2, so I think it might be difficult to implement.
 
This B/G feature is now generally available, but it's still marked as "(Beta)" on the console, so I'm looking forward to its future improvements.
Although I didn't test it this time, I think that if the restrictions on ALTER for Green environments were looser, it would become more practical in many situations.

In conclusion

SRG is looking for new team members! If you're interested, please contact us here!