Move an instance

This page describes moving an instance in Spanner.

You can move your Spanner instance from any instance configuration to any other instance configuration, including between regional and multi-region configurations. Moving your instance does not cause downtime, and Spanner continues to provide the usual transaction guarantees, including strong consistency, during the move.

Why move your Spanner instance?

Benefits of moving your instance include:

  • Increase availability: Obtain 99.999% availability with zero downtime after performing a regional to multi-region move.
  • Reduce latency: Reduce latency and increase geographic coverage with additional read-only replicas through a regional to multi-region or multi-region to multi-region move.
  • Reduce cost: Reduce hourly costs by moving from a multi-region configuration to a regional configuration.
  • Colocate database: Colocate the Spanner database with the client application by moving the instance to a more optimized location.

Pricing

When moving an instance, both the source and destination instance configurations are subject to hourly compute and storage charges. Once the move is complete, you are billed for the instance storage at the destination configuration.

If you are moving your instance to a new regional or multi-region instance configuration, you might be subject to outbound data transfer charges. For more information, see Spanner Pricing.

Limitations

  • To move your instance, it must have a minimum of 1 node (1000 processing units).
  • You cannot move your instance across projects and Google Cloud accounts.
  • You cannot move a Spanner free trial instance. You can move the instance after upgrading to a paid instance.
  • If you have active requests using a regional service endpoint on any of the instance resources, the instance move impacts all the requests that are using the regional endpoint because regional enforcement blocks access to cross region instances. Requests that use a global endpoint are unaffected.
  • Spanner backups are specific to an instance configuration and are not included when moving an instance. See Backups in the source instance configuration for more information.
  • The following APIs are disabled during an instance move:
    • InstanceAdmin.DeleteInstance
    • InstanceAdmin.UpdateInstance
    • DatabaseAdmin.CreateDatabase
    • DatabaseAdmin.UpdateDatabaseDdl (Disabled if default_leader is specified in the request.)
    • DatabaseAdmin.RestoreDatabase
    • DatabaseAdmin.CreateBackup
    • DatabaseAdmin.CopyBackup
  • You cannot move instances that contain any CMEK-enabled databases.
  • If a database has a modified default leader, the selection is preserved if it names a read-write region in the destination instance configuration, and that configuration is multi-region. If the destination configuration is regional, or doesn't include the named read-write region, the default leader selection is cleared.
  • Moving an instance changes the instance configuration attribute of your instance. If you manage your Spanner resources through automation, make sure to prepare and address any inconsistencies that might arise.
    • For example, if you use Terraform to manage your Spanner instances and databases, and you enable terraform apply --auto-approve to keep your resources in sync, all instances and child resources are deleted when we move the instance. Update the configuration accordingly to avoid deletion and data loss. See Terraform Apply Options for more information about the apply command.
  • While the instance is being moved, the Spanner monitoring metrics and charts might show data in both the source and destination instance configurations, or it might only reflect performance in one instance configuration.
  • If you've configured the open source Autoscaler tool, then you don't need to disable it. It fails because InstanceAdmin.UpdateInstance (used for node and processing unit changes) is disabled.
  • You can't move an instance if the Spanner managed autoscaler feature is enabled on it. To move the instance, you need to disable the managed autoscaler, move the instance, and then re-enable the managed autoscaler.

Performance considerations

When an instance is being moved, it experiences higher read-write latencies and a higher transaction abort rate. The CPU utilization during the move might go up to 100% because the instance move is performed using spare CPU provisioned by the user. However, moving an instance does not cause any downtime. The time it takes to move an instance depends on various factors including the size of the databases, the number of nodes, and the kind of move (e.g., regional to multi-region).

After moving an instance, the performance of the instance varies depending on the details of the instance configuration. For example, multi-region configurations generally have higher write latency and lower read latency than regional configurations.

How to move an instance

You can move an instance configuration by using the Google Cloud console. First, you are asked to fill an instance move request form. Then, the Spanner team follows up with the start date of the instance move. Note that moving an instance does not change the name, ID, or project ID of the instance.

Prerequisites

Before making a request to move your instance configuration, make sure you have read the Limitations and Performance considerations sections. Then, follow these steps:

  1. Check that you have the spanner.instances.update IAM permission on the source instance.
  2. Add a resource label to the instance to be moved. The key for this label is "move-to", and the value is the name of the destination instance configuration (e.g. "us-east4"). For more information, see Label an instance.
  3. If applicable, request moving your non-production instances (e.g., test and staging) before moving your production instances to help assess and understand the performance impact on workloads during an instance move.
  4. When you move a Spanner instance, the moving process deletes the instance tags that you created in Data Catalog. To preserve your tags, you need to export your tags before the move and import them after the move. For more information, see Export and import tags.

For best practices, also follow these guidelines:

  • Test performance workloads in non-production instances in the destination instance configuration first before moving your production instance.
  • Check that there are no hotspots in your databases using the Key Visualizer.
  • Review to ensure that you have enough node quota in the destination instance configuration to support the expected peak usage of the instance. For more information, see Spanner Quotas & Limits.

  • Make sure the peak CPU utilization of your instance is within the maximum thresholds recommended for the type of instance configuration to which you want to move your source instance configuration.

    Additionally, if you're using autoscaling, you must provision enough nodes for peak CPU usage according to the maximum recommendations noted, and then disable autoscaling before you move the instance.

  • Don't make changes to the instance during the migration. This includes changing the instance node count, changing database schemas, creating or dropping databases, or creating or deleting backups.

Move an instance

Console

  1. Go to the Spanner Instances page in the Google Cloud console.

    Go to the Instances page

  2. Click the name of the instance you want to move.

    The Google Cloud console displays the instance's Overview page.

  3. Click Edit instance.

  4. To schedule moving to a new instance configuration, click Contact Google and complete the Spanner Instance Move Request form.

    After the form is submitted, Google contacts you with the start date of the instance move.

Backups in the source instance configuration

When you move a Spanner instance configuration, the backups in the source instance are not moved to the new destination configuration automatically. It is important that you copy your backups and consider your data recovery plan before moving your instance configuration.

If there are backups in your source instance that are needed, you must first copy your backups to another instance with the same instance configuration as the source instance to be moved. After you have copied your backups to another instance, you must delete any existing backups in the source instance before you can move the instance configuration to a new instance configuration. Google does not move your instance if backups exist in the source instance configuration at the scheduled time of the instance move. We recommend that you copy your backups as close to the move date (notified by Google) as possible.

To learn more about copying backups and associated costs, see Copy a backup.

What to do after submitting your move request

After an instance move request is made, Google contacts you to let you know the start date of the instance configuration move. In general, we expect to respond to all move requests within two business days.

After you receive a move date confirmation from us, tell all relevant parties about the move date and get ready to copy any backups you would like to keep.

What's next