Multi-region configuration options
The options for configuring your multi-region cluster include:-
Change nothing: Using the , 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 : 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 : 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 , low-latency reads from all regions.
- For , low-latency reads and writes from each row’s , and low-latency from all other regions.
-
Change both and : 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.
| 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. |
| Single-region apps that can accept region failure. | Single-region apps that must survive region failure. | |
REGIONAL BY ROW | Low-latency consistent multi-region reads and writes for rows that are homed in specific regions. | Low-latency consistent reads from a row’s home region. Low-latency consistent from outside the row’s home region. Higher-latency writes if writing to a row from outside its home region. |
| Multi-region apps that read and write individual rows of the table from a specific region and can accept region failure. | Multi-region apps that read and write individual rows of the table from a specific region and 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. |
| Multi-region apps that need low-latency reads of a “read-mostly” table. | Multi-region apps that need low-latency reads of a “read-mostly” table and must survive a region failure. |
250ms. This setting is especially helpful for lowering the write latency of . 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.