0f0354a8b8
The parent of this patch introduced the change to Alembic-based migrations. This commit builds on top of that by adding expand, migrate and contract commands to the glance-manage tool. Appropriate documentation is updated and failing tests are adjusted to accomodate the new database versioning schema. Data migrations are expected to be run in the background with older Glance services being active during the upgrade process. Partially-Implements: blueprint database-strategy-for-rolling-upgrades Co-Authored-By: Hemanth Makkapati <hemanth.makkapati@rackspace.com> Change-Id: Ie839e0f240436dce7b151de5b464373516ff5a64 Depends-On: I77921366a05ba6f9841143af89c1f4059d8454c6
4.1 KiB
Database Management
The default metadata driver for Glance uses sqlalchemy, which implies
there exists a backend database which must be managed. The
glance-manage binary provides a set of commands for making
this easier.
The commands should be executed as a subcommand of 'db':
glance-manage db <cmd> <args>
Sync the Database
glance-manage db sync [VERSION]
Place an existing database under migration control and upgrade it to the specified VERSION or to the latest migration level if VERSION is not specified.
Note
Prior to Ocata release the database version was a numeric value. For
example: for the Newton release, the latest migration level was
44. Starting with Ocata, database version will be a
revision name corresponding to the latest migration included in the
release. For the Ocata release, there is only one database migration and
it is identified by revision ocata01. So, the database
version for Ocata release would be ocata01.
However, with the introduction of zero-downtime upgrades, database
version will be a composite version including both expand and contract
revisions. To achieve zero-downtime upgrades, we split the
ocata01 migration into ocata_expand01 and
ocata_contract01. During the upgrade process, the database
would initially be marked with ocata_expand01 and
eventually after completing the full upgrade process, the database will
be marked with ocata_contract01. So, instead of one
database version, an operator will see a composite database version that
will have both expand and contract versions. A database will be
considered at Ocata version only when both expand and contract revisions
are at the latest revisions possible. For a successful Ocata rolling
upgrade, the database should be marked with both
ocata_expand01, ocata_contract01.
Determining the Database Version
glance-manage db version
This will print the current migration level of a Glance database.
Upgrading an Existing Database
glance-manage db upgrade [VERSION]
This will take an existing database and upgrade it to the specified VERSION.
Expanding the Database
glance-manage db expand
This will run the expansion phase of a rolling upgrade process. Database expansion should be run as the first step in the rolling upgrade process before any new services are started.
Migrating the Data
glance-manage db migrate
This will run the data migrate phase of a rolling upgrade process. Database migration should be run after database expansion and before database contraction has been performed.
Contracting the Database
glance-manage db contract
This will run the contraction phase of a rolling upgrade process. Database contraction should be run as the last step of the rolling upgrade process after all old services are upgraded to new ones.
Downgrading an Existing Database
Upgrades involve complex operations and can fail. Before attempting any upgrade, you should make a full database backup of your production data. As of Kilo, database downgrades are not supported, and the only method available to get back to a prior database version is to restore from backup[1].
[1]: http://docs.openstack.org/ops-guide/ops-upgrades.html#perform-a-backup