Jump to: navigation, search

NoDowntimeDBMigrations

Revision as of 15:14, 24 July 2013 by Johannes Erdfelt (talk | contribs) (Created page with "=== Problem Description === Database migrations in Openstack currently require services are stopped before the migrations are run. This is because code currently assumes a fi...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Problem Description

Database migrations in Openstack currently require services are stopped before the migrations are run. This is because code currently assumes a fixed schema.

In the past, some migrations have shown to take a significant amount of time run on large installations, causing unacceptable amounts of downtime.

As Openstack installations continue getting larger and larger, these long downtimes will continue getting worse and worse. If an Openstack provider guarantees 99.99% uptime, that leaves only 4 minutes total per month for all downtime (planned or unplanned). Some database migrations in the past have taken hours to run on large installations.


Proposed Solution

Embrace the Expand/Contract pattern for database migrations. This pattern splits database migrations into three parts:

  1. Expand schema (adding new columns)
  2. Migrate data
  3. Contract schema (removing unused columns)

Code would migrate data on load when the service is running. Optionally, a background task can migrate all data at whatever speed specified. When all data that needs to be migrated has been migrated, the contraction can be run which will remove unused columns.

This decouples the database schema from the code allowing the two to be updated independently and allowing the service to continue running transparently while the data is migrated.