> ## Documentation Index
> Fetch the complete documentation index at: https://cockroachlabs.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Multi-Region Survival Goals

export const InternalLink = ({version, path = "", children, ...props}) => {
  let detectedVersion = version || "stable";
  if (typeof window !== 'undefined' && !version) {
    const match = window.location.pathname.match(/\/docs\/([^/]+)/);
    if (match) {
      detectedVersion = match[1];
    }
  }
  const normalizedPath = path.startsWith("/") ? path.slice(1) : path;
  return <a href={`/docs/${detectedVersion}/${normalizedPath}`} {...props}>
      {children}
    </a>;
};

A *survival goal* dictates how many simultaneous failure(s) a database can survive. All tables within the same database operate with the **same survival goal**. Each database can have its own survival goal setting.

The following survival goals are available:

* Zone failure
* Region failure

The zone failure survival goal is the default. You can configure a database to survive region failures at the cost of slower write performance (due to network hops) using the following statement:

```sql theme={"theme":{"light":"catppuccin-mocha","dark":"catppuccin-mocha"}}
ALTER DATABASE <db> SURVIVE REGION FAILURE;
```

For more information about the survival goals supported by CockroachDB, see the following sections:

* [Survive zone failures](#survive-zone-failures)
* [Survive region failures](#survive-region-failures)

## Survive zone failures

With the zone level survival goal, the database will remain fully available for reads and writes, even if a zone becomes unavailable. However, the database may not remain fully available if multiple zones in the same region fail. This is the default setting for multi-region databases.

You can configure a database to survive zone failures using the <InternalLink path="alter-database">`ALTER DATABASE ... SURVIVE ZONE FAILURE` statement</InternalLink>.

If your application has performance or availability needs that are different than what the default settings provide, you can explore the other customization options described on this page.

## Survive region failures

The region level survival goal has the property that the database will remain fully available for reads and writes, even if an entire region becomes unavailable. This added survival comes at a 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. In other words, you are adding network hops and making writes slower in exchange for robustness.

You can upgrade a database to survive region failures using the <InternalLink path="alter-database">`ALTER DATABASE ... SURVIVE REGION FAILURE` statement</InternalLink>.

Setting this goal on a database in a cluster with 3 <InternalLink path="multiregion-overview#cluster-regions">cluster regions</InternalLink> will automatically increase the <InternalLink path="configure-replication-zones">replication factor</InternalLink> of the <InternalLink path="architecture/glossary">ranges</InternalLink> underlying the database from 3 (the default) to 5. This ensures that there will be 5 replicas of each range spread across the 3 regions (2+2+1=5). This is how CockroachDB is able to provide region level resiliency while maintaining good read performance in the leaseholder's region. For writes, CockroachDB will need to coordinate across 2 of the 3 regions, so you will pay additional write latency in exchange for the increased resiliency.

<Note>
  To survive region failures, you must add at least 3 <InternalLink path="multiregion-overview#database-regions">database regions</InternalLink>.
</Note>

## When to use zone vs. region survival goals

Set a <InternalLink path="multiregion-survival-goals#survive-zone-failures">`ZONE` survival goal</InternalLink> 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 <InternalLink path="multiregion-survival-goals#survive-region-failures">`REGION` survival goal</InternalLink> 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 <InternalLink path="multiregion-overview#database-regions">database regions</InternalLink>. At least three database regions are required to survive region failures.

## See also

* <InternalLink path="multiregion-overview">Multi-Region Capabilities Overview</InternalLink>
* <InternalLink path="choosing-a-multi-region-configuration">How to Choose a Multi-Region Configuration</InternalLink>

- <InternalLink path="table-localities">Table Localities</InternalLink>
- <InternalLink path="demo-low-latency-multi-region-deployment">Low Latency Reads and Writes in a Multi-Region Cluster</InternalLink>
- <InternalLink path="topology-patterns">Topology Patterns</InternalLink>
- <InternalLink path="disaster-recovery">Disaster Recovery</InternalLink>
- <InternalLink path="migrate-to-multiregion-sql">Migrate to Multi-Region SQL</InternalLink>
- <InternalLink path="multiregion-overview#secondary-regions">Secondary regions</InternalLink>
- <InternalLink path="alter-database#set-secondary-region">`SET SECONDARY REGION`</InternalLink>
- <InternalLink path="alter-database#drop-secondary-region">`DROP SECONDARY REGION`</InternalLink>