跨多个账户复制数据库和账户对象

本主题介绍了在同一组织中跨 Snowflake 账户复制账户对象和数据并保持对象和数据同步所需的步骤。账户复制可以在不同 区域 Snowflake 账户之间并跨越 云平台 进行。

备注

当您将账户升级到 Business Critical Edition(或更高版本)时,故障转移功能可能需要最多 12 小时才能可用。

对复制和故障转移/故障回复的区域支持

客户可以对跨区域组内的所有区域进行复制。要在属于不同 区域组 的区域之间进行复制(例如,从 Snowflake 商业区到 Snowflake 政府区域),请联系 Snowflake 支持部门 以启用访问权限。

从 Database Replication 转换为基于组的复制

已启用使用 ALTER DATABASE 进行复制的数据库必须禁用复制之 前 才能将它们添加到复制组或故障转移组。

备注

使用 ACCOUNTADMIN 角色执行此部分中的 SQL 语句。

第 1 步:禁用已启用复制数据库的复制

执行 SYSTEM$DISABLE_DATABASE_REPLICATION 函数以禁用主数据库以及链接到它的任何辅助数据库的复制,以便将其添加到复制组或故障转移组。

在主数据库的源账户中执行以下 SQL 语句:

SELECT SYSTEM$DISABLE_DATABASE_REPLICATION('mydb');

第 2 步:将数据库添加到主故障转移组并创建辅助故障转移组

成功禁用数据库复制后,您可以将主数据库添加到源账户中的故障转移组。

然后在目标账户中创建辅助故障转移组。在目标账户中刷新辅助故障转移组时,之前的辅助数据库将自动添加为辅助故障转移组的成员,并使用主数据库中的更改进行刷新。

有关创建主要和辅助故障转移组的更多详细信息,请参阅 工作流程。

备注

您将以前复制的数据库添加到复制或故障转移组时,Snowflake执行以下操作:不会 重新复制已为该数据库复制的数据。刷新组时,仅复制自上次刷新以来的更改。

工作流程

下列 SQL 语句演示了启用账户和数据库对象复制以及刷新对象的工作流程。下面详细讨论每个步骤。

备注

以下示例要求为源账户和目标账户启用复制。有关详细信息,请参阅 先决条件:为组织中的账户启用复制。

示例

执行以下首选的 Snowflake 客户端中的 SQL 语句,以便启用账户和数据库对象复制和故障转移并刷新对象。

在源账户上执行

  1. 创建角色并授予其 CREATE FAILOVER GROUP 权限。此步骤是 可选的:

    USE ROLE ACCOUNTADMIN;
    
    CREATE ROLE myrole;
    
    GRANT CREATE FAILOVER GROUP ON ACCOUNT
      TO ROLE myrole;
    
  2. 在源账户中创建故障转移组并启用到特定目标账户的复制。

    备注

    • 如果要向复制组或故障转移组添加数据库,而这些数据库先前已使用 ALTER DATABASE 启用了数据库复制制和故障转移,那么在将它们添加到组之前,请遵循 从 Database Replication 转换为基于组的复制 说明(本主题内容)。

    • 要将数据库添加到故障转移组,活动角色必须具有 MONITOR 数据库的权限。有关数据库权限的详细信息,请参阅 数据库权限 (在单独的主题中)。

    USE ROLE myrole;
    
    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';
    

在目标账户上执行

  1. 在目标账户中创建角色并授予其 CREATE FAILOVER GROUP 权限。此步骤是 可选的:

    USE ROLE ACCOUNTADMIN;
    
    CREATE ROLE myrole;
    
    GRANT CREATE FAILOVER GROUP ON ACCOUNT
      TO ROLE myrole;
    
  2. 在目标账户中创建故障转移组作为源账户中故障转移组的副本。

    备注

    如果目标账户中存在源账户中不存在的账户对象(例如用户或角色),在创建辅助组之前,请参阅 用户和角色的初始复制。

    USE ROLE myrole;
    
    CREATE FAILOVER GROUP myfg
      AS REPLICA OF myorg.myaccount1.myfg;
    
  3. 手动刷新辅助故障转移组。这是一个*可选的*步骤。如果使用复制创建主故障转移组,则在创建辅助故障转移组时,系统会自动执行辅助故障转移组的初始刷新。

    1. 创建一个具有故障转移组 REPLICATE 权限的角色。此步骤是 可选的。

      使用具有故障转移组 OWNERSHIP 权限的角色在目标账户中执行:

      GRANT REPLICATE ON FAILOVER GROUP myfg TO ROLE my_replication_role;
      
    2. 使用具有 REPLICATE 权限的角色执行刷新语句:

      USE ROLE my_replication_role;
      
      ALTER FAILOVER GROUP myfg REFRESH;
      
  4. 创建一个具有故障转移组 FAILOVER 权限的角色。此步骤是 可选的。

    使用具有故障转移组 OWNERSHIP 权限的角色在目标账户中执行:

    GRANT FAILOVER ON FAILOVER GROUP myfg TO ROLE my_failover_role;;
    

复制账户对象和数据库

本部分中的说明解释了如何准备账户进行复制、将特定对象从源账户复制到目标账户,以及同步目标账户中的对象。

先决条件:为组织中的账户启用复制

组织管理员必须为源账户和目标账户启用复制。

要启用账户复制,组织管理员 使用 SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER 函数来将 ENABLE_ACCOUNT_DATABASE_REPLICATION 参数设置为 true。

作为组织管理员,为组织中的每个源账户和目标账户启用复制。

-- View the list of the accounts in your organization
-- Note the organization name and account name for each account for which you are enabling replication
SHOW ACCOUNTS;

-- Enable replication by executing this statement for each source and target account in your organization
SELECT SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER('<organization_name>.<account_name>', 'ENABLE_ACCOUNT_DATABASE_REPLICATION', 'true');

虽然 SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER 函数支持传统的 账户定位器 定位符,但当组织拥有多个共享相同定位器(位于不同区域)的账户时,它会导致意外结果。

第 1 步:在源账户中创建一个具有 CREATE FAILOVER GROUP 权限的角色 – 可选

创建角色并授予其 CREATE FAILOVER GROUP 权限。此步骤是可选的。如已创建此角色,请跳转至 第 3 步:在源账户中创建一个主故障转移组。

USE ROLE ACCOUNTADMIN;

CREATE ROLE myrole;

GRANT CREATE FAILOVER GROUP ON ACCOUNT
    TO ROLE myrole;

第 2 步:识别已启用复制的账户和组成员关系

在创建主故障转移组之前,请识别出已启用复制的账户,以及现有的故障转移组和复制组。

查看已启用复制的所有账户

要检索组织中已启用复制的账户列表,请使用 SHOW REPLICATION ACCOUNTS。

使用 ACCOUNTADMIN 角色执行以下 SQL 语句:

SHOW REPLICATION ACCOUNTS;

返回:

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

查看 区域 IDs 的完整列表。

查看故障转移组和复制组成员身份

账户、数据库和共享对象对 团体成员身份有约束。创建新组或向现有组添加对象之前,您可以查看现有故障转移组的列表以及每个组中的对象。

备注

只有账户管理员(具有 ACCOUNTADMIN 角色的用户)或组所有者(具有组 OWNERSHIP 权限的角色)可以执行本部分中的 SQL 语句。

查看链接到当前账户的所有故障转移组以及每个组中的对象类型:

SHOW FAILOVER GROUPS;

查看故障转移组 myfg 中的所有数据库:

SHOW DATABASES IN FAILOVER GROUP myfg;

查看故障转移组 myfg 中的所有共享:

SHOW SHARES IN FAILOVER GROUP myfg;

第 3 步:在源账户中创建一个主故障转移组

创建一个主故障转移组,并启用从当前(源)账户到同一组织中一个或多个目标账户的特定对象的复制和故障转移。

您可以使用 Snowsight 或者 SQL 创建复制组或故障转移组。

备注

如果要向复制组或故障转移组添加数据库,而这些数据库先前已使用 ALTER DATABASE 启用了数据库复制,那么在将它们添加到组之前,请遵循 从 Database Replication 转换为基于组的复制 说明(本主题内容)。

使用 Snowsight 创建复制组或故障转移组

备注

  • 只有账户管理员才能使用 Snowsight 创建复制组或故障转移组(请参阅 使用 Snowsight 进行复制配置的限制)。

  • 您必须以具有 ACCOUNTADMIN 角色的用户身份登录到目标账户。如果没有,系统将提示您登录。

    源账户和目标账户都必须使用相同的连接类型(公共互联网)。否则,登录目标账户将失败。

完成以下步骤来创建新的复制组或故障转移组:

  1. 登录 Snowsight。

  2. 在导航菜单中,选择 Admin » Accounts。

  3. 选择 Replication,然后在 Groups 选项卡上完成以下操作之一:

    • 对于 Business Critical Edition(或更高版本)账户,请完成以下操作之一:

      • 如果尚未创建复制组或连接,请选择 Get started 配置复制组和连接。此时将出现 Setup business continuity 向导。

      • 选择 + Group 在不配置连接的情况下配置复制组。此时将出现 Create a group 向导。

    • 对于 Standard Edition 和 Enterprise Edition 账户,请完成以下操作之一:

      • 如果尚未创建复制组或连接,请选择 Get started 配置复制组。此时将出现 Setup replication 向导。

      • 如果存在一个或多个复制组,选择 + Group 配置复制组。此时将出现 Create a group 向导。

  4. 在 Select a target account 页面上,选择目标账户并登录,然后选择 Next。

  5. 在 Create a group 页面上的 Group name 框中,输入满足以下要求的组名称:

    • 必须以字母字符开头,且不能包含空格或特殊字符,除非标识符字符串被双引号包围(例如“My object”)。放在双引号内的标识符也区分大小写。

      有关更多信息,请参阅 标识符要求。

    • 在一个账户中,故障转移组和复制组的名称必须是唯一的。

  6. 选择 Edit objects 将共享和账户对象添加到您的组中。

    备注

    账户对象只能添加到一个复制组或故障转移组。如果您的账户中已存在具有任何账户对象的复制或故障转移组,则无法选择这些对象。

  7. 选择 Select databases 将数据库对象添加到您的组中。

  8. 选择 Replication frequency。

  9. 如果账户是 Business Critical Edition 版本或更高版本,则默认情况下系统会创建一个故障转移组。您也可以选择创建复制组。要创建复制组,请选择 Advanced options,然后取消选择 Enable failover。

  10. 完成以下操作之一:

    • 对于 Business Critical Edition(或更高版本)账户,选择 Next。

    • 对于 Standard Edition 和 Enterprise Edition 账户,选择 Start replication 创建复制组。

  11. 对于 Business Critical Edition(或更高版本)账户,在 Create connection 页面的 Connection name 框中输入连接名称,然后选择 Start replication。

如果创建复制组不成功,请参阅 使用 Snowsight 解决创建和编辑复制组方面的问题 了解常见错误以及解决方法。

使用 SQL 创建故障转移组

在源账户中创建指定账户和数据库对象的故障转移组,并启用复制和故障转移到目标账户列表。有关语法的信息,请参阅 CREATE FAILOVER GROUP。

例如,启用用户、角色、仓库、资源监视器和数据库 db1 和 db2 的从源账户复制到同一组织中的 myaccount2 账户。将复制计划设置为每 10 分钟自动刷新 myaccount2。

在源账户上执行以下语句:

USE ROLE myrole;

CREATE FAILOVER GROUP myfg
    OBJECT_TYPES = USERS, ROLES, WAREHOUSES, RESOURCE MONITORS, DATABASES, INTEGRATIONS, NETWORK POLICIES
    ALLOWED_DATABASES = db1, db2
    ALLOWED_INTEGRATION_TYPES = API INTEGRATIONS
    ALLOWED_ACCOUNTS = myorg.myaccount2
    REPLICATION_SCHEDULE = '10 MINUTE';

第 4 步:在目标账户中创建一个具有 CREATE FAILOVER GROUP 权限的角色 – 可选

在目标账户中创建角色并授予其 CREATE FAILOVER GROUP 权限。此步骤是可选的。如已创建此角色,请跳转至 第 5 步:在目标账户中创建辅助故障转移组。

USE ROLE ACCOUNTADMIN;

CREATE ROLE myrole;

GRANT CREATE FAILOVER GROUP ON ACCOUNT
    TO ROLE myrole;

第 5 步:在目标账户中创建辅助故障转移组

备注

如果目标账户中存在源账户中不存在的账户对象(例如用户或角色),在创建辅助组之前,请参阅 用户和角色的初始复制。

在目标账户中创建辅助故障转移组作为源账户中主故障转移组的副本。

执行 CREATE FAILOVER GROUP ...AS REPLICA OF 语句,并且对于已在 第 3 步:在源账户中创建一个主故障转移组 (本主题内容中)中启用复制的每个目标账户,都要执行此语句。

在每个目标账户中执行以下语句:

USE ROLE myrole;

CREATE FAILOVER GROUP myfg
  AS REPLICA OF myorg.myaccount1.myfg;

第 6 步:手动刷新目标账户中的辅助故障转移组 – 可选

要手动刷新目标账户中的对象,请执行 ALTER FAILOVER GROUP ...REFRESH 命令。

我们建议的最佳实践是使用 CREATE FAILOVER GROUP 或 ALTER FAILOVER GROUP 设置 REPLICATION_SCHEDULE 参数来计划辅助刷新。

备注

如果目标账户中调用该函数的用户已在源账户中被删除,则刷新操作会失败。

为角色授予故障转移组的 REPLICATE 权限 – 可选

您必须使用具有故障转移组的 REPLICATE 权限的角色,才能执行刷新目标账户中的辅助复制或故障转移组的命令。REPLICATE 权限当前 无法 复制,且必须在源账户和目标账户中的故障转移(或复制)组上授予。

使用具有组 OWNERSHIP 权限的角色从源账户执行此语句:

GRANT REPLICATE ON FAILOVER GROUP myfg TO ROLE my_replication_role;

使用具有组 OWNERSHIP 权限的角色从目标账户执行此语句:

GRANT REPLICATE ON FAILOVER GROUP myfg TO ROLE my_replication_role;

手动刷新辅助故障转移组

例如,要刷新故障转移组 myfg 中的对象,请从目标账户执行以下语句:

USE ROLE my_replication_role;

ALTER FAILOVER GROUP myfg REFRESH;

第 7 步:为角色授予故障转移组的 FAILOVER 权限 – 可选

您必须使用具有故障转移组的 FAILOVER 权限 的角色,才能执行对目标账户中的辅助故障转移组进行故障转移的命令。FAILOVER 权限当前 无法 复制,且必须在每个源账户和目标账户中授予。

有关更多信息,请参阅 角色和授权的复制。

例如,要向角色 my_failover_role 授予故障转移组 my_fg 的 FAILOVER 权限,请使用具有该组 OWNERSHIP 权限的角色,在 目标账户 中执行以下语句:

GRANT FAILOVER ON FAILOVER GROUP myfg TO ROLE my_failover_role;

有关创建具有指定权限集的自定义角色的说明,请参阅 创建自定义角色。

有关对 安全对象 执行 SQL 操作的相应角色和权限授予的一般信息,请参阅 访问控制概述。

故障转移组的架构级复制

对于故障转移组中的数据库,您可以选择在数据库和/或数据库中的单个架构上配置 REPLICABLE_WITH_FAILOVER_GROUPS 参数,以指定用于复制的架构子集。

此功能可让您控制故障转移组中被复制的架构,如果数据库中只有一部分数据需要故障转移提供的额外灾难恢复保护,则此功能非常有用。

由于此参数默认情况下对所有数据库及其包含的架构都启用,因此您可以通过选择从复制中省略哪些数据库和/或架构来调整复制粒度。您可以进一步微调复制设置,允许复制某些架构,即使包含这些架构的数据库未被复制。

指定要复制或跳过的架构

您可以使用可选的 可选的 REPLICABLE_WITH_FAILOVER_GROUPS 参数,在故障转移组中明确指定要复制或跳过的数据库架构。

REPLICABLE_WITH_FAILOVER_GROUPS 参数

REPLICABLE_WITH_FAILOVER_GROUPS 参数指定是否复制属于故障转移组中的数据库的架构。可以在数据库和数据库中的任何/所有架构上设置此参数。如果为数据库设置了该参数,则数据库中的所有架构都会继承该值,除非为任何给定架构显式设置了不同的值。

该参数接受两个值, 'YES' 或者 'NO' (不区分大小写),并且是可选的:

  • 如果 REPLICABLE_WITH_FAILOVER_GROUPS 未在数据库上显式设置(或显式取消设置),数据库将遵循标准复制行为,这相当于将参数设置为 'YES'。

  • 如果 REPLICABLE_WITH_FAILOVER_GROUPS 未在架构上显式设置(或显式取消设置),则复制行为从其父数据库继承。

ALTER DATABASE <name> SET REPLICABLE_WITH_FAILOVER_GROUPS = { 'YES' | 'NO' }
ALTER DATABASE <name> UNSET REPLICABLE_WITH_FAILOVER_GROUPS

ALTER SCHEMA <name> SET REPLICABLE_WITH_FAILOVER_GROUPS = { 'YES' | 'NO' }
ALTER SCHEMA <name> UNSET REPLICABLE_WITH_FAILOVER_GROUPS

安全要求

要在数据库或架构上设置或取消设置此参数,需要以下权限:

  • REPLICATE (账户级权限)。在架构级复制功能之前,此权限只是复制组和故障转移组的对象级权限。拥有 ACCOUNTADMIN 角色的用户可以将此权限授予其他角色。

  • USAGE (数据库 和 架构 权限)或任何类似的权限,可以对数据库和架构采取行动。

示例

授予预先存在的角色必要的权限, replicationadmin:

USE ROLE ACCOUNTADMIN;

GRANT REPLICATE ON ACCOUNT TO ROLE replicationadmin;
GRANT USAGE ON DATABASE db1 TO ROLE replicationadmin;
GRANT USAGE ON SCHEMA db1.sch1 TO ROLE replicationadmin;

仅复制数据库 db1 中的一个架构,即 sch1:

USE ROLE replicationadmin;

ALTER DATABASE db1 SET REPLICABLE_WITH_FAILOVER_GROUPS = 'NO';
ALTER SCHEMA sch1 SET REPLICABLE_WITH_FAILOVER_GROUPS = 'YES';

复制 db2 数据库中除 sch2 之外的所有架构:

USE ROLE replicationadmin;

ALTER DATABASE db2 SET REPLICABLE_WITH_FAILOVER_GROUPS = 'YES';
ALTER SCHEMA sch2 SET REPLICABLE_WITH_FAILOVER_GROUPS = 'NO';

刷新目标账户中设置了 REPLICABLE_WITH_FAILOVER_GROUPS 的架构

在数据库刷新期间:

  • REPLICABLE_WITH_FAILOVER_GROUPS 设置为 'YES' 的架构会从源账户复制到目标账户。

  • REPLICABLE_WITH_FAILOVER_GROUPS 设置为 'NO' 的架构不会被复制,以下两种情况除外:

    • 目标架构是源账户架构的副本。在这种情况下,目标架构始终与其源架构同步。

    • 目标架构与源账户架构存在名称冲突。在这种情况下,复制作业会因名称冲突而失败。

列出账户中设置了 REPLICABLE_WITH_FAILOVER_GROUPS 的数据库和架构

通过查询 ACCOUNT_USAGE 和 INFORMATION_SCHEMA 视图,可以列出当前账户中为 REPLICABLE_WITH_FAILOVER_GROUPS 参数设置的值。

小技巧

如果不了解使用 ACCOUNT_USAGE 或者 INFORMATION_SCHEMA 视图的原因,请参阅 Account Usage 与 Information Schema 之间的差异。

示例

对于这些示例,我们将使用 INFORMATION_SCHEMA 视图。这样,您可以在进行任何更改后立即看到设置。

使用预先存在的 replicationadmin 角色,返回该账户的所有参数值,该账户有两个数据库:

  • db1 数据库显式设置为 NO,数据库中的 sch1 架构显式设置为 YES。数据库中只有这一个架构才有资格进行复制。

  • db2 数据库显式设置为 YES,数据库中的 sch2 架构显式设置为 NO。除该架构外,数据库中的所有架构均符合复制条件。

USE ROLE replicationadmin;

SELECT database_name, replicable_with_failover_groups
  FROM db1.INFORMATION_SCHEMA.DATABASES;
+---------------+---------------------------------+
| DATABASE_NAME | REPLICABLE_WITH_FAILOVER_GROUPS |
+---------------+---------------------------------+
| DB1           | NO                              |
| DB2           | YES                             |
| DB3           | UNSET                           |
+---------------+---------------------------------+
SELECT schema_name, catalog_name, replicable_with_failover_groups
  FROM db1.INFORMATION_SCHEMA.SCHEMATA ORDER BY catalog_name;
+--------------------+--------------+---------------------------------+
| SCHEMA_NAME        | CATALOG_NAME | REPLICABLE_WITH_FAILOVER_GROUPS |
+--------------------+--------------+---------------------------------+
| PUBLIC             | DB1          | NO                              |
| SCH1               | DB1          | YES                             |
| SCH2               | DB1          | NO                              |
| SCH3               | DB1          | NO                              |
| INFORMATION_SCHEMA | DB1          | UNSET                           |
+--------------------+--------------+---------------------------------+
USE ROLE replicationadmin;

SELECT schema_name, catalog_name, replicable_with_failover_groups
  FROM db2.INFORMATION_SCHEMA.SCHEMATA
  ORDER BY catalog_name;
+--------------------+--------------+---------------------------------+
| SCHEMA_NAME        | CATALOG_NAME | REPLICABLE_WITH_FAILOVER_GROUPS |
+--------------------+--------------+---------------------------------+
| PUBLIC             | DB2          | YES                             |
| SCH1               | DB2          | YES                             |
| SCH2               | DB2          | NO                              |
| SCH3               | DB2          | YES                             |
| INFORMATION_SCHEMA | DB2          | UNSET                           |
+--------------------+--------------+---------------------------------+

将全局 IDs 应用于目标账户中通过脚本创建的对象

如果您在目标账户中通过复制 以外 的任何方式(例如使用脚本)创建了账户对象(例如用户和角色),则这些用户和角色默认情况下没有全局标识符。刷新操作使用全局标识符将这些对象同步到源账户中的相同对象。

大多数情况下,当从源账户刷新目标账户时,刷新操作会从目标账户中 删除 属于以下类型的所有账户对象:OBJECT_TYPES 列表中没有全局标识符的类型。但是,将用户和角色复制到目标账户的初始操作可能会导致首次刷新操作失败。有关此行为的详细信息,请参阅 用户和角色的初始复制。

用户和角色的初始复制

USERS 和 ROLES 对象类型的初始刷新操作的行为可能会有所不同,具体取决于目标账户中是否存在同名的匹配对象。

备注

  • 本部分中描述的行为仅在 首次 将这些对象类型复制到目标账户时适用。

  • 以下场景描述了如何复制 USERS。该方法同样适用于复制 ROLES。

  • 如果目标账户中存在与源账户中用户同名的现有用户,则初始刷新操作将失败,并描述您必须继续的两个选项:

    • 强制刷新操作并允许删除目标账户中的任何现有用户。源账户中的用户将被复制到目标账户中。

      要强制刷新组,请使用刷新命令的 FORCE 参数。例如,要强制刷新故障转移组,请执行以下命令:

      ALTER FAILOVER GROUP <fg_name> REFRESH FORCE;
      
    • 按名称链接账户对象。借助 SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME 函数,可链接目标账户和源账户中具有相同名称的用户。系统不会删除目标账户中已链接的用户。

      要按名称链接账户对象,请执行以下命令:

      SELECT SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME('<rg_name>');
      

      备注

      如果目标账户中的任何用户在源账户中*没有*与之匹配的同名用户,就会被系统 删除。

  • 如果目标账户中的用户在源账户中 没有 与之匹配的同名用户,则目标账户中的初始刷新操作会删除所有用户。这可能会导致以下数据和元数据丢失:

    • 如果复制组和故障转移组的 OBJECT_TYPES 列表中包含 USERS,则会导致以下数据和元数据丢失:

      • 工作表丢失。

      • 查询历史记录丢失。

    • 如果 OBJECT_TYPES 列表中包含 USERS,但不包含 ROLES,则会导致以下数据和元数据丢失:

      • 向用户授予的权限丢失。

    • 如果 OBJECT_TYPES 列表中包含 ROLES,则会导致以下数据和元数据丢失:

      • 向共享对象授予的权限丢失。

为避免删除目标账户中的用户或角色,请执行以下操作:

  1. 在源账户中,手动重新创建初始复制前*仅*存在于目标账户中的任何用户或角色。

  2. 在目标账户中,使用 SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME 函数链接两个账户中具有相同名称的匹配对象。

配置辅助存储集成的云存储访问权限

如果启用了存储集成复制,则必须在存储集成复制到目标账户后采取其他步骤。复制的集成有自己的 Identity and Access Management (IAM) 实体,该实体与主集成的身份和 IAM 实体不同。因此,您必须更新云提供商权限,以授予复制集成对云存储的访问权限。

此信任关系只需在目标账户上配置一次。

该过程类似于在源账户中授予访问权限。有关更多信息,请参阅以下页面:

配置目录表在辅助暂存区的自动刷新

如果使用目录表复制外部暂存区,并且已为源目录表配置自动刷新,则必须采取步骤为辅助目录表配置 自动刷新。

该过程类似于在源账户中设置自动刷新。有关更多信息,请参阅以下内容:

重要

  • 在目标账户中完成上述配置步骤后,您应当对目录表执行完全刷新,以确保没有遗漏任何通知。

  • 对于 Google Cloud Storage 和 Azure Blob 存储,每个目标账户中的通知集成名称必须与源账户中的通知集成名称一致。

配置辅助自动引入管道的通知

在故障转移之前,您必须采取额外的步骤来配置辅助自动引入管道的云通知。本节介绍了需要此额外配置的原因,以及如何为每个受支持的云提供商完成此配置。

Amazon S3

配置过程取决于设置事件通知的方式。例如,假设您有一个依赖于 Amazon Simple Notification Service (SNS) 主题的自动引入管道,用于发布有关 Snowflake 暂存区位置的消息。

当您将管道复制到目标账户时,Snowflake 会自动创建一个新的 Amazon Simple Queue Service (SQS) 队列。您必须为目标账户的 SQS 队列订阅 SNS 主题,才能获得有关暂存区位置的通知。

Microsoft Azure Blob 存储

在 Microsoft Azure Blob 存储的暂存区上自动加载数据的管道需要事件网格订阅、存储队列,以及绑定到存储队列的通知集成。目标账户中的辅助管道需要单独的事件网格、存储队列以及绑定到存储队列的通知集成。源账户和目标账户中的事件网格必须配置为同一 Azure 存储源的端点。

有关配置详细信息,请参阅下图:

Azure 管道复制

创建新的事件网格订阅和存储队列。然后,在目标账户中创建新的通知集成,并授予 Snowflake 对存储队列的访问权限。有关说明,请参阅 使用 Azure 事件网格配置自动化。

重要

每个目标账户中通知集成的名称 必须 与源账户中通知集成的名称匹配。

Google Cloud Storage 的外部暂存区

自动加载来自位于 Google Cloud Storage 中文件的管道需要 Google Pub/Sub 订阅以及引用该订阅的通知集成。目标账户中的每个复制管道也需要 Google Pub/Sub 订阅,以及引用该订阅的通知集成。每个源账户和目标账户中的 Pub/Sub 订阅必须订阅接收来自 Google Cloud Storage 源通知的相同 Pub/Sub 主题。

有关配置详细信息,请参阅下图:

GCP 管道复制
在目标账户中,创建 Pub/Sub 主题的新订阅和新的通知集成。

然后,授予 Snowflake 对 Pub/Sub 订阅的访问权限。有关说明,请参阅 使用 GCS Pub/Sub 配置自动化。

重要

每个目标账户中通知集成的名称 必须 与源账户中通知集成的名称匹配。

更新 API 集成的远程服务

如果您已启用 API 集成复制,那么在将 API 集成复制到目标账户后,需要采取额外的步骤。复制的集成有自己的 Identity and Access Management (IAM) 实体,该实体与主集成的身份和 IAM 实体不同。因此,您必须更新远程服务上的权限,以授予对复制函数的访问权限。该过程类似于为主要账户上的函数授予访问权限。有关更多信息,请参阅以下链接:

比较主数据库和辅助数据库中的数据集

作为每次复制刷新操作的一部分,Snowflake 都会执行自动验证检查。如果验证失败,则刷新失败。因此,您不必手动验证复制的数据。如果出于合规性原因需要其他验证,可以在刷新操作完成后执行手动验证步骤。

Snowflake 自动验证

目前,Snowflake 会在每次刷新操作后在主账户和辅助账户之间执行以下检查:

  • 对于复制的所有文件,Snowflake 会比较主账户和辅助账户之间的哈希值。

  • 对于每个表,Snowflake 会比较主账户和辅助账户之间的以下值:

    • 文件计数。

    • 行数。

    • 字节数。

手动验证

如果数据库对象在复制组或故障转移组中进行了复制,则您可以使用 HASH_AGG 函数比较主数据库和辅助数据库中部分或全部表中的行,以验证数据一致性。HASH_AGG 函数返回输入行集合的汇总 64 位哈希值。无论输入行的顺序如何,哈希值都是相同的。

在辅助账户和主账户中的所有表或表的随机子集上查询此函数。在主账户中,使用 AT | BEFORE 子句指定关联数据库的最新刷新时间点。比较两个账户的查询的输出。

刷新后手动验证数据的示例

在以下示例中,数据库 mydb 包含在故障转移组 myfg 中。数据库 mydb 包含表 myschema.mytable。

在目标账户上运行的命令
  1. 查询 REPLICATION_GROUP_REFRESH_PROGRESS 表函数(在 Snowflake Information Schema 中)。请注意,primarySnapshotTimestamp 列中的 DETAILS 处于 PRIMARY_UPLOADING_METADATA 阶段。这是主账户上该数据库最近一次刷新的时间戳。

    SELECT PARSE_JSON(details)['primarySnapshotTimestamp']
      FROM TABLE(information_schema.replication_group_refresh_progress('myfg'))
      WHERE PHASE_NAME = 'PRIMARY_UPLOADING_METADATA';
    
  2. 查询辅助账户中指定表的 HASH_AGG 函数。以下查询会返回 myschema.mytable 表中所有行的哈希值:

    SELECT HASH_AGG( * ) FROM mydb.myschema.mytable;
    
在源账户上运行的命令
  1. 查询主账户中同一个表的 HASH_AGG 函数。使用 Time Travel,指定为辅助数据库执行最新刷新时的时间戳:

    SELECT HASH_AGG( * ) FROM mydb.myschema.mytable
      AT(TIMESTAMP => '<primarySnapshotTimestamp>'::TIMESTAMP);
    
  2. 比较这两个查询的结果。输出应该是相同的。

在源账户中修改复制或故障转移组

您可以在源账户中使用 Snowsight 或者 SQL 编辑复制组或故障转移组的名称、包含的对象和复制计划。

备注

不能将复制组更改为故障转移组,反之亦然。要启用或禁用故障转移,请删除该组,然后使用正确的故障转移设置重新创建。

使用 Snowsight 修改源账户中的复制或故障转移组

备注

只有账户管理员才能使用 Snowsight 编辑复制组或故障转移组(请参阅 使用 Snowsight 进行复制配置的限制)。

要执行这些操作,您必须登录到源账户。如果您尚未登录,则 Status 列会显示登录消息,而不是刷新状态。

  1. 登录 Snowsight。

  2. 在导航菜单中,选择 Admin » Accounts。

  3. 依次选择 Replication、Groups。

  4. 定位您要编辑的复制或故障转移组,并选择位于该行最后一列的 More 菜单 (...)。

  5. 选择 Edit。

  6. 要更改组名称,请在 Group name 框中,输入满足以下要求的新名称:

    • 必须以字母字符开头,且不能包含空格或特殊字符,除非标识符字符串被双引号包围(例如“My object”)。放在双引号内的标识符也区分大小写。

      有关更多信息,请参阅 标识符要求。

    • 账户中的故障转移组和复制组的名称必须是唯一的。

  7. 选择 Edit objects 添加或删除共享对象和账户对象。

    备注

    账户对象只能添加到一个复制组或故障转移组。如果您的账户中已存在具有任何账户对象的复制或故障转移组,则无法选择这些对象。

  8. 选择 Select databases 添加或删除数据库对象。

  9. 选择 Replication frequency 更改组的复制计划。

  10. 选择 Save 更新组。

    如果未成功将变更保存到组,请参阅 使用 Snowsight 解决创建和编辑复制组方面的问题 了解常见错误以及解决方法。

使用 SQL 修改源账户中的复制或故障转移组

您可以使用 ALTER REPLICATION GROUP 或 ALTER FAILOVER GROUP 命令修改复制组或故障转移组属性。

在目标账户中暂停或恢复复制计划

您可以使用 Snowsight 或 SQL 在目标账户中暂停或恢复复制计划。

使用 Snowsight 在目标账户中暂停或恢复复制计划

备注

只有账户管理员才能使用 Snowsight 编辑复制组或故障转移组(请参阅 使用 Snowsight 进行复制配置的限制)。

要暂停或恢复复制计划,您必须登录到目标账户。

  1. 登录 Snowsight。

  2. 在导航菜单中,选择 Admin » Accounts。

  3. 依次选择 Replication、Groups。

  4. 定位您要编辑的复制或故障转移组,并选择位于该行最后一列的 More 菜单 (...)。

  5. 选择 Pause 或 Resume。

使用 SQL 在目标账户中暂停或恢复复制计划

您可以使用 ALTER REPLICATION GROUP 或 ALTER FAILOVER GROUP 命令暂停或恢复目标账户中的复制计划。要暂停,请指定 SUSPEND 参数。要恢复,请指定 RESUME 参数。

删除辅助复制组或故障转移组

您可以使用 DROP REPLICATION GROUP 或 DROP FAILOVER GROUP 命令删除辅助复制或故障转移。只有复制组或故障转移组所有者(即具有 OWNERSHIP 组权限的角色)可以删除该组。

您必须在源账户中删除该组,才能使用 Snowsight 删除辅助复制组或故障转移组。请参阅 使用 Snowsight 删除复制组或故障转移组。

删除主复制组或故障转移组

您可以使用 Snowsight 或 SQL 删除主复制组或故障转移组。如果您要使用 SQL 删除主要组,您必须首先删除所有辅助组。请参阅 删除辅助复制组或故障转移组。

使用 SQL 删除主复制组或故障转移组

仅当删除主复制组或故障转移组的所有副本(即辅助复制组或故障转移组)后,才能删除主复制组或故障转移组。或者,您也可以将辅助故障转移组提升为主故障转移组,然后删除以前的主故障转移组。

请注意,只有组所有者才能删除组。

使用 Snowsight 删除复制组或故障转移组

备注

只有账户管理员可以使用 Snowsight 删除复制组或故障转移组(请参阅 使用 Snowsight 进行复制配置的限制)。

您可以删除主复制组或故障转移组以及任何链接的辅助组。

  1. 登录 Snowsight。

  2. 在导航菜单中,选择 Admin » Accounts。

  3. 依次选择 Replication、Groups。

  4. 找到要删除的复制组或故障转移组。选择位于该行最后一列的 More 菜单 (...)。

  5. 依次选择 Drop、Drop group。

使用 Snowsight 解决创建和编辑复制组方面的问题

以下场景可以帮助您解决使用 Snowsight 创建或编辑复制组或故障转移组时可能出现的常见问题。

您无法将数据库添加到组中

错误

Database '<database_name>' is already configured to replicate to
account '<account_name>' by replication group '<group_name>'.

原因

一个数据库只能属于一个复制组或故障转移组。您为该组选择的数据库之一已包含在另一个复制组或故障转移组中。

解决方案

选择 Select Databases 并取消选择已包含在另一组中的任何数据库。

错误

Cannot directly add previously replicated object '<database_name>' to a
replication group. Please use the provided system functions to convert
this object first.

原因

要添加到复制组或故障转移组的数据库先前已配置为数据库复制。

解决方案

禁用数据库的数据库复制。请参阅 从 Database Replication 转换为基于组的复制。

您无法将共享添加到组中

错误

Share '<share_name>' is already configured to replicate to
account '<account_name>' by replication group '<group_name>'.

原因

一个共享只能属于一个复制组或故障转移组。您为该组选择的共享之一已包含在另一个复制组或故障转移组中。

解决方案

选择 Select Objects 并取消选择已包含在另一个组中的任何共享。

使用 Snowsight 进行复制配置的限制

  • 只有具有 ACCOUNTADMIN 角色的用户才能使用 Snowsight 创建复制组或故障转移组。具有 CREATE REPLICATION GROUP 或 CREATE FAILOVER GROUP 权限角色的用户可以使用相应的自 SQL 命令创建组。

  • 只有具有 ACCOUNTADMIN 角色的用户才能使用 Snowsight 编辑或删除复制组或故障转移组。具有复制组或故障转移组 OWNERSHIP 权限角色的用户可以使用相应的 SQL 命令编辑和删除组。

  • 如果您的账户使用的是私有连接,则无法使用 Snowsight 来创建、修改或删除群组。您可以使用 SQL 来完成这些操作。