A lightning talk about how to achieve no downtime when updating a system with relational database as back end storage.

1. Always On
Zero Downtime releases
for systems with relational databases
@anderslundsgard

2. 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

3. 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

4. How?
The deployment of web and database servers

5. 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

6. 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

7. 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

8. Database server
Web server
1. Add new schema
2. Write to both schemas
3. Backfill historical data
4. Read from new schema
5. Remove writes to old schema
6. Remove old schema
End users don’t experience any downtime
Updating the database Read Write
Probably after days or weeks

9. 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

10. @anderslundsgard
Questions?