Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Always On - Zero Downtime releases


Published on

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

  • Be the first to comment

Always On - Zero Downtime releases

  1. 1. Always On Zero Downtime releases for systems with relational databases @anderslundsgard
  2. 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. 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. 4. How? The deployment of web and database servers
  5. 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. 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. 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. 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. 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. 10. @anderslundsgard Questions?