业务连续性和灾难恢复中的列表支持

提供商可以将列表及其依赖项(例如共享和数据库)包含在 账户复制和故障转移组 中。通过故障转移组,如果发生服务降级或停机,该列表将依赖故障转移组进行数据复制和灾难恢复。

备注

术语

  • 主列表:主故障转移组中的列表

  • 辅助列表:辅助故障转移组中的列表

理解业务连续性和灾难恢复的需求

当主区域发生中断时,业务连续性和灾难恢复 (BCDR) 对提供商而言至关重要。

  • 提供商必须在中断期间以最小的干扰继续支持其数据产品。

  • 提供商必须遵守有关 RTO(恢复时间目标)和 RPO(恢复点目标)的服务水平协议 (SLAs),以避免经济处罚。

  • 提供商必须在辅助区域维护其数据的副本,以应对中断情况。

故障转移和恢复的手动配置

未将列表添加到其故障转移组的提供商,其恢复时间更长,且向其使用者提供的信息会过时。如果没有 BCDR,提供商必须在故障转移后在辅助区域重新创建列表。然后使用者必须重新挂载到新的列表 URLs。这种手动复制会导致 ETL 管道和应用程序发生大规模中断,从而延长消费者的停机时间,并增加提供商的数据传输成本。

自动故障转移和恢复

列表 BCDR 提升了企业就绪性,并减少了故障所造成的中断。

  • 列表 BCDR 免除了提供商在故障转移后重新创建列表的需求。

  • 新的主区域不会向安全共享区 (SSA) 账户重新进行复制,由于仅将增量更改复制到 SSA 账户,从而节省了数据传输成本。

借助对列表的 BCDR 支持,在故障转移之后:

  • 使用者仍可访问提供方的数据,不会出现停机。

  • 提供商可从新的主区域满足新的实用者区域的需求。

  • 提供商仍可满足使用者对数据新鲜度的要求,因为列表会从新的主区域进行刷新。

列表的 BCDR 工作流程

列表的典型 BCDR 工作流程如下:

  1. 中断事件影响该区域,波及主区域。

    • 当主区域宕机时,使用者区域中的列表无法刷新。因此,使用者使用的是过时数据。

  2. 数据恢复管理员启动组织的运行手册。

  3. 管理员获准故障转移至辅助区域。

    • 该辅助区域将成为新的主区域。

    • 故障转移组中的副本成为所有对象的新信息源。

  4. 管理员使用数据源(例如外部表和 ETL 管道)的最新更新来刷新新的主区域。

    • 管理员获取新主区域中对象的快照,以验证其是否拥有最新数据。

    • 管理员审计新的主区域,以确认其是否已准备好投入生产。

    • 故障转移完成后,自动履行功能将在下一个刷新间隔从新的主数据库重新开始工作。

备注

管理员可以使用 SHOW LISTINGS IN FAILOVER GROUP 命令来确认列表已准备好投入生产。

BCDR 选择标准

在以下情况下不支持 BCDR:

  • 列表处于草稿状态。

  • 列表由暂存区支持。

  • 列表是付费列表。

  • 列表未启用 自动履行

  • 列表是 Snowflake Native App 列表。

行为、注意事项和约束

请阅读以下各部分,以了解列表 BCDR 的行为、注意事项和约束。

行为

  • 如果删除辅助故障转移组,则故障转移组中的辅助列表也会自动删除。

注意事项

  • 目前,不支持对外部管理的 Iceberg 表进行故障转移,尽管这些表支持自动履行。托管 Iceberg 表的故障转移当前处于 公开预览 阶段。

  • 某些功能可能不支持在数据库层面的故障转移,但在列表层面可能支持故障转移。在复制过程中,不支持的对象将被忽略。

约束

在配置列表的 BCDR 之前,请确保您理解以下约束:

完整子集约束(全有或全无规则)

  • 向故障转移组添加对象时,如果该对象被已启用自动履行的列表引用,则该同一列表引用的所有对象都必须包含在同一故障转移组中。

  • 从故障转移组移除对象时,如果该对象被已启用自动履行的列表引用,则该同一列表引用的所有对象必须一起移除。

故障转移组对象类型要求

当故障转移组包含被已启用自动履约的列表引用的数据库或共享时,故障转移组必须在其 OBJECT_TYPES 参数中包含 LISTINGS。例如:

CREATE FAILOVER GROUP provider_dr_fg
  OBJECT_TYPES = DATABASES, LISTINGS
  ...

列表自动履行设置约束

  • 在列表上启用自动履行或发布已启用自动履行的列表之前,所有列表依赖项(包括共享和数据库)必须配置在包含 LISTINGS 对象类型的故障转移组中。

  • 必须在辅助账户上手动启用自动履行(如果尚未启用)。有关更多信息,请参阅 SYSTEM$ENABLE_GLOBAL_DATA_SHARING_FOR_ACCOUNT

  • 当列表使用 REFERENCE_USAGE 权限时,可能存在与列表无直接关联但仍被计为完整子集约束中一部分的对象。

内部 Marketplace 列表约束

以下约束适用于内部 Marketplace 上的列表(组织内部列表):

申请审批工作流程
  • 如果使用者提交了尚未获批的组织列表请求,并且系统故障转移到辅助部署,则副本提供商将看不到该使用者的请求。这是因为请求与最初提出请求的部署环境相关联。使用者需要重新请求列表。

  • 在故障恢复到主区域后,尝试取消发布列表时,在以下场景中将失败:

    • 使用者请求了位于主区域及其故障转移区域中的列表,并且

    • 使用者重新请求了列表,而该请求在处于辅助区域时已获批。

    出现此失败是因为原始待处理请求仍然存在。要成功取消发布,提供商必须明确拒绝原始请求,然后重新尝试取消发布操作。

数据字典
  • 精选对象不属于故障转移复制过程的一部分。因此,在主实例上选择的任何精选对象在故障转移后都不会反映在辅助实例上。提供商必须在故障转移后手动重置这些对象。如果提供商没有重置精选对象,使用者将看到过时的数据字典,即使他们添加了新表也是如此。这是因为后台作业会跳过此列表。设置精选对象后,后台作业将获取此列表。

  • 如果在系统作为副本运行时对精选对象进行了任何修改,这些更改在故障恢复后将不会同步回原始主实例。

数据预览
  • 数据预览信息不会复制到辅助区域。因此,故障转移后,使用者将看不到任何数据预览文件。在辅助区域上,提供商必须重新生成数据预览文件。

  • 与数据字典类似,在故障转移期间对数据预览所做的任何更改在故障恢复后都不会同步回原始主区域。提供商可以在故障恢复后在原始主区域上重置数据预览信息。

组织配置文件
  • 主要提供商和辅助提供商都必须使用可以发布列表的 配置文件

配置文件复制约束

  • 如果配置文件未由故障转移组复制,则辅助账户上的列表将继续工作,但不会附加任何配置文件。

  • 如果配置文件未由故障转移组复制,则在故障转移和故障恢复刷新后,原始主账户的配置文件将保持不变。

  • 在发生故障转移之前,辅助账户的配置文件处于只读状态。故障转移后,新的主账户可以创建、更改或删除配置文件。

  • 如果辅助账户已有本地配置文件,初始故障转移组刷新将故意失败,以避免潜在的数据丢失。请按照查询结果消息中的步骤继续操作。

  • 配置文件审批请求不会被复制。如果原始主账户中有任何待处理的审批请求,则在故障转移后,新的主账户可以重新请求审批。

只读辅助列表约束

无法直接修改辅助列表。所有写入操作,例如 ALTER 和 DROP,必须在主列表上执行。