Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to handle data changes in Blue/Green deployment technique?

I have studied this article about Blue/Green deployment, then some more googling introduced me to this article about Canary Release. I have this ambiguity : what will happen to databases? how we should make them synchronized? i have two possible scenarios in mind :

  • imagine there are two separate databases one for each environment
    (green and blue) at the time that blue is active, new records will be inserted into it's database and green is not aware of these changes
    unless we provide a trigger like mechanism(or any other mechanism) to update the green database.
  • second scenario suggests that we share a backward compatible database between two environments, but backward compatibility is not so easy
    when dealing with databases, we have to publish database changes
    before publishing the application.

there may be third scenario, implement a Blue/Green deployment for databases inside the main Blue/Green deployment.

what do you think is the better solution and why? do you suggest any other practice or well known pattern ?

thank you

like image 639
MoienGK Avatar asked May 10 '15 14:05

MoienGK


People also ask

What is a blue green deployment database?

Blue-green deployment is a release management technique that reduces risk and minimizes downtime. It uses two production environments, known as Blue and Green, to provide reliable testing, continuous no-outage upgrades, and instant rollbacks.

How do you avoid downtime during deployment?

A Blue-Green deployment is a relatively simple way to achieve zero downtime deployments by creating a new, separate environment for the new version being deployed and switching traffic into it. A rollback happens just as easily, with a traffic switch to the old version.


1 Answers

I have personally only worked with the backwards-compatible databases approach. The main benefit is that it well understood and works for a wide variety of deployment types, including canary and blue-green; I have used that approach even without the benefit of a blue-green deployment strategy (the mundane rolling deployment to all servers, which is essentially a fast canary deployment). Having to deploy database changes before application releases is common to several deployment strategies not that burdensome compared to the need for complicated triggering or mirroring mechanisms between different database versions.

Your third scenario also falls into the trap of needing triggering or mirroring between the database slices as well. In RDBMS terms, this is typically unsupported or completely impossible because there is only master database and all other instances do not accept write operations. The net effect of this is that the version of the master instance is the de-facto version of the whole database.

Certain No-SQL databases do not fall into this trap. For instance, MongoDB will happily allow multiple, different versions of document schemas in the same collection. This allows your application to be informed of the data version and handle the documents differently. However, MongoDB is not appropriate for all applications (just like an RDBS is not the right data store for certain types of data).

like image 63
Patrick M Avatar answered Sep 28 '22 17:09

Patrick M