Migrate to Multi-Region SQL

This page describes how to migrate a multi-region cluster from using replication zones to using multi-region SQL abstractions.

Overview

If you are already using to control your multi-region cluster, you can ignore this page.

CockroachDB v21.1 added support for . Using high-level SQL statements, you can control where your data is stored and how it is accessed to provide good performance and tunable latency for your application’s users. Prior to v21.1, the only way to accomplish these goals in a multi-region cluster involved using lower-level mechanisms called in specific patterns called Duplicate indexes, Geo-partitioned replicas, and Geo-partitioned leaseholders. These patterns and the use of replication zones are still fully supported. However, for most users, they are harder to use and in some cases can result in worse performance than the multi-region SQL abstractions. This page discusses:

Mappings from each of the legacy replication-zone-based patterns to the multi-region SQL abstractions that are designed to replace them.
Instructions for migrating from replication-zone-based workflows to multi-region SQL abstractions.
A review of the underlying zone configuration changes that result from running the multi-region SQL statements.

Replication zone patterns and multi-region SQL abstractions

Replication Zone Pattern	Multi-Region SQL
Duplicate indexes
Geo-partitioned replicas	with
Geo-partitioned leaseholders	with

CockroachDB will no longer provide the pattern’s behavior for a database if you use the with that database. In other words, the multi-region SQL statements do not provide a behavior that is analogous to Follow-the-Workload.

For more information about how to use ZONE vs. REGION survival goals, see . For more information about when to use GLOBAL vs. REGIONAL tables, see .

How to migrate a database to the multi-region SQL abstractions

The following instructions assume that you will re-use your existing (that is, regions added during cluster setup using ).

Performance considerations

Expect performance to be temporarily affected by this process. When you run the commands described below, the cluster may need to do a significant amount of work to meet the new replica placement constraints it has just been given. Therefore, we recommend running this procedure at a time when you would normally perform scheduled maintenance. Depending on how long you are willing to wait between steps for the replica rebalancing process to settle down, data movement may still be occurring when the next set of constraints is added using the multi-region SQL abstractions; this may lead to further data movement. In other words, the process described here may result in a significant increase in CPU usage, IOPS, and network traffic while the cluster rebalances replicas to meet the final set of constraints you have provided it with. Until this process completes, the cluster may not be able to handle its normal workload. Note that the process of dropping the old zone configs that occurs when the old configurations are removed must be complete before you can and set . You can ensure this process is complete by waiting for the statement shown below to finish successfully. For a tutorial that shows how to transition a database to using multi-region SQL statements, see .

As part of this migration, data may move temporarily out of the geography where you have constrained it to be placed. For more information about CockroachDB’s support for data domiciling, see .

Step 1. Remove the old replication zone configurations

Depending on which you are migrating from, the procedure will vary. For instructions showing how to remove the existing zone configuration for each pattern, see below.

Duplicate indexes
Geo-partitioned leaseholders
Geo-partitioned replicas

You can check the state of any schema object’s replication zone configuration at any time using .

Duplicate indexes

If you used the duplicate indexes pattern, the steps for backing out the old configuration are:

Remove the replication zone configurations you added using the statement. Note that this will remove all zone configurations from the table. If you had any additional customizations beyond what are required for the duplicate indexes pattern, you will have to reapply them.
ALTER TABLE postal_codes CONFIGURE ZONE DISCARD;
Drop the extra indexes you added. This will have the side effect of also deleting the zone configurations you added to those indexes.
DROP INDEX postal_codes@idx_central; DROP INDEX postal_codes@idx_east;

The latency and resiliency benefits of the duplicate indexes pattern can be replaced by making postal_codes a with a that meets your needs.

Geo-partitioned replicas

If you applied the geo-partitioned replicas pattern, the steps for backing out the old configuration are:

Remove the manually created table partition. This will also automatically remove the replication zone configurations that were applied to the partition as part of the instructions.
ALTER TABLE users PARTITION BY NOTHING;
Remove the manually created partition on the secondary indexes. This will also automatically remove the replication zone configurations that were applied to the partition as part of the instructions.
ALTER INDEX users_last_name_index PARTITION BY NOTHING;

The latency and resiliency benefits of the geo-partitioned replicas pattern can be replaced by making users a with a .

The multi-region SQL abstractions use a hidden column to represent the row’s home region. You may need to modify your existing schema to take this into account. For example, if you already have a column you are using to denote each row’s home region, you can use that name instead of crdb_region by following the instructions on the page.

Geo-partitioned leaseholders

If you applied the geo-partitioned leaseholders pattern, the steps for backing out the old configuration are:

Remove the manually created table partition. This will also automatically remove the replication zone configurations that were applied to the partition as part of the instructions.
ALTER TABLE users PARTITION BY NOTHING;
Remove the manually created partition on the secondary indexes. This will also automatically remove the replication zone configurations that were applied to the partition as part of the instructions.
ALTER INDEX users_last_name_index PARTITION BY NOTHING;

The latency and resiliency benefits of the geo-partitioned leaseholders pattern can be replaced by making users a with a .

Step 2. Add a primary region to your database

The steps from this point forward assume that you have cleared your prior replication zone configurations and will be using the to work with a cluster that has existing . Every multi-region database needs to have a primary region. To set the primary region, issue the statement:

ALTER DATABASE foo SET PRIMARY REGION = "us-west1"

Step 3. Add more regions to the database

To add another region to the database, issue the statement:

ALTER DATABASE foo ADD REGION "us-central1";

Step 4. (Optional) Configure your database survival goal

Depending on your desired database , you can choose from the following settings:

(Default): the database will remain fully available for reads and writes if one zone in a region goes down. More than one zone going down concurrently may affect availability.
: the database will remain fully available for reads and writes if one region goes down. More than one region going down concurrently may affect availability.

For example, to set a region survival goal, issue the following SQL statement:

ALTER DATABASE foo SURVIVE REGION FAILURE;

For more information about when to use ZONE vs. REGION survival goals, see .

Step 5. Configure table localities

For each table in your database, apply the that provides the latency and resiliency requirements you need for that table. As described in Replication zone patterns and multi-region SQL abstractions, the mapping from legacy replication zone patterns to multi-region SQL abstractions is:

Replication Zone Pattern	Multi-Region SQL
Duplicate indexes
Geo-partitioned replicas	with
Geo-partitioned leaseholders	with

For example, to configure the postal_codes table from the duplicate indexes example to use , you would enter the following statements to make the postal_codes table a :

ALTER TABLE postal_codes SET LOCALITY GLOBAL;

For more information about when to use GLOBAL vs. REGIONAL tables, see .

Step 6. (Optional) View the updated zone configurations

The multi-region SQL statements operate on the same replication zone configurations that you have access to via the statement. If you are interested in seeing how they work with the lower-level zone config mechanisms, you can use the statement to view the zone configurations. For example, given a multi-region demo cluster set up using the instructions in , here is what the zone configs for several tables in the look like.

Regional by row tables

A table differs from the default by setting the following zone configuration settings:

SHOW ZONE CONFIGURATION FROM TABLE users;

     target     |                                      raw_config_sql
----------------+-------------------------------------------------------------------------------------------
  DATABASE movr | ALTER DATABASE movr CONFIGURE ZONE USING
                |     range_min_bytes = 134217728,
                |     range_max_bytes = 536870912,
                |     gc.ttlseconds = 90000,
                |     num_replicas = 5,
                |     num_voters = 3,
                |     constraints = '{+region=europe-west1: 1, +region=us-east1: 1, +region=us-west1: 1}',
                |     voter_constraints = '[+region=us-east1]',
                |     lease_preferences = '[[+region=us-east1]]'
(1 row)

The same table, loaded in a demo cluster with no zone configuration changes, looks like this:

SHOW ZONE CONFIGURATION FROM TABLE users;

     target     |              raw_config_sql
----------------+-------------------------------------------
  RANGE default | ALTER RANGE default CONFIGURE ZONE USING
                |     range_min_bytes = 134217728,
                |     range_max_bytes = 536870912,
                |     gc.ttlseconds = 90000,
                |     num_replicas = 3,
                |     constraints = '[]',
                |     lease_preferences = '[]'
(1 row)

are not compatible with databases containing tables. CockroachDB does not prevent you from defining secondary regions on databases with regional by row tables, but the interaction of these features is not supported. Therefore, Cockroach Labs recommends that you avoid defining secondary regions on databases that use regional by row table configurations.

Global tables

A table differs from the default by setting the following zone configuration settings:

SHOW ZONE CONFIGURATION FROM TABLE promo_codes;

       target       |                                      raw_config_sql
--------------------+-------------------------------------------------------------------------------------------
  TABLE promo_codes | ALTER TABLE promo_codes CONFIGURE ZONE USING
                    |     range_min_bytes = 134217728,
                    |     range_max_bytes = 536870912,
                    |     gc.ttlseconds = 90000,
                    |     global_reads = true,
                    |     num_replicas = 5,
                    |     num_voters = 3,
                    |     constraints = '{+region=europe-west1: 1, +region=us-east1: 1, +region=us-west1: 1}',
                    |     voter_constraints = '[+region=us-east1]',
                    |     lease_preferences = '[[+region=us-east1]]'
(1 row)

The same table, loaded in a demo cluster with no zone configuration changes, looks like this:

SHOW ZONE CONFIGURATION FROM TABLE promo_codes;

     target     |              raw_config_sql
----------------+-------------------------------------------
  RANGE default | ALTER RANGE default CONFIGURE ZONE USING
                |     range_min_bytes = 134217728,
                |     range_max_bytes = 536870912,
                |     gc.ttlseconds = 90000,
                |     num_replicas = 3,
                |     constraints = '[]',
                |     lease_preferences = '[]'
(1 row)

​Overview

​Replication zone patterns and multi-region SQL abstractions

​How to migrate a database to the multi-region SQL abstractions

​Performance considerations

​Step 1. Remove the old replication zone configurations

​Duplicate indexes

​Geo-partitioned replicas

​Geo-partitioned leaseholders

​Step 2. Add a primary region to your database

​Step 3. Add more regions to the database

​Step 4. (Optional) Configure your database survival goal

​Step 5. Configure table localities

​Step 6. (Optional) View the updated zone configurations

​Regional by row tables

​Global tables

​See also

Overview

Replication zone patterns and multi-region SQL abstractions

How to migrate a database to the multi-region SQL abstractions

Performance considerations

Step 1. Remove the old replication zone configurations

Duplicate indexes

Geo-partitioned replicas

Geo-partitioned leaseholders

Step 2. Add a primary region to your database

Step 3. Add more regions to the database

Step 4. (Optional) Configure your database survival goal

Step 5. Configure table localities

Step 6. (Optional) View the updated zone configurations

Regional by row tables

Global tables

See also