Introduction to Business Continuity and Disaster Recovery¶
Snowflake enables failover of your databases across multiple accounts in different regions for business continuity and disaster recovery. Failover across accounts hosted on different cloud platforms is supported.
In this Topic:
How Does Database Failover/Failback Work?¶
In the event of a massive outage (due to a network issue, software bug, etc.) that disrupts the cloud services in a given region, access to Snowflake will be unavailable until the source of the outage is resolved and services are restored.
To ensure continued availability and data durability in such a scenario, you can replicate your databases in a given region to another Snowflake account (owned by your organization) in a different region. This option allows you to recover multiple databases in the other region and continue to process data after a failure in the first region results in full or partial loss of Snowflake availability.
Initiating failover involves promoting a secondary (i.e. replica) database in an available region to serve as the primary database. When promoted, the now-primary database becomes writeable. Concurrently, the former primary database becomes a secondary, read-only database.
Business Continuity and Disaster Recovery Flow¶
The following diagram shows two accounts in the same organization but different regions (
Region B). In one account, a local database has been promoted to serve as a primary database. Replication has been enabled for the other account, allowing it to store a replica of the primary database (that is, a secondary database):
The following diagram shows a secondary database that has been created in the account in
Region B. The green arrow shows a data refresh operation in progress from the primary database to the secondary database:
The following diagram shows a failover scenario: A service outage in
Region A, where the account that contains the primary database is located. The secondary database (in
Region B) has been promoted to serve as the primary database. Concurrently, the former primary database has become a secondary, read-only database:
The steps to fail over a database are described in Failing Over Databases Across Multiple Accounts.
The following diagram shows that the service outage in
Region Ahas been resolved. A database refresh operation is in progress from the primary database (in
Region B) to the secondary database (in
The final diagram shows operations returned to their initial configuration (i.e. failback). The secondary database (in
Region A) has been promoted to once again serve as the primary database for normal business operations. Concurrently, the former primary database (in
Region B) has become a secondary, read-only database: