This page has high-level information about how to configure a multi-region cluster's survival goals and table locality.
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:
- 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 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. |
Different databases and tables within the same cluster can each use different combinations of the settings above.
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.