Introduction to Account Replication and Failover

This feature enables the replication of objects from a source account to one or more target accounts in the same organization. Replicated objects in each target account are referred to as secondary objects and are replicas of the primary objects in the source account. Replication is supported across regions and across cloud platforms.

In this Topic:

Region Support for Replication and Failover/Failback

All Snowflake regions across Amazon Web Services, Google Cloud Platform, and Microsoft Azure support account replication.

Customers can replicate across all regions within a region group. To replicate between regions in different region groups, (i.e. from a Snowflake commercial region to a Snowflake government or Virtual Private Snowflake region), please contact Snowflake Support.

Replication Groups and Failover Groups

A replication group is a defined collection of objects in a source account that are replicated as a unit to one or more target accounts. Replication groups provide read-only access for the replicated objects.

A failover group is a replication group that can also fail over. A secondary failover group in a target account provides read-only access for the replicated objects. When a secondary failover group is promoted to become the primary failover group, read-write access is available. Any target account specified in the list of allowed accounts in a failover group can be promoted to serve as the primary failover group.

Replication and failover groups provide point-in-time consistency for the objects on the target account. The objects that can be included in a replication or failover group are listed below in Replicated Objects (in this topic).

Note that some object replication features are only available for Business Critical Edition (or higher). The following table lists the availability of account and database object replication features for each Snowflake edition:

Feature

Standard

Enterprise

Business Critical

VPS

Database replication

Share replication

Replication Group

Account object (other than database and share) replication

Failover Group

Replicated Objects

This feature supports replicating the objects listed below. Database replication and share replication are available on all editions. Replication of all other objects are only available for Business Critical Edition (or higher). For details on feature availability, see this table.

Object

Type or Feature

Replicated

Notes

Databases

Integrations

Security, API

Storage integrations are planned for a future release.

Network policies

Parameters (account level)

Resource monitors

Roles

Includes privileges granted to roles, as well as roles granted to roles (i.e. hierarchies of roles).

If users and roles are replicated, roles granted to users are also replicated.

Replicating database roles is planned for a future milestone of this feature.

Shares

Users

Warehouses

Database Replication

This feature supports replicating databases. A snapshot includes changes to the objects and data. If roles are replicated (in the same or different replication or failover group), the database refresh also synchronizes the privilege grants on the secondary database and the objects in the database (schemas, tables, views, etc.) to roles in the account. See Grants for Database Objects for more details.

Replicated Database Objects

When a primary database is replicated, a snapshot of its database objects and data is transferred to the secondary database. However, some database objects are not replicated. The following table indicates which database objects are replicated to a secondary database.

For specific usage information about these objects, see Database Replication Considerations.

Object

Type or Feature

Replicated

Notes

Tables

Permanent tables

Transient tables

Temporary tables

Automatic Clustering of clustered tables

External tables

Creating or refreshing a secondary database is blocked if an external table exists in the primary database. . Planned for a future version of database replication.

Table constraints

Except if a foreign key in the database references a primary/unique key in another database. .

Sequences

Views

Views

If a view references any object in another database (e.g. table columns, other views, UDFs, or stages), . both databases must be replicated.

Materialized views

Secure views

File formats

Stages

Stages

Planned for a future version of database replication.

Temporary stages

Pipes

Planned for a future version of database replication.

Stored procedures

For details, see Replication of Stored Procedures and User-Defined Functions (UDFs).

Streams

For details, see Replication and Streams.

Tasks

For details, see Replication and Tasks.

UDFs

For details, see Replication of Stored Procedures and User-Defined Functions (UDFs).

Policies

Column-level Security (masking)

For masking, row access, and tag-based masking policies, refer to policy replication considerations.

Row access policies

Tag-based masking policies

Session policies

For session and password policies, refer to replication and security policies.

Password policies

Tags

Object Tagging

For tags, refer to Replication and Tags.

Integration Replication

This feature supports replicating security integrations for SAML2, SCIM, Snowflake OAuth, and External OAuth, and API integrations. Storage integrations are not currently supported but are planned for a future release.

For details about security integrations, see Replication of Security Integrations & Network Policies Across Multiple Accounts.

API integration replication requires additional setup after the integration is replicated to a target account. Access to the remote service must be granted to replicated functions. For details, see Update the Remote Service for API Integrations.

Network Policy Replication

The feature supports replicating network policies.

For details, see Replication of Security Integrations & Network Policies Across Multiple Accounts.

Parameter Replication

This feature supports replicating account-level parameters and object parameters. Object parameters are replicated when the object is included in the replication group. For example, if WAREHOUSES are replicated, warehouse-specific parameters (e.g. STATEMENT_TIMEOUT_IN_SECONDS) are replicated. For a full list see Object Parameters.

Account-level parameter replication includes all Account Parameters and parameters set on the account. Account-level parameters (e.g. DATA_RETENTION_TIME_IN_DAYS) are replicated when ACCOUNT PARAMETERS is included in the list of object types for a replication group.

Resource Monitor Replication

This feature supports replicating resource monitors and privileges granted on resource monitors to roles. A secondary resource monitor follows the same quota reset schedule as its primary. For example, if the quota on the primary resource monitor resets on the first of the month, and the secondary is first replicated on the 15th of the month, its quota will reset on the first of the next month along with the primary.

Email notification setup is not replicated and account administrators will need to set up email notifications on each target account. See Enabling Receipt of Notifications for Account Administrators. Replication of notification setup will be added in a future release.

Role Replication

This feature supports replicating roles, including role hierarchies. Role objects must be replicated to replicate access privileges. Replicated access privileges are listed in Replication of Roles and Grants below.

Note

All roles are replicated, including the ORGADMIN role.

Share Replication

This feature supports replication of share objects as well as access privileges granted to shares on database objects.

User Replication

This feature supports replicating users and their properties to target accounts, and the following user authentication methods:

Authentication Method

Works in Target Accounts

Notes

Password

Password with MFA (multi-factor authentication)

Users who are enrolled in MFA in the source account must separately enroll in MFA when they log into each target account.

Multi-Factor Authentication (MFA)

Users who are enrolled in MFA in the source account must separately enroll in MFA when they log into each target account.

Key pair

Federated Authentication & SSO

See Replication of Security Integrations & Network Policies Across Multiple Accounts for details on replicating federated SSO (i.e. SAML2) security integrations.

Snowflake OAuth

See Replication of Security Integrations & Network Policies Across Multiple Accounts for details on replicating OAuth security integrations.

External OAuth

See Replication of Security Integrations & Network Policies Across Multiple Accounts for details on replicating OAuth security integrations.

SCIM

See Replication of Security Integrations & Network Policies Across Multiple Accounts for details on replicating SCIM security integrations.

Note

If USERS and ROLES objects are replicated to a target account, these object types are read-only in the target account and cannot be modified. Users and roles must be created in the source account, then replicated to each target account. See Replication and Read-only Secondary Objects (in this topic).

Warehouse Replication

This feature supports replicating warehouses and privileges granted on warehouses to roles (if roles are replicated). The state of the primary warehouse is not replicated. Warehouses are replicated in the suspended state to each target account and can be resumed in the target account.

Replication of Roles and Grants

In order to replicate grants on objects to roles, roles must be replicated from the source account to the target account. To replicate roles in a replication or failover group, you must include roles in the object_types list. Roles can be in a separate replication or failover group from the data objects on which the privileges are granted.

When roles are replicated, grants on objects are only replicated to a target account if:

  • The privilege was granted by the owner of the object or indirectly by a role that was granted the privilege with the WITH GRANT OPTION parameter by the owner of the object.

  • Both the grantee and grantor role for a privilege grant are located in the target account.

  • The object is replicated (i.e. the object type is included in the object_types list).

Otherwise the grant on the object is not replicated.

Note

  • If a role is dropped that has the OWNERSHIP privilege on an active pipe in the target account, the refresh operation fails.

  • Privileges on replication groups and failover groups (see Replication Privileges in this topic) are not replicated. If the REPLICATE or FAILOVER privilege has been granted on replication groups or failover groups, these privileges need to be granted in both the source and target accounts.

Grants for Database Objects

If roles and databases are replicated to a target account (in the same or different replication or failover group), refreshing a secondary database synchronizes the privilege grants on the database and the objects in the database (schemas, tables, views, etc.) to existing roles in the target account (i.e. roles that have been replicated to the target account). Note that only privilege grants on objects supported by database replication are synchronized. For the list of supported objects, see Replicated Database Objects.

The following database objects are not currently supported for replication. As a result, privilege grants on these objects are also not replicated:

  • Stages

  • Pipes

  • External tables

Future Grants for Objects

If roles are replicated to the target account, future grants that are granted at the database or schema level are replicated to the target account. This also includes future grants on non-replication supported objects. For example, stage replication is not yet supported, however future grants on stages are replicated. When you create a stage in a target account, the privileges granted on future stages materialize as intended.

Object Creation and Ownership

If new objects are created in a target account during a refresh from the source account, and roles are not replicated to the target account, the OWNERSHIP privilege for the new objects is granted to the ACCOUNTADMIN role.

If roles are replicated to the target account, the OWNERSHIP privilege is granted to the same role on the target account as the role with the OWNERSHIP privilege in the source account when roles are next replicated. The roles may be replicated at the same time the new objects are created in the target account if the objects and roles are in the same replication (or failover) group.

Grants for Shares

In order to enable secure data sharing, grants on objects to shares are replicated even if roles are not replicated to target accounts. This section provides information on how grants on objects to shares are replicated.

If roles are replicated from the source account to the target account, grants to objects on shares are replicated if:

  • The grantor role exists in the target account or

  • The grantor role in the source account has the OWNERSHIP privilege on the primary object.

If roles are not replicated from the source account to the target account, then:

  • Grants on objects to shares are replicated.

  • The grantor role for grants on replicated objects to shares is the role with the OWNERSHIP privilege on the object.

User Who Refreshes Objects in a Target Account

A user who executes the ALTER FAILOVER GROUP … REFRESH command to refresh objects in a target account from the source account must use a role with the REPLICATE privilege on the failover group. Snowflake protects this user in the target account by failing in the following scenarios:

  • If the user does not exist in the source account, the refresh operation fails.

  • If the user exists in the source account, but a role with the REPLICATE privilege was not granted to the user, the refresh operation fails.

Replication Schedule

As a best practice, Snowflake recommends scheduling automatic refreshes using the REPLICATION_SCHEDULE parameter. The schedule can be defined when creating a new replication or failover group with CREATE <object> or later (using ALTER <object>).

When a secondary replication or failover group is created, an initial refresh is automatically executed. The next refresh is scheduled based on when the prior refresh started and the scheduling interval, or the next valid time based on the cron expression. For example, if the refresh schedule interval is 10 minutes and the prior refresh operation (either a scheduled refresh or manually triggered refresh) starts at 12:01, the next refresh is scheduled for 12:11.

Snowflake ensures only one refresh is executed at any given time. If a refresh is still executing when the next refresh is scheduled, the next refresh is delayed to start when the currently executing refresh completes. For example, if a refresh is scheduled to execute 15 minutes after the hour, every hour, and the prior refresh completes at 12:16, the next refresh is scheduled to execute when the previously executing refresh is completed.

Suspend and Resume Scheduled Replication

A secondary failover group cannot be promoted to the primary group while a refresh is executing. To fail over gracefully, suspend scheduled replication in the target account. After the failover is completed, resume the scheduled replication. For syntax, see ALTER FAILOVER GROUP.

Note

Suspending scheduled replication does not suspend a refresh operation that is currently in progress. It suspends the schedule so that no additional refreshes are scheduled after the current one is completed.

Replication to Accounts on Lower Editions

If either of the following conditions is true, Snowflake displays an error message:

  • A primary replication group with only database and/or share objects is in a Business Critical (or higher) account but one or more of the accounts approved for replication are on lower editions. Business Critical Edition is intended for Snowflake accounts with extremely sensitive data.

  • A primary replication or failover group with any object types is in a Business Critical (or higher) account and a signed business associate agreement is in place to store PHI data in the account per HIPAA and HITRUST CSF regulations. However, no such agreement is in place for one or more of the accounts enabled for replication, regardless if they are Business Critical (or higher) accounts.

This behavior is implemented in an effort to help prevent account administrators for Business Critical (or higher) accounts from inadvertently replicating sensitive data to accounts on lower editions.

An account administrator (a user with the ACCOUNTADMIN role) or a user with a role with the CREATE REPLICATION GROUP/CREATE FAILOVER GROUP or OWNERSHIP privilege can override this default behavior by including the IGNORE EDITION CHECK clause when executing the CREATE <object> or ALTER <object> statement. If IGNORE EDITION CHECK is set, the primary replication or failover group may be replicated to the specified accounts on lower Snowflake editions in these specific scenarios.

Note

Failover groups can only be created in a Business Critical Edition (or higher) account. Therefore failover groups can only be replicated to an account that is a Business Critical Edition (or higher) account.

Back to top