Migrating a Database
While it is possible for a project’s compute instances / servers to access a Database instance in a different availability zone (AZ), this will incur a performance penalty for database requests due to the longer network paths and other reasons. It is therefore advisable for a Database instance and the compute instances that use it to be in the same AZ.
(Note: This article is only relevant to Database instances launched and managed using the Nectar / OpenStack Database service. If you have set up a regular Nectar instance (server) and installed a database on it, then you need to follow the top-level Migrating an Instance instructions.)
There are a couple of possible ways of migrating a database managed using the Database service, but we recommend that you use the Database service’s backup facility to do this.
You will need quota for the new Database instance and storage, and sufficient object storage quota to hold the database backup that you will use for migration.
Migrating a single Database instance
Note that, the following just covers the migration of the Database instance itself.
Disable any application services that access or update the old Database instance.
(Note that there isn’t a way for you to “shut down” a Database instance. Even blocking access via the database security groups will only block new connections, not connections that are already established.)
Create a new Database instance from the backup in the new AZ.
Set up the new Database instance’s security groups, root access and so on to mirror the old instance.
Verify that everything is OK.
Wait. It is advisable to keep the old Database instance for a few days in case it is needed to roll back the migration of services that depend on it.
Delete the old Database instance and backup.
Migrating a Database cluster
We are not aware of anyone using the OpenStack Database clustering capability in Nectar “for real”. If you need advice on migrating a Database cluster, please contact Nectar Support.