Multi-region configuration options
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 localities: This is useful for multi-region apps that require different read and write latency guarantees for different tables in the database, and are not concerned with surviving a region failure. In this configuration, you get:
- Zone survival (the default).
- For global tables, low-latency reads from all regions.
- For regional by row tables, low-latency reads and writes from each row’s home region, and low-latency follower reads from all other regions.
- Change both survival goals and table localities: 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).
Configuration options vs. performance characteristics and application styles
The following table offers another view of how the various configuration options map to:- The performance characteristics of specific survival goal and table locality combinations.
- The types of applications that can benefit from each combination.
Different databases and tables within the same cluster can each use different combinations of these settings.
For new clusters using the multi-region SQL abstractions, Cockroach Labs
recommends lowering the
--max-offset setting to 250ms. This
setting is especially helpful for lowering the write latency of global tables. Nodes can run with different values for --max-offset, but only
for the purpose of updating the setting across the cluster using a rolling upgrade.
See also
- Multi-Region Capabilities Overview
- When to Use
REGIONALvs.GLOBALTables - When to Use
ZONEvs.REGIONSurvival Goals - Survive Region Outages with CockroachDB
- Topology Patterns
- Disaster Recovery
- Low Latency Reads and Writes in a Multi-Region Cluster
- Secondary regions
SET SECONDARY REGIONDROP SECONDARY REGION

