A survival goal dictates how many simultaneous failure(s) a multi-region database can survive. All tables within the same database operate with the same survival goal. Each database is allowed to have its own survival goal setting.
Note:
This is an enterprise-only feature. You can use free trial credits to try it out.
Allowed survival goals include:
ZONE(default): Databases configured to survive zone failures have 3 voting replicas for every range, all in the home region. To support low-latency reads from other regions, one non-voting replica is placed in each non-home region.REGION: Databases configured to survive region failures have 2 voting replicas in the home region, and 3 voting replicas in non-home regions. This enables fast reads from within the home region and ensures minimal disruption in case one node fails, since the home region has two possible leaseholder candidates.
Set a ZONE survival goal if:
- You can accept a single node failure up to an entire zone failure. If multiple zones fail in the same region, the database may become unavailable.
Set a REGION survival goal if:
- The database must remain available, even if a region goes down.
- You can accept the performance cost: write latency will be increased by at least as much as the round-trip time to the nearest region. Read performance will be unaffected.
- The database can be or already is configured with 3 or more database regions. At least three database regions are required to survive region failures.
See also
- Multi-Region Capabilities Overview
- How to Choose a Multi-Region Configuration
- When to Use
REGIONALvs.GLOBALTables - 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?
