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

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

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

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

SELECT SYSTEM$DISABLE_DATABASE_REPLICATION('mydb');

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

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

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

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

示例¶

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

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

组织管理员（ORGADMIN 角色）必须为源账户和目标账户启用复制。

要启用账户复制，具有 ORGADMIN 角色的用户可使用 SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER 函数将 ENABLE_ACCOUNT_DATABASE_REPLICATION 参数设置为 true。请注意，一个组织中的多个账户可以通过同一 ORGADMIN 账户进行复制。

登录 ORGADMIN 账户来为组织中的每个源账户和目标账户启用复制。

USE ROLE ORGADMIN;

-- 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 权限。此步骤是可选的。如已创建此角色，请跳转至 第 2 步：在源账户中创建主故障转移组。

USE ROLE ACCOUNTADMIN;

CREATE ROLE myrole;

GRANT CREATE FAILOVER GROUP ON ACCOUNT
    TO ROLE myrole;

第 2 步：在源账户中创建主故障转移组¶

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

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        |
+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+

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';

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

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

USE ROLE ACCOUNTADMIN;

CREATE ROLE myrole;

GRANT CREATE FAILOVER GROUP ON ACCOUNT
    TO ROLE myrole;

第 4 步：在目标账户中创建辅助故障转移组¶

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

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

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

USE ROLE myrole;

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

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

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

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

第 6 步：为角色授予故障转移组的 FAILOVER 权限 – 可选¶

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

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

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

GRANT FAILOVER ON FAILOVER GROUP myfg TO ROLE my_failover_role;

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

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

使用 SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME() 应用全局 IDs¶

通过链接源账户和目标账户中具有相同名称的匹配对象，可以防止某些对象类型丢失。借助 SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME 函数，可将全局标识符添加到目标账户中的账户对象。

将全局标识符应用于故障转移组 myfg 的 object_types 列表中的目标账户中的账户对象类型：

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

SELECT SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME('myfg');

用户和角色的初始复制¶

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

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

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

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

    ALTER FAILOVER GROUP <fg_name> REFRESH FORCE;
    

    Copy

  • 按名称链接账户对象。借助 SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME 函数，可链接目标账户和源账户中具有相同名称的用户。系统不会删除目标账户中已链接的用户。

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

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

    Copy

    备注

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

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

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

    • 工作表丢失。

    • 查询历史记录丢失。

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

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

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

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

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

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

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

Amazon S3¶

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

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

• 如果您将 Amazon S3 事件通知与 Amazon Simple Queue Service (SQS)，请按照 第 4 步：配置事件通知 中的说明进行操作。

  重要

  为了确保管道没有遗漏任何通知，您应该在切换到新 SQS 队列后刷新管道。

  您也可以从 SQS 迁移到 SNS。有关更多信息，请参阅 迁移到 Amazon Simple Notification Service (SNS)。

• 如果您使用的是 Amazon Simple Notification Service (SNS)，请参阅 将 Snowflake SQS 队列订阅至 SNS 主题中。

• 如果您使用的是 Amazon EventBridge，请参阅 选项 3：设置 Amazon EventBridge 以自动执行 Snowpipe。

Microsoft Azure Blob 存储¶

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

有关配置详细信息，请参阅下图：

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

Google Cloud Storage 的外部暂存区¶

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

有关配置详细信息，请参阅下图：

在目标账户中，创建 Pub/Sub 主题的新订阅和新的通知集成。

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

使用 Snowsight 监控复制¶

要监控组织中 复制组和故障转移组 的复制进度和状态，请使用 Snowsight 中的 Replication 页面。

您可以查看刷新操作的状态和详细信息：

• 查看最近刷新操作的当前状态。

• 查看副本滞后时间（自上次刷新操作以来的时间）。

• 查看各组的副本滞后时间分布。

• 查看下一次计划刷新操作的日期和时间。

要查看每个复制组或​​故障转移组的复制状态，请完成以下步骤：

1. 登录到 Snowsight 并导航至 Admin » Accounts。

2. 选择 Replication，然后选择 Groups。

Groups 页面显示了具有查看权限角色所在所有组的 刷新操作详细信息。您可以使用磁贴来筛选视图。

• 例如，如果 Status 磁贴指示刷新操作失败，您可以选择该磁贴来调查存在故障的组。

• Longest Replication lag 磁贴中的滞后时间指的是自上次刷新操作以来的持续时间。这是辅助复制组或故障转移组*滞后*于主要组的时间长度。最长滞后时间指的是自最旧的辅助复制组上次刷新以来的时间长度。

  例如，如果您有三个故障转移组 fg_1、fg_2、fg_3，其独立的复制计划分别为 10 分钟、2 小时和 12 小时，则最长滞后时间可能长达 12 小时。但是，如果 fg_3 在目标账户中最近刷新过，则其滞后时间会重置为 0，不同的故障转移组可能会有更长的滞后时间。

• 您可以选择 Group Lag Distribution 磁贴中的单个条形图来将结果筛选到单个组。

您还可以使用搜索字段或下拉菜单来筛选组：

• 您可以使用 |sf-search-icon|（搜索框按复制组或故障转移组名称进行搜索。

• 选择 Type 即可按复制组或故障转移组筛选结果。

• 选择 Replicating 即可按主要组（选择 To）或次要组（选择 From）进行筛选。

• 选择 |sf-account-icon|（账户）菜单即可按账户名称筛选结果。

• 选择 Status 即可按刷新操作状态筛选结果：

  • Refresh Cancelled

  • Refresh Failed

  • Refresh In Progress

  • Refresh Successful

您可以查看有关复制组和故障转移组的以下详细信息：

您可以选择一个复制组或故障转移组，查看有关每次刷新操作的详细信息。有关更多信息，请参阅 Snowsight 中有关复制历史记录的部分。

监控刷新操作的进度¶

本节提供了有关如何监控特定复制组或故障转移组的复制进度的信息。

SELECT phase_name, start_time, end_time, progress, details
  FROM TABLE(INFORMATION_SCHEMA.REPLICATION_GROUP_REFRESH_PROGRESS('myfg'));

查看复制历史记录¶

您可以使用 Snowsight 或 SQL 查看复制历史记录。

使用 Snowsight 查看复制历史记录¶

您可以在组的详细信息页面中查看特定复制组或故障转移组每个刷新操作的复制历史记录和详细信息。

1. 登录到 Snowsight 并导航至 Admin » Accounts。

2. 依次选择 Replication、Groups。

3. 选择复制组或故障转移组的名称。

然后，您可以查看有关该组的以下信息：

• 组类型（复制组或故障转移组）。

• 复制计划（例如，每 10 分钟一次）。

• 每次刷新操作的持续时间。

• 副本滞后时间（自上次刷新操作以来的时间长度）。

• 下一次计划刷新操作的日期和时间。

您可以按状态和时间段对页面上的数据进行筛选：

• 选择 Status 即可按刷新操作状态筛选结果：

  • Refresh Cancelled

  • Refresh Failed

  • Refresh In Progress

  • Refresh Successful

• 选择 Duration 以显示以下时间段的刷新操作详细信息：

  • Last hour

  • Last 24 hours

  • Last 7 days

  • All

  选择 All 显示最近 14 天的刷新操作。

每次刷新操作的详细信息包括以下列：

列	描述
Query ID	刷新操作的查询 ID。
Status	显示刷新操作的状态。有效值包括 Successful、Failed、In Progress。
Ended	刷新操作结束的日期和时间。
Duration	刷新操作完成所需的时间长度。 持续时间按 复制阶段 进行了细分，并用颜色进行了编码。每个色段的宽度表示在该阶段花费的时间比例。 以下图像仅供参考。当您 选择刷新操作 了解更多详情时，系统将显示此图表。
Transferred	复制的字节数。
Objects	复制的对象数量。

选择一行以查看有关特定刷新操作的其他详细信息，包括：

• 每个复制阶段的持续时间。

• 错误消息（针对失败的刷新操作）。

• 按类型和数量复制的数据库对象列表。

• 复制的数据库数量和数据库名称。

SELECT PHASE_NAME, START_TIME, END_TIME, TOTAL_BYTES, OBJECT_COUNT
  FROM TABLE(information_schema.replication_group_refresh_history('myfg'))
  WHERE START_TIME >= current_date - interval '7 days';

SELECT REPLICATION_GROUP_NAME, PHASE_NAME, START_TIME, END_TIME, TOTAL_BYTES, OBJECT_COUNT
  FROM snowflake.account_usage.replication_group_refresh_history
  WHERE START_TIME >= date_trunc('month', current_date());

监控复制成本¶

要监控复制的 Credit 使用量，请查询以下内容之一：

• REPLICATION_GROUP_USAGE_HISTORY 视图 （在 Account Usage 中）。

• REPLICATION_GROUP_USAGE_HISTORY 表函数（在 Snowflake Information Schema 中）。

SELECT start_time, end_time, replication_group_name, credits_used, bytes_transferred
  FROM table(information_schema.replication_group_usage_history(date_range_start=>dateadd('day', -7, current_date())));

SELECT start_time, 
  end_time, 
  replication_group_name, 
  credits_used, 
  bytes_transferred
FROM snowflake.account_usage.replication_group_usage_history
WHERE start_time >= DATE_TRUNC('month', CURRENT_DATE());

监控数据库的复制成本¶

对于包含在复制或故障转移组中的单个数据库的复制成本，可以通过检索数据库的复制字节数并将其与使用的 Credit 相关联来计算。

示例¶

在下面的示例中，数据库 mydb 包含在故障转移组 myfg 中。数据库 mydb 包含表 mytable。

使用 Snowsight 修改复制组或故障转移组¶

要编辑组名称，您必须登录目标账户。如果您尚未登录，则 Status 列会显示登录消息，而不是刷新状态。

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

1. 登录到 Snowsight 并导航至 Admin » Accounts。

2. 依次选择 Replication、Groups。

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

4. 选择 Edit。

5. 要更改组名称，请在 Group Name 框中，输入满足以下要求的新名称：

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

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

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

6. 选择 Select Objects 添加或删除共享对象和账户对象。

   备注

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

7. 选择 Select Databases 添加或删除数据库对象。

8. 选择 Replication Frequency 更改组的复制计划。

9. 选择 Save Changes 更新组。

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

使用 SQL 修改复制组或故障转移组¶

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

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

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

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

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

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

1. 登录到 Snowsight 并导航至 Admin » Accounts。

2. 依次选择 Replication、Groups。

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

4. 依次选择 Drop、Drop Group。

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

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

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

您无法将共享添加到组中¶

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