Introduction to replication and failover across multiple accounts¶

Replication feature / edition matrix¶

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

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. Refer to Grants for database objects for more details.

Replication of some databases is not supported or might fail the refresh operation. For more information, see Current limitations of replication.

Integration replication¶

Account replication supports the replication of integrations for the following features:

• Security integrations of the following types:

  • Federated Authentication & SSO (i.e. SAML2)

  • SCIM

  • Snowflake OAuth

  • External OAuth

  For more information about security integrations, see Replication of security integrations & network policies across multiple accounts.

• API integrations.

  After replicating API integrations to a target account, you must grant access to the remote service to the replicated external functions. For more information, see Updating the remote service for API integrations.

• Notification integrations of the following types:

  • TYPE = EMAIL

  • TYPE = QUEUE with DIRECTION = OUTBOUND

  • TYPE = WEBHOOK

• Storage integrations.

  When you replicate a storage integration, you must establish a new trust relationship for your cloud storage in the target accounts. To learn more, see Configure cloud storage access for secondary storage integrations.

• External access integrations.

  For more information about external access integrations, see External network access overview.

Network policy replication¶

The feature supports replicating network policies.

For more information, 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.

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.

Share replication¶

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

Replication of inbound shares (shares from providers) is not supported.

User replication¶

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

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.

For information about replicating secondary roles and session policies, see Session policies with secondary roles.

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.

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 more information, see ALTER FAILOVER GROUP.