10
Always On Zero Downtime releases for systems with relational databases @anderslundsg ard

Always On - Zero Downtime releases

Embed Size (px)

Citation preview

Page 1: Always On - Zero Downtime releases

Always OnZero Downtime releases

for systems with relational databases

@anderslundsgard

Page 2: Always On - Zero Downtime releases

Always On• What?

– New versions of system components deployed at any time without causing downtime for the end user

 • Why?

– Enables Fast turnaround time– Production deployments can be made at any time. Preferably in office hours

when the contributors are present.

• How?– Automated deployment– Load balanced deploy for webservers– Database changes should be independent on application version

Page 3: Always On - Zero Downtime releases

Pre-requirements for Always On• A desire to increase quality and long term

maintainability• A desire to reduce the time between production

deploys• Versioning of code and database scripts• Tooling for automated deployment– Special tooling for relational databases is a must

Page 4: Always On - Zero Downtime releases

How?The deployment of web and database servers

Page 5: Always On - Zero Downtime releases

Decoupling database and webserver installations Traditional

App

(C#, Java) v.98

SQL v.98

App

(C#, Java) v.99

SQL v.99

App

(C#, Java) v.100

SQL v.100

SQL v.101

App

(C#, Java) v.101

Page 6: Always On - Zero Downtime releases

Decoupling database and webserver installations Decoupled

App

(C#, Java) v.98

App

(C#, Java) v.99

App

(C#, Java) v.100

App

(C#, Java) v.101

SQL v.25

SQL v.26

SQL v.27

SQL v.28

SQL v.29

SQL v.30

SQL v.31

SQL v.32

Page 7: Always On - Zero Downtime releases

Database server

Web1

Web2

Load balancer

End users don’t experience any downtime

1. Bring down web server #1 from load balancer

2. Install new version of application on server #1

Updating the web servers

3. Toggle the load balancer

4. Install new version of application on server #2

5. Activate load balancer

Page 8: Always On - Zero Downtime releases

Database server

Web server

1. Add new schema2. Write to both schemas3. Backfill historical data4. Read from new schema5. Remove writes to old schema6. Remove old schema

End users don’t experience any downtime

Updating the database

Read Write

Probably after days or weeks

Page 9: Always On - Zero Downtime releases

What does this mean to me?• It’s easy!– A database change should always be

backward compatible with the old code

• Example of what is not doable– Changing a stored procedure so that it changes its interface (in

and out parameters)• Solution: Create a new version of the stored procedure

– Migrate data to a new structure that is dependent on new data access• Solution: Have parallel writes/reads

Page 10: Always On - Zero Downtime releases

@anderslundsgard

Questions?