Replicating Account Objects Across Multiple Accounts¶

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:

Replication Groups and Failover Groups
Replicated Objects
Replication Privileges
Replication of Roles and Grants
Replication Schedule
- Suspend and Resume Scheduled Replication
Replication and Read-only Secondary Objects
Cross-replication Group References
Replication Group and Failover Group Constraints
- Database and Share Objects
- Account Objects
Transitioning From Database Replication to Group-Based Replication
- Step 1. Disable Replication for a Replication Enabled Database
- Step 2. Add the Database to a Primary Failover Group and Create a Secondary Failover Group
Workflow
- Example
Replicating Account Objects and Databases
Update the Remote Service for API Integrations
Refreshing a Secondary Failover Group in a Target Account Manually
- Grant the REPLICATE Privilege on Failover Group to Role — Optional
- Manually Refresh a Secondary Failover Group
Promoting a Target Account to Serve as the Source Account
- Grant the FAILOVER Privilege on Failover Group to Role — Optional
- Promote a Secondary Failover Group to Primary Failover Group

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:

Feature	Standard Edition	Business Critical Edition
Database replication	✔	✔
Share replication	✔	✔
Replication Group	✔	✔
Account object (other than database and share) replication		✔
Failover Group		✔

Note

Database replication related functionality in Snowsight, the classic web interface, views, and functions (see list below) are for Database Replication only. There is currently no web interface support for replication and failover groups, and the available refresh and history functions for replication and failover groups are noted below:

Account Usage REPLICATION_DATABASES view
Information Schema functions:
- DATABASE_REFRESH_HISTORY (use REPLICATION_GROUP_REFRESH_HISTORY)
- DATABASE_REFRESH_PROGRESS, DATABASE_REFRESH_PROGRESS_BY_JOB (use REPLICATION_GROUP_REFRESH_PROGRESS, REPLICATION_GROUP_REFRESH_PROGRESS_BY_JOB)
- REPLICATION_USAGE_HISTORY

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.
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 Privileges on Database Objects for more details.

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 Replicated Privileges below.

Note

All roles are replicated, including the ORGADMIN role.

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.

Replicated Privileges¶

Privileges on Account Objects¶

Synchronize grants of privileges and roles within the Snowflake access control framework by replicating roles. This section describes the object and privilege grants that are replicated when roles are replicated from the source account to a target account.

Note

Privileges on replication groups and failover groups (see Replication Privileges in this topic) are currently 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.

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

Stages

Pipes

Streams

Tasks

External tables

Privileges on 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 objects, see Replicated Database Objects.

Future grants on both supported and unsupported database objects are synchronized at the database and schema levels. After a secondary database is promoted to become the primary database in a set, creating new objects of a specified type automatically grants the defined privileges to roles, as defined by the future grants. For more information about future grants, see Simplifying Grant Management Using Future Grants.

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 Privileges¶

This section describes the replication privileges that are available to be granted to roles to specify the operations users can perform on objects in the system. For grant syntax see GRANT <privileges> … TO ROLE.

Privilege	Object	Usage	Notes
OWNERSHIP	Replication Group Failover Group	Grants ability to delete, alter, and grant or revoke access to an object.	Can be granted by: The ACCOUNTADMIN role or A role that has the MANAGE GRANTS privilege or A role that has the OWNERSHIP privilege on the group.
CREATE REPLICATION GROUP	Account	Grants ability to create a replication group.	Must be granted by the ACCOUNTADMIN role.
CREATE FAILOVER GROUP	Account	Grants ability to create a failover group.	Must be granted by the ACCOUNTADMIN role.
FAILOVER	Failover Group	Grants ability to promote a secondary failover group to serve as primary failover group.	Can be granted or revoked by a role with the OWNERSHIP privilege on the group.
REPLICATE	Replication Group Failover Group	Grants ability to refresh a secondary group.	Can be granted or revoked by a role with the OWNERSHIP privilege on the group.
MONITOR	Replication Group Failover Group	Grants ability to see details within an object.	Can be granted or revoked by a role with the OWNERSHIP privilege on the group.

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. If roles are replicated in a separate replication or failover group, grants to roles are only replicated after the group that includes roles is replicated.

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.

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.

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.

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 and Read-only Secondary Objects¶

All secondary objects in a target account, including secondary databases and shares, are read-only. Changes cannot be made locally in a target account to replicated objects or object types. For example, if the USERS object type is replicated from a source account to a target account, new users cannot be created or modified in the target account.

New, local databases and shares can be created and modified in a target account. If the ROLES object type is replicated from a source account to the target account, new roles cannot be created or modified. Privileges cannot be granted to (or revoked from) a role on a secondary object in the target account. However, privileges can be granted to (or revoked from) a secondary role on local objects (for example, databases, shares, or replication or failover groups) created in the target account.

Cross-replication Group References¶

Objects in a replication (or failover) group that have dangling references (references to objects in another replication group) may successfully replicate to a target account in some circumstances. If the replication operation results in behavior in the target account that is consistent with behavior that may occur in the source account, replication succeeds.

For example, if a column in a table in failover group fg_a references a sequence in failover group fg_b, replication of both groups succeeds. If fg_a is replicated before fg_b, insert operations (after failover) on the table that references the sequence fails if fg_b was not replicated. This behavior can occur in a source account. If a sequence is dropped in a source account, insert operations on a table with a column referencing the dropped sequence fails.

When the dangling reference is a security policy that protects data, the replication (or failover) group with the security policy must be replicated before any replication group that contains objects that reference the policy is replicated.

Attention

Making updates to security policies that protect data in separate replication groups may result in inconsistencies and should be done with care.

Replication Group and Failover Group Constraints¶

Account objects, databases, and shares are constrained in replication and failover group membership, and must be uniquely replicated to target accounts. The following sections detail these constraints.

Account Objects¶

The following constraints apply to account object replication:

An account can only have one failover group that contains account objects other than databases or shares.
An account can have multiple replication groups with account objects as long as each group is replicated to different target accounts.
An account object cannot be in both a failover group and a replication group.
Replication and failover groups that contains account objects cannot share target accounts.

Transitioning From Database Replication to Group-Based Replication¶

Databases that have been enabled for replication using ALTER DATABASE must have replication disabled before they can be added to a replication or failover group.

Note

Execute the SQL statements in this section using the ACCOUNTADMIN role.

Step 1. Disable Replication for a Replication Enabled Database¶

Execute the SYSTEM$DISABLE_DATABASE_REPLICATION function to disable replication for a primary database, along with any secondary databases linked to it, in order to add it to a replication or failover group.

Execute the following SQL statement from the source account with the primary database:

SELECT SYSTEM$DISABLE_DATABASE_REPLICATION('mydb');

Step 2. Add the Database to a Primary Failover Group and Create a Secondary Failover Group¶

Once you have successfully disabled replication for a database, you can add the primary database to a failover group in the source account.

Then create a secondary failover group in the target account. When the secondary failover group is refreshed in the target account, the previously secondary database will automatically be added as a member of the secondary failover group and refreshed with the changes from the primary database.

For more details on creating primary and secondary failover groups, see Workflow (in this topic).

Note

When you add a previously replicated database to a replication or failover group, Snowflake does not re-replicate the data that has already been replicated for that database. Only changes since the last refresh are replicated when the group is refreshed.

Workflow¶

The following SQL statements demonstrate the workflow for enabling account and database object replication and refreshing objects. Each step is discussed in detail below.

Example¶

Execute the following SQL statements in your preferred Snowflake client to enable account and database object replication and failover, and refresh objects.

Executed on Source Account¶

Create a role and grant it the CREATE FAILOVER GROUP privilege. This step is optional:

-- Execute the following SQL statements using the ACCOUNTADMIN role:
USE ROLE ACCOUNTADMIN;

CREATE ROLE myrole;

GRANT CREATE FAILOVER GROUP ON ACCOUNT
 TO ROLE myrole;

Create a failover group in the source account and enable replication to specific target accounts.
Note
- If you have databases to add to a replication or failover group that have been previously enabled for database replication and failover using ALTER DATABASE, follow the Transitioning From Database Replication to Group-Based Replication instructions (in this topic) before adding them to a group.
- To add a database to a failover group, the active role must have the MONITOR privilege on the database. For details on database privileges, see Database Privileges (in a separate topic).
```
USE ROLE myrole;

-- Execute the following SQL statement using a role with the CREATE FAILOVER GROUP privilege:
CREATE FAILOVER GROUP myfg
    OBJECT_TYPES = USERS, ROLES, WAREHOUSES, RESOURCE MONITORS, DATABASES
    ALLOWED_DATABASES = db1, db2
    ALLOWED_ACCOUNTS = myorg.myaccount2, myorg.myaccount3
    REPLICATION_SCHEDULE = '10 MINUTE';
```

Executed on Target Account¶

Create a role in the target account and grant it the CREATE FAILOVER GROUP privilege. This step is optional:

-- Execute the following SQL statements using the ACCOUNTADMIN role:
USE ROLE ACCOUNTADMIN;

CREATE ROLE myrole;

GRANT CREATE FAILOVER GROUP ON ACCOUNT
    TO ROLE myrole;

Create a failover group in the target account as a replica of the failover group in the source account.

USE ROLE myrole;

-- Execute the following SQL statement using a role with the CREATE FAILOVER GROUP privilege:
CREATE FAILOVER GROUP myfg
    AS REPLICA OF myorg.myaccount1.myfg;

Apply global IDs to objects. This is an optional step for any account objects not created via replication.
```
-- Execute the following SQL statements using the ACCOUNTADMIN role:
SELECT SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME('myfg');
```
Important

This step must be executed if account objects (e.g. users) exist in the target account that you do not want to drop during replication. For more details, see Step 5. Apply Global IDs to Objects Created by Scripts in Target Accounts — Optional.

Refresh a Secondary Group Manually¶

To manually refresh a secondary failover group in the target account, see Refreshing a Secondary Failover Group in a Target Account Manually (in this topic).

Note

As a best practice, Snowflake recommends scheduling automatic refreshes using the REPLICATION_SCHEDULE parameter. See Replication Schedule (in this topic).

Replicating Account Objects and Databases¶

The instructions in this section explain how to prepare your accounts for replication, enable the replication of specific objects from the source account to the target account, and synchronize the objects in the target account.

Important

Target accounts do not have Tri-Secret Secure or AWS PrivateLink configured as a default. If Tri-Secret Secure or PrivateLink is required for compliance, security or other purposes, it is your responsibility to ensure that those features are configured in the target account.

Account and Database Object Replication to Accounts on Lower Editions¶

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

The primary replication group 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.
The primary replication or failover group 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, but 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 can be replicated to the specified accounts on any Snowflake edition.

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.

Prerequisite: Enable Replication on Your Accounts¶

You must have replication enabled for two or more accounts in your organization. If the Organizations feature is enabled for your account, a user with the ORGADMIN role can enable replication. See Prerequisite: Enable Replication for Accounts in the Organization for instructions. If you do not have Organizations enabled, you can contact Snowflake Support to enable replication for your accounts.

Step 1: Create a Role with the CREATE FAILOVER GROUP Privilege in the Source Account — Optional¶

Create a role and grant it the CREATE FAILOVER GROUP privilege. This step is optional. If you have already created this role, skip to Step 2: Create a Primary Failover Group in a Source Account.

-- Execute the following SQL statements using the ACCOUNTADMIN role:
USE ROLE ACCOUNTADMIN;

CREATE ROLE myrole;

GRANT CREATE FAILOVER GROUP ON ACCOUNT
    TO ROLE myrole;

Step 2: Create a Primary Failover Group in a Source Account¶

Create a primary failover group and enable the replication and failover of specific objects from the current (source) account to one or more target accounts in the same organization.

View All Accounts Enabled for Replication¶

To retrieve the list of accounts in your organization that are enabled for replication, use SHOW REPLICATION ACCOUNTS.

-- Execute the following SQL statements using the ACCOUNTADMIN role:
SHOW REPLICATION ACCOUNTS;

+------------------------+-------------------------+--------------+-----------------+-----------------+-------------------+
| snowflake_region       | created_on              | account_name | account_locator |  comment        | organization_name |
+------------------------+-------------------------+--------------+-----------------+-----------------+-------------------+
| AWS_US_WEST_2          | 2020-07-15 21:59:25.455 | myaccount1   | myacctlocator1  |                 | myorg             |
+------------------------+-------------------------+--------------+-----------------+-----------------+-------------------+
| AWS_US_EAST_1          | 2020-07-23 14:12:23.573 | myaccount2   | myacctlocator2  |                 | myorg             |
+------------------------+-------------------------+--------------+-----------------+-----------------+-------------------+
| AWS_US_EAST_2          | 2020-07-25 19:25:04.412 | myaccount3   | myacctlocator3  |                 | myorg             |
+------------------------+-------------------------+--------------+-----------------+-----------------+-------------------+

See the complete list of Region IDs.

View Failover and Replication Group Membership¶

Account, database, and share objects have constraints on group membership. Before creating new groups or adding objects to existing groups, you can review the list of existing failover groups and the objects in each group.

Note

Only an account administrator (user with the ACCOUNTADMIN role) or the group owner (role with the OWNERSHIP privilege on the group) can execute the SQL statements in this section.

View all failover groups linked to the current account, and the object types in each group:

SHOW FAILOVER GROUPS;

View all the databases in failover group myfg:

SHOW DATABASES IN FAILOVER GROUP myfg;

View all the shares in failover group myfg:

SHOW SHARES IN FAILOVER GROUP myfg;

Enable Account and Database Object Replication from a Source Account to Target Account¶

Create a failover group of specified account and database objects in the source account and enable replication and failover to a list of target accounts. See CREATE FAILOVER GROUP for syntax.

For example, enable replication of users, roles, warehouses, resources monitors, and databases db1 and db2 from the source account to the myaccount2 account in the same organization. Set the replication schedule to automatically refresh myaccount2 every 10 minutes.

Note

If you have databases to add to a replication or failover group that have been previously enabled for database replication using ALTER DATABASE, follow the Transitioning From Database Replication to Group-Based Replication instructions (in this topic) before adding them to a group.

Executed on the source account:

use role myrole;

-- Execute the following SQL statement using a role with the CREATE FAILOVER GROUP privilege:
create failover group myfg
    object_types = users, roles, warehouses, resource monitors, databases, integrations
    allowed_databases = db1, db2
    allowed_integration_types = API INTEGRATIONS
    allowed_accounts = myorg.myaccount2
    replication_schedule = '10 MINUTE';

Step 3: Create a Role with the CREATE FAILOVER GROUP Privilege in the Target Account — Optional¶

Create a role in the target account and grant it the CREATE FAILOVER GROUP privilege. This step is optional. If you have already created this role, skip to Step 4: Create a Secondary Failover Group in the Target Account.

-- Execute the following SQL statements using the ACCOUNTADMIN role:
USE ROLE ACCOUNTADMIN;

CREATE ROLE myrole;

GRANT CREATE FAILOVER GROUP ON ACCOUNT
    TO ROLE myrole;

Step 4: Create a Secondary Failover Group in the Target Account¶

Create a secondary failover group in the target account as a replica of the primary failover group in the source account.

Execute a CREATE FAILOVER GROUP … AS REPLICA OF statement in each target account for which you enabled replication in Step 2: Create a Primary Failover Group in a Source Account (in this topic).

Executed from each target account:

use role myrole;

-- Execute the following SQL statement using a role with the CREATE FAILOVER GROUP privilege:
CREATE FAILOVER GROUP myfg
  AS REPLICA OF myorg.myaccount1.myfg;

Step 5. Apply Global IDs to Objects Created by Scripts in Target Accounts — Optional¶

If you created account objects, for example, users and roles, in your target account by any means other than via replication (e.g. using scripts), these users and roles have no global identifier by default. The refresh operation uses global identifiers to synchronize these objects to the same objects in the source account. When a target account is refreshed from the source account, the refresh operation drops any users or roles in the target account that have no global identifier.

Optionally call the SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME function to add a global identifier to users and roles in the target (current) account that were created manually and that match objects with the same names in the source account. For account objects that exist only in the target account, replicate them manually in the source account before calling this function.

Note

Global identifiers are only added to account objects that are included in a replication or failover group for the following object types:

RESOURCE_MONITOR
ROLE
USER
WAREHOUSE

For example:

-- Execute the following SQL statements using the ACCOUNTADMIN role:
SELECT SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME('myfg');

Update the Remote Service for API Integrations¶

If you have enabled API integration replication, additional steps are required after the API integration is replicated to the target account. The replicated integration has its own identity and access management (IAM) entity that are different from the identity and IAM entity of the primary integration. Therefore, you must update the permissions on the remote service to grant access to replicated functions. The process is similar to granting access to the functions on the primary account. See the below links for more details:

For Amazon Web Services (AWS), Set Up the Trust Relationship(s) between Snowflake and the New IAM Role.
For Google Cloud Platform (GCP), Create a GCP Security Policy for the Proxy Service.
For Microsoft Azure:
- Step 1. Link the API integration for Azure
- Step 2. Create a validate-JWT policy

Refreshing a Secondary Failover Group in a Target Account Manually¶

To manually refresh the objects in a target account, execute the ALTER FAILOVER GROUP … REFRESH command.

As a best practice, we recommend scheduling your secondary refreshes by setting the REPLICATION_SCHEDULE parameter using CREATE FAILOVER GROUP or ALTER FAILOVER GROUP.

Note

If the user who calls the function in the target account was dropped in the source account, the refresh operation fails.

Grant the REPLICATE Privilege on Failover Group to Role — Optional¶

The REPLICATE privilege is currently not replicated and must be granted on a failover (or replication) group in both the source and target accounts.

Executed from the source account:

-- Execute the following SQL statements using a role with the OWNERSHIP privilege on the group:
GRANT REPLICATE ON FAILOVER GROUP myfg TO ROLE my_replication_role;

Executed from the target account:

-- Execute the following SQL statements using a role with the OWNERSHIP privilege on the group:
GRANT REPLICATE ON FAILOVER GROUP myfg TO ROLE my_replication_role;

Manually Refresh a Secondary Failover Group¶

For example, to refresh the objects in the failover group myfg, execute the following statement from the target account:

USE ROLE my_replication_role;

-- Execute the following SQL statements using a role with the REPLICATE privilege:
ALTER FAILOVER GROUP myfg REFRESH;

Promoting a Target Account to Serve as the Source Account¶

To promote a target account to serve as the source account, execute the ALTER FAILOVER GROUP … PRIMARY command.

Grant the FAILOVER Privilege on Failover Group to Role — Optional¶

The FAILOVER privilege is currently not replicated and must be granted on a failover group in both the source and target accounts.

Executed from myaccount1 source account:

USE ROLE ACCOUNTADMIN;

GRANT FAILOVER ON FAILOVER GROUP myfg TO ROLE my_failover_role;

Executed from myaccount2 target account:

USE ROLE ACCOUNTADMIN;

GRANT FAILOVER ON FAILOVER GROUP myfg TO ROLE my_failover_role;

Promote a Secondary Failover Group to Primary Failover Group¶

The following example promotes myaccount2 in the current myorg organization to serve as the source account for replication of the objects specified in the failover group myfg.

Executed from myaccount2 account:

USE ROLE my_failover_role;

ALTER FAILOVER GROUP myfg PRIMARY;

Replicating Account Objects Across Multiple Accounts¶

Replication Groups and Failover Groups¶

Replicated Objects¶

Database Replication¶

Integration Replication¶

Network Policy Replication¶

Parameter Replication¶

Resource Monitor Replication¶

Role Replication¶

Share Replication¶

User Replication¶

Warehouse Replication¶

Replicated Privileges¶

Privileges on Account Objects¶

Privileges on Database Objects¶

User Who Refreshes Objects in a Target Account¶

Replication Privileges¶

Replication of Roles and Grants¶

Future Grants for Objects¶

Object Creation and Ownership¶

Grants for Shares¶

Replication Schedule¶

Suspend and Resume Scheduled Replication¶

Replication and Read-only Secondary Objects¶

Cross-replication Group References¶

Replication Group and Failover Group Constraints¶

Database and Share Objects¶

Account Objects¶

Transitioning From Database Replication to Group-Based Replication¶

Step 1. Disable Replication for a Replication Enabled Database¶

Step 2. Add the Database to a Primary Failover Group and Create a Secondary Failover Group¶

Workflow¶

Example¶

Executed on Source Account¶

Executed on Target Account¶

Refresh a Secondary Group Manually¶

Replicating Account Objects and Databases¶

Account and Database Object Replication to Accounts on Lower Editions¶

Prerequisite: Enable Replication on Your Accounts¶

Step 1: Create a Role with the CREATE FAILOVER GROUP Privilege in the Source Account — Optional¶

Step 2: Create a Primary Failover Group in a Source Account¶

View All Accounts Enabled for Replication¶

View Failover and Replication Group Membership¶

Enable Account and Database Object Replication from a Source Account to Target Account¶

Step 3: Create a Role with the CREATE FAILOVER GROUP Privilege in the Target Account — Optional¶

Step 4: Create a Secondary Failover Group in the Target Account¶

Step 5. Apply Global IDs to Objects Created by Scripts in Target Accounts — Optional¶

Update the Remote Service for API Integrations¶

Refreshing a Secondary Failover Group in a Target Account Manually¶

Grant the REPLICATE Privilege on Failover Group to Role — Optional¶

Manually Refresh a Secondary Failover Group¶

Promoting a Target Account to Serve as the Source Account¶

Grant the FAILOVER Privilege on Failover Group to Role — Optional¶

Promote a Secondary Failover Group to Primary Failover Group¶