Choosing a multi-region configuration

On this page Carat arrow pointing down
Warning:
CockroachDB v21.1 is no longer supported as of November 18, 2022. For more details, refer to the Release Support Policy.

This page has high-level information about how to configure a multi-region cluster's survival goals and table locality.

Note:

This is an enterprise-only feature. Request a 30-day trial license to try it out.

The options for configuring your multi-region cluster include:

  • Change nothing: Using the default settings, you get:

    • Zone survival (the default).
    • Low-latency reads and writes from a single region.
    • A choice of low-latency stale reads or high-latency fresh reads from other regions (and high-latency fresh reads is the default).
  • Change only survival goals: This configuration is useful for single-region apps that need higher levels of survival. In this configuration, you move from availability zone (AZ) survival to get:

    • Region survival.
    • Low-latency reads from a single region.
    • A choice of low-latency stale reads or high-latency fresh reads from other regions (and high-latency fresh reads is the default).
    • Higher-latency writes from all regions (due to region survival).
  • Change only table locality: This is useful for multi-region apps that require different read/write latency guarantees for different tables in the database, and are not concerned with surviving a region failure. In this configuration, you get:

  • Change both survival goals and table locality: This is useful for multi-region apps that want a high level of survival. In this configuration, you move from zone survival and get:

    • Region survival.
    • Low-latency reads from all regions.
    • Higher-latency writes from all regions (due to region survival).

The table below offers another view of how the configuration options described above map to:

  • The performance characteristics of specific survival goal/table locality combinations.
  • The types of applications that can benefit from each combination.
locality ↓ survival →
ZONE REGION
REGIONAL BY TABLE Low-latency for single-region writes and multi-region stale reads. Single-region writes are higher latency than for ZONE, as at least one additional region must be consulted for each write. Stale multi-region reads are of comparable latency to ZONE survival.
For single-region apps that can accept risk of region failure. For single-region apps that must survive region failure.
REGIONAL BY ROW Low-latency consistent multi-region reads & writes for rows which are homed in specific regions. Low-latency consistent reads from a row's home region. Low-latency consistent stale reads from outside the row's home region. Low-latency writes if you are writing to a row from its home region.
For multi-region apps which read/write individual rows of the table from a specific region, and can accept the risk of region failure. Same as for ZONE survival, but for apps that must survive a region failure.
GLOBAL Low-latency multi-region reads. Writes are higher latency than reads. Low-latency multi-region reads. Writes are higher latency than reads. There should be minimal difference in write latencies between ZONE and REGION survival due to a new custom non-blocking transaction protocol.
For multi-region apps that need low-latency reads of a "read-mostly" table. For multi-region apps that need low-latency reads of a "read-mostly" table, and the ability to survive region failures.
Note:

Different databases and tables within the same cluster can each use different combinations of the settings above.

Tip:

For new clusters using the multi-region SQL abstractions, we recommend lowering the --max-offset setting to 250ms. This is especially helpful for lowering the write latency of global tables. Note that this will require restarting all of the nodes in your cluster at the same time; it cannot be done with a rolling restart.

See also


Yes No
On this page

Yes No