A table locality indicates how CockroachDB optimizes access to a table's data in a multi-region cluster. CockroachDB uses the table locality setting to determine how to optimize access to the table's data from that locality.
This is an enterprise-only feature. Request a 30-day trial license to try it out.
The following table localities are available:
REGIONALGLOBAL
Use a REGIONAL table locality if:
- Your application requires low-latency reads and writes from a single region (either at the row level or the table level).
- Access to the table's data can be slower (higher latency) from other regions.
Use a GLOBAL table locality if:
- Your application has a "read-mostly" table of reference data that is rarely updated, and that needs to be available to all regions.
- You can accept that writes to the table will incur higher latencies from any given region, since writes use a novel non-blocking transaction protocol that uses a timestamp "in the future". Note that the observed write latency is dependent on the
--max-offsetsetting.
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
- How to Choose a Multi-Region Configuration
- When to Use
ZONEvs.REGIONSurvival Goals - Low Latency Reads and Writes in a Multi-Region Cluster
- Topology Patterns
- Disaster Recovery
- Migrate to Multi-Region SQL
- Secondary regions
SET SECONDARY REGIONDROP SECONDARY REGION
Was this helpful?
