灾难恢复
清晰的灾难恢复模式对于云原生数据分析平台（例如 Azure Databricks）至关重要。 至关重要的是，即使在区域性服务范围内的云服务提供商因区域性灾难（如飓风、地震）或其他源而中断的罕见情况下，数据团队也可以使用 Azure Databricks 平台。
Azure Databricks 通常是包括许多服务的整个数据生态系统的核心部分，其中包括上游数据引入服务（批/流式处理）、ADLS gen2（对于 2023 年 3 月 6 日之前创建的工作区，则为 Azure Blob 存储）之类的云原生存储、下游工具和服务（例如商业智能应用）以及业务流程工具。 某些用例可能对区域性服务范围内的中断特别敏感。
本文介绍可成功用于 Databricks 平台的区域间灾难恢复解决方案的概念和最佳做法。
区域内高可用性保证
虽然本主题的其余部分侧重于跨区域灾难恢复的实施，但了解 Azure Databricks 在单个区域内提供的高可用性保证非常重要。 区域内高可用性保证涵盖以下组件：
Azure Databricks 控制平面的可用性
- 大多数控制平面服务都运行在 Kubernetes 群集上，会自动处理在特定 AZ 中丢失 VM 的事宜。
- 工作区数据存储在使用高级存储的数据库中，在整个区域进行复制。 存储数据库（单台服务器）时，不会跨不同的 AZ 或区域进行复制。 如果区域中断影响数据库的存储，则通过从备份中启动一个新实例来恢复数据库。
- 用于处理 DBR 图像的存储帐户在区域内也是冗余的，所有区域都有在主要区域关闭时使用的辅助存储帐户。 请参阅 Azure Databricks 区域。
- 通常，在可用性区域恢复后，控制平面功能应该会在大约 15 分钟内还原。
计算平面的可用性
- 工作区可用性取决于控制平面的可用性（如上所述）。
- 如果 DBFS 根的存储帐户配置了 ZRS 或 GZRS（默认为 GRS），则 DBFS 根上的数据不受影响。
- 通过从 Azure 计算提供程序请求节点（假设剩余区域中有足够的容量来满足请求），从不同的可用性区域中拉取群集的节点。 如果某个节点丢失，群集管理器会从 Azure 计算提供程序请求替换节点，该提供程序会从可用的 AZ 中拉取这些节点。 唯一的例外是驱动程序节点丢失。 在这种情况下，作业或群集管理器会重启它们。
灾难恢复概述
灾难恢复涉及一组策略、工具和过程，可在发生自然或人为灾难后恢复或延续重要的技术基础结构和系统。 大型云服务（如 Azure）可为许多客户提供服务，并且具有针对单一故障的内置防护措施。 例如，区域是一组连接到不同电源的建筑物，可确保单个电源丢失不会关闭某个区域。 但是，可能会发生云区域故障，并且中断程度及其对组织的影响可能会有所不同。
在实施灾难恢复计划之前，务必了解灾难恢复 (DR) 和高可用性 (HA) 之间的区别。
高可用性是系统的复原能力特性。 高可用性可确保最低级别的操作性能，该性能通常由一致的运行时间或运行时间百分比来定义。 可通过将高可用性设计为主系统的一项功能来实现高可用性（在与主系统相同的区域）。 例如，Azure 之类的云服务具有 ADLS gen2（对于 2023 年 3 月 6 日之前创建的工作区，则为 Azure Blob 存储）之类的高可用性服务。 高可用性不需要 Azure Databricks 客户进行大量的显式准备。
相比之下，灾难恢复计划需要适用于特定组织的决策和解决方案，以应对关键系统更大的区域性中断。 本文讨论了使用 Azure Databricks 的灾难恢复计划的常用灾难恢复术语、常用解决方案以及一些最佳做法。
术语
区域术语
本文使用以下区域定义：
主要区域：用户运行典型日常交互和自动数据分析工作负载的地理区域。
次要区域：IT 团队在主要区域中断期间暂时移动数据分析工作负载的地理区域。
异地冗余存储：Azure 具有跨区域的异地冗余存储，用于使用异步存储复制过程的持久化存储。
重要
对于灾难恢复过程，Databricks 建议不要依赖异地冗余存储来跨区域复制数据，例如 Azure Databricks 为 Azure 订阅中的每个工作区创建的 ADLS gen2（对于 2023 年 3 月 6 日之前创建的工作区，则为 Azure Blob 存储）。 通常，对增量表使用深度克隆，并将数据转换为增量格式，以便对其他数据格式使用深度克隆。
部署状态术语
本文使用以下部署状态定义：
主动部署：用户可以连接到 Azure Databricks 工作区的主动部署并运行工作负载。 使用 Azure Databricks 计划程序或其他机制定期安排作业。 也可在此部署过程中执行数据流。 有些文档可能会将主动部署称为热部署。
被动部署：过程不会在被动部署上运行。 IT 团队可以设置自动化过程，以将代码、配置和其他 Azure Databricks 对象部署到被动部署。 只有在当前主动部署处于关闭状态时，部署才会变为主动。 有些文档可能会将被动部署称为冷部署。
重要
一个项目可以选择性地在不同区域包含多个被动部署，以提供用于解决区域性中断的其他选项。
一般来说，在所谓的主动-被动灾难恢复策略中，一个团队一次只有一个主动部署。 有一种不太常见的灾难恢复解决方案策略称为主动-主动，其中有两个同时进行的主动部署。
灾难恢复行业术语
下面是必须了解并为团队定义的两个重要行业术语：
恢复点目标：恢复点目标 (RPO) 是由于重大事件而可能导致 IT 服务丢失数据（事务）的最大目标时间段。 Azure Databricks 部署不存储主要客户数据。 它存储在 ADLS gen2（对于 2023 年 3 月 6 日之前创建的工作区，则为 Azure Blob 存储）之类的单独系统中，或你所控制的其他数据源中。 Azure Databricks 控制平面部分或全部存储一些对象，例如作业和笔记本。 对于 Azure Databricks，RPO 定义为可能会丢失对象（例如作业和笔记本）更改的最大目标时间段。 此外，你还负责在 ADLS gen2（对于 2023 年 3 月 6 日之前创建的工作区，则为 Azure Blob 存储）或你所控制的其他数据源中为你自己的客户数据定义 RPO。
恢复时间目标：恢复时间目标 (RTO) 是灾难之后必须还原业务流程的目标时限和服务级别。
灾难恢复和数据损坏
灾难恢复解决方案不能缓解数据损坏。 主要区域中损坏的数据从主要区域复制到次要区域，并且在两个区域中都是损坏的。 还可通过其他方法缓解此类故障，例如 Delta 按时间顺序查看。
典型恢复工作流
Azure Databricks 灾难恢复方案通常通过以下方式来实现：
故障发生在你在主要区域使用的关键服务中。 这可以是数据源服务，也可以是影响 Azure Databricks 部署的网络。
可以通过云提供商调查情况。
如果你断定公司无法等待主要区域中的问题得到修复，则可以决定需要故障转移到次要区域。
确认同一问题不会也影响次要区域。
故障转移到次要区域。
- 停止工作区中的所有活动。 用户停止工作负载。 如果可能，指示用户或管理员备份最近的更改。 如果作业尚未因中断而失败，则其将被关闭。
- 在次要区域中启动恢复过程。 恢复过程将连接和网络流量的路由和重命名更新到次要区域。
- 测试完成后，声明次要区域可运行。 生产工作负载现在可以继续。 用户可以登录到当前主动部署。 可以重新触发计划的作业或延迟的作业。
有关 Azure Databricks 上下文中的详细步骤，请参阅测试故障转移。
在某些时候，主要区域中的问题得到缓解，你可以确认这一事实。
还原（故障回复）到主要区域。
- 停止次要区域中的所有工作。
- 在主要区域中启动恢复过程。 恢复过程将连接和网络流量的路由和重命名处理回主要区域。
- 根据需要将数据复制回主要区域。 为了降低复杂性，也许可以最大程度地减少需要复制的数据量。 例如，如果某些作业在辅助部署中运行时是只读的，则可能不需要将该数据复制回主要区域中的主部署。 但是，你可能有一个需要运行的生产作业，并且可能需要将数据复制回主要区域。
- 在主要区域中测试部署。
- 声明你的主要区域可运行并且它是主动部署。 恢复生产工作负载。
有关还原到主要区域的详细信息，请参阅测试还原（故障回复）。
重要
在这些步骤中，一些数据可能会丢失。 你的组织必须定义可接受的数据丢失量以及可用于缓解数据丢失的措施。
步骤 1：了解你的业务需求
第一步是定义并了解业务需求。 定义哪些数据服务属于关键服务及其期望的 RPO 和 RTO 是什么。
研究每个系统的实际容错能力，请记住，灾难恢复故障转移和故障回复可能会花费大量成本，并可能带来其他风险。 其他风险可能包括数据损坏、数据重复（如果将数据写入错误的存储位置）以及用户在错误的位置登录并进行更改。
映射影响业务的所有 Azure Databricks 集成点：
- 灾难恢复解决方案是否需要适应交互式过程和/或自动化过程？
- 你使用哪些数据服务？ 有些服务可能是本地服务。
- 输入数据如何到达云？
- 谁会使用此数据？ 哪些过程在下游使用了该数据？
- 是否存在需要了解灾难恢复更改的第三方集成？
确定可支持灾难恢复计划的工具或通信策略：
- 你将使用哪些工具来快速修改网络配置？
- 是否可以预定义配置并使之模块化，以便以自然且可维护的方式适应灾难恢复解决方案？
- 哪些通信工具和通道会将灾难恢复故障转移和故障回复的更改告知内部团队和第三方（集成、下游使用者）？ 如何确认他们是否已进行确认？
- 需要哪些工具或特殊支持？
- 在完全恢复之前，将关闭哪些服务（如果有）？
步骤 2：选择可满足业务需求的过程
你的解决方案必须在控制平面、计算平面和数据源中复制正确的数据。 用于灾难恢复的冗余工作区必须映射到不同区域中的不同控制平面。 必须使用基于脚本的解决方案（同步工具或 CI/CD 工作流）定期使数据保持同步。 不需要同步计算平面网络（例如 Databricks Runtime 辅助角色）内部的数据。
如果使用 VNet 注入功能（并非所有订阅和部署类型都可使用此功能），则可以使用基于模板的工具（例如 Terraform）在两个区域中一致地部署这些网络。
此外，需要确保跨区域复制所需的数据源。
一般最佳实践
成功的灾难恢复计划的一般最佳做法包括：
了解哪些过程对业务至关重要且必须在灾难恢复中运行。
清楚地确定涉及的服务、正在处理的数据、数据流的含义以及存储位置
尽可能隔离服务和数据。 例如，为灾难恢复数据创建特殊的云存储容器，或将灾难期间所需的 Azure Databricks 对象移至单独的工作区。
你需要负责为未存储在 Databricks 控制平面中的其他对象维护主部署和辅助部署之间的完整性。
警告
最佳做法是不将任何数据元素存储在用于工作区根 DBFS 访问的根 ADLS gen2（对于 2023 年 3 月 6 日之前创建的工作区，则为 Azure Blob 存储）中。 生产客户数据不支持此根 DBFS 存储。 不过，你可以存储其他对象，例如库、配置文件、init 脚本和类似数据。 要么开发一个自动过程来复制这些对象，要么记住制定相应的过程来更新辅助部署以进行手动部署。
对于数据源，建议尽可能使用用于复制和冗余的原生 Azure 工具将数据复制到灾难恢复区域。
选择恢复解决方案策略
典型的灾难恢复解决方案涉及两个（或可能更多）工作区。 有几种策略供你选择。 考虑潜在的中断时长（几小时甚至一天），以及确保工作区完全正常运行和还原（故障回复）到主要区域所需的工作量。
主动-被动解决方案策略
主动-被动解决方案是最常见且最简单的解决方案，本文将重点介绍此类解决方案。 主动-被动解决方案将数据和对象更改从主动部署同步到被动部署。 如果愿意，你可以在不同区域中拥有多个被动部署，但本文重点介绍单一被动部署方法。 在灾难恢复事件期间，次要区域中的被动部署将成为主动部署。
此策略有两个主要变体：
- 统一（企业范围）的解决方案：只有一组支持整个组织的主动和被动部署。
- 按部门或项目划分的解决方案：每个部门或项目域都维护一个单独的灾难恢复解决方案。 一些组织希望将各部门之间的灾难恢复详细信息分离开来，并根据每个团队的独特需求为每个团队使用不同的主要区域和次要区域。
还有其他变体，例如将被动部署用于只读用例。 如果你有只读工作负载（例如用户查询），只要这些工作负载不修改数据或 Azure Databricks 对象（例如笔记本或作业），则它们均可随时在被动解决方案上运行。
主动-主动解决方案策略
在主动-主动解决方案中，始终可以在两个区域中并行运行所有数据进程。 操作团队必须确保仅在两个区域都成功完成时，才将数据过程（例如作业）标记为已完成。 对象不能在生产中进行更改，且必须严格遵循 CI/CD 从开发/过渡到生产的提升。
主动-主动解决方案是最复杂的策略，由于作业在两个区域中运行，因此会产生额外的财务成本。
与主动-被动策略一样，可以将其作为统一的组织解决方案或按部门划分的解决方案。
辅助系统中可能不需要所有工作区都具有相同的工作区，具体取决于工作流。 例如，也许开发或过渡工作区可能不需要副本。 使用精心设计的开发管道，可以在需要时轻松重构这些工作区。
选择工具
在主要区域和次要区域中，各工具可以通过两种主要方法来保持工作区之间的数据尽可能相似：
- 同步从主要区域复制到次要区域的客户端：同步客户端将生产数据和资产从主要区域推送到次要区域。 通常，此操作按计划运行。
- 用于并行部署的 CI/CD 工具：对于生产代码和资产，请使用 CI/CD 工具将对生产系统的更改同时推送到两个区域。 例如，在将代码和资产从过渡/开发推送到生产时，CI/CD 系统会使其同时在两个区域中可用。 核心理念是将 Azure Databricks 工作区中的所有项目都视为基础结构即代码。 大多数项目都可以同时部署到主要工作区和次要工作区，而某些项目可能仅在灾难恢复事件之后才需要部署。 若要获取工具，请参阅自动化脚本、示例和原型。
下图对比了这两种方法。
可以按需组合使用这些方法。 例如，将 CI/CD 用于笔记本源代码，但将同步用于配置（如池和访问控制）。
下表说明如何使用每个工具选项处理不同类型的数据。
| 说明 | 如何使用 CI/CD 工具进行处理 | 如何使用同步工具进行处理 |
|---|---|---|
| 源代码：笔记本源代码导出和打包库的源代码 | 共同部署到主要区域和次要区域。 | 将源代码从主要区域同步到次要区域。 |
| 用户和组 | 在 Git 中将元数据作为配置进行管理。 或者，对两个工作区使用相同的标识提供者 (IdP)。 将用户和组数据共同部署到主要部署和辅助部署。 | 对两个区域都使用 SCIM 或其他自动化工具。 不建议手动创建，但如果使用手动创建，则必须同时对两个区域进行创建。 如果使用手动设置，请创建一个计划的自动化过程，以在两个部署之间比较用户和组的列表。 |
| 池配置 | 可以是 Git 中的模板。 共同部署到主要区域和次要区域。 但在灾难恢复事件之前，次要区域中的 min_idle_instances 必须为零。 |
使用 API 或 CLI 将池同步到次要工作区时，使用任何 min_idle_instances 创建的池。 |
| 作业配置 | 可以是 Git 中的模板。 对于主要部署，请按原样部署作业定义。 对于辅助部署，请部署作业并将并发数设置为零。 这将禁用此部署中的作业，并阻止额外的运行。 在辅助部署变为主动状态后，更改并发数值。 | 如果作业由于某种原因在现有 <interactive> 群集上运行，则同步客户端需要映射到次要工作区中的相应 cluster_id。 |
| 访问控制列表 (ACL) | 可以是 Git 中的模板。 共同部署到笔记本、文件夹和群集的主要部署和辅助部署。 但在灾难恢复事件发生前，请保存作业的数据。 | 权限 API 可以为群集、作业、池、笔记本和文件夹设置访问控制。 同步客户端需要映射到次要工作区中每个对象的相应对象 ID。 Databricks 建议创建对象 ID 从主要工作区到次要工作区的映射，同时在复制访问控制之前同步这些对象。 |
| 库 | 包含在源代码和群集/作业模板中。 | 从集中式存储库、DBFS 或云存储（可以装载）中同步自定义库。 |
| 群集初始化脚本 | 如果愿意，可以包含在源代码中。 | 为了简化同步，将 init 脚本存储在主要工作区的公用文件夹或一小部分文件夹中（如果可能）。 |
| 装入点 | 如果仅通过基于笔记本的作业或命令 API 创建，则包含在源代码中。 | 使用作业，这些作业可以作为 Azure 数据工厂 (ADF) 活动运行。 请注意，假设工作区位于不同区域，则存储终结点可能会发生更改。 这在很大程度上也取决于数据灾难恢复策略。 |
| 表元数据 | 如果仅通过基于笔记本的作业或命令 API 创建，则包含在源代码中。 这适用于内部 Azure Databricks 元存储或外部配置的元存储。 | 通过笔记本或脚本，使用 Spark 目录 API 或 Show Create Table 来比较元存储之间的元数据定义。 请注意，用于基础存储的表可以基于区域，并且在元存储实例之间将有所不同。 |
| 机密 | 如果仅通过命令 API 创建，则包含在源代码中。 请注意，某些机密内容可能需要在主要区域和次要区域之间进行更改。 | 机密是通过 API 在两个工作区中创建的。 请注意，某些机密内容可能需要在主要区域和次要区域之间进行更改。 |
| 群集配置 | 可以是 Git 中的模板。 共同部署到主要部署和辅助部署，但辅助部署中的部署应在灾难恢复事件之前终止。 | 使用 API 或 CLI 将群集同步到次要工作区后，便可以创建群集。 如果需要，可以根据自动终止设置显式终止这些群集。 |
| 笔记本、作业和文件夹权限 | 可以是 Git 中的模板。 共同部署到主要部署和辅助部署。 | 使用 权限 API 进行复制。 |
选择区域和多个次要工作区
需要完全控制灾难恢复触发器。 可以随时出于任何原因决定触发此操作。 你需要先确保灾难恢复稳定性，然后才能重启操作故障回复（正常生产）模式。 通常，这意味着需要创建多个 Azure Databricks 工作区才能满足生产和灾难恢复需求，并需要选择次要故障转移区域。
在 Azure 中，检查数据复制以及产品和 VM 类型的可用性。
步骤 3：准备工作区并执行一次性复制
如果工作区已在生产环境中，则通常运行一次性复制操作，以便将被动部署与主动部署同步。 这个一次性副本处理以下内容：
- 数据复制：使用云复制解决方案或增量深度克隆操作进行复制。
- 令牌生成：使用令牌生成自动执行复制和将来的工作负载。
- 工作区复制：使用步骤 4：准备数据源中所述的方法使用工作区复制。
- 工作区验证：- 测试以确保工作区和进程可以成功执行并提供预期的结果。
初始一次性复制操作完成后，后续复制和同步操作会更快，并且来自工具的任何日志记录也将是记录更改内容和更改时间的日志。
步骤 4：准备数据源
Azure Databricks 可以使用批处理或数据流来处理大量各种数据源。
数据源中的批处理
批量处理数据时，数据通常位于可轻松复制或传递到另一个区域的数据源中。
例如，数据可能会定期上传到云存储位置。 在次要区域的灾难恢复模式下，必须确保将文件上传到次要区域存储中。 工作负载必须读取并写入次要区域存储。
数据流
处理数据流是一项更大的挑战。 可以从各种源引入流式传输数据，并在处理该数据后将其发送到流式处理解决方案：
- 消息队列，如 Kafka
- 数据库变更数据捕获流
- 基于文件的连续处理
- 基于文件的计划处理，也称为一次性触发
在所有这些情况下，都必须将数据源配置为处理灾难恢复模式和在次要区域中使用辅助部署。
流编写器可存储检查点，以及有关已处理数据的信息。 此检查点可以包含一个数据位置（通常是云存储），必须将其修改为新位置，以确保成功重启流。 例如，检查点下的 source 子文件夹可能会存储基于文件的云文件夹。
必须及时复制此检查点。 考虑将检查点间隔与任何新的云复制解决方案同步。
检查点更新是编写器的一项功能，因此适用于数据流引入或在另一个流式传输源上处理和存储数据流。
对于流式处理工作负载，请确保在客户管理的存储中配置了检查点，以便将其复制到次要区域，使工作负载能够从上次的故障点恢复。 还可以选择与主要过程并行运行次要流式处理过程。
步骤 5：实现和测试解决方案
定期测试灾难恢复设置，以确保其正常运行。 如果在需要时无法使用灾难恢复解决方案，那么维护它就没有任何价值。 一些公司每隔几个月切换一次区域。 定期切换区域可测试你的假设和过程，并确保它们满足恢复需求。 这还可以确保组织熟悉应对紧急事件的策略和过程。
重要
定期在实际条件下测试灾难恢复解决方案。
如果发现缺少对象或模板，且仍需要依靠存储在主要工作区中的信息，请修改计划以消除这些障碍，将此信息复制到辅助系统中，或以其他方式提供此信息。
通常，请测试对过程和配置进行的任何必要组织更改。 灾难恢复计划会影响部署管道，并且团队必须知道需要保持同步的内容。设置灾难恢复工作区之后，必须确保基础结构（手动或代码）、作业、笔记本、库和其他工作区对象在次要区域中可用。
与团队讨论如何扩展标准工作过程和配置管道，以将更改部署到所有工作区。 管理所有工作区中的用户标识。 切记为新工作区配置工具（例如作业自动化和监视）。
规划并测试对配置工具的更改：
- 引入：了解数据源的位置以及这些源获取数据的位置。 如果可能，请对源进行参数化，并确保你有单独的配置模板用于处理辅助部署和次要区域。 准备故障转移计划并测试所有假设。
- 执行更改：如果你有一个用于触发作业或其他操作的计划程序，则可能需要配置一个适用于辅助部署或其数据源的单独计划程序。 准备故障转移计划并测试所有假设。
- 交互式连接：考虑使用 REST API、CLI 工具或其他服务（例如 JDBC/ODBC）时，区域性中断可能会如何影响配置、身份验证和网络连接。 准备故障转移计划并测试所有假设。
- 自动化更改：对于所有自动化工具，准备故障转移计划并测试所有假设。
- 输出：对于生成输出数据或日志的任何工具，请准备故障转移计划并测试所有假设。
测试故障转移
灾难恢复可以由许多不同的场景触发。 它可能由意外中断触发。 一些核心功能可能已关闭，包括云网络、云存储或其他核心服务。 你无权正常关闭系统，必须尝试恢复。 但是，此过程可能是由关机或计划内中断触发的，甚至可能是由于在两个区域之间定期切换主动部署而触发。
测试故障转移时，请连接到系统并运行关闭过程。 确保所有作业均已完成并且群集已终止。
同步客户端（或 CI/CD 工具）可以将相关的 Azure Databricks 对象和资源复制到次要工作区。 要激活次要工作区，相关过程可能包括以下部分或全部内容：
- 运行测试，确认平台是否为最新版本。
- 禁用主要区域中的池和群集，以便在失败的服务恢复联机状态时，主要区域不会开始处理新数据。
- 恢复过程：
- 检查最新同步数据的日期。 请参阅灾难恢复行业术语。 此步骤的详细信息因同步数据的方式和独特的业务需求而异。
- 使数据源稳定，并确保它们均可用。 包括所有外部数据源，例如 Azure 云 SQL、以及 Delta Lake、Parquet 或其他文件。
- 查找流式处理恢复点。 设置从此处重启的过程，并准备好可识别和删除潜在重复项的过程（可使用 Delta Lake 简化此过程）。
- 完成数据流过程并通知用户。
- 启动相关的池（或将
min_idle_instances增加到相关数目）。 - 启动相关群集（如果未终止）。
- 更改作业的并发运行并运行相关作业。 可以一次性运行这些作业，也可以定期运行这些作业。
- 对于任何将 URL 或域名用于 Azure Databricks 工作区的外部工具，请更新配置以说明新的控制平面。 例如，更新 REST API 和 JDBC/ODBC 连接的 URL。 当控制平面更改时，Azure Databricks Web 应用程序的面向客户的 URL 也会更改，请向组织的用户告知新 URL。
测试还原（故障回复）
故障回复更易于控制，并且可以在维护时段中完成。 此计划可以包括以下部分或全部内容：
- 确认主要区域已还原。
- 在次要区域中禁用池和群集，使其不会开始处理新数据。
- 将次要工作区中的所有新资产或已修改资产同步回主要部署。 根据故障转移脚本的设计，可以运行相同的脚本，以将对象从次要（灾难恢复）区域同步到主要（生产）区域。
- 将所有新数据更新同步回主要部署。 可以使用日志和 Delta 表的审核线索来确保不会丢失数据。
- 关闭灾难恢复区域中的所有工作负载。
- 将作业和用户 URL 更改到主要区域。
- 运行测试，确认平台是否为最新版本。
- 启动相关的池（或将
min_idle_instances增加到相关数目）。 - 启动相关群集（如果未终止）。
- 更改作业的并发运行，并运行相关作业。 可以一次性运行这些作业，也可以定期运行这些作业。
- 根据需要，再次设置次要区域，以用于将来的灾难恢复。
自动化脚本、示例和原型
灾难恢复项目要考虑的自动化脚本：
- Databricks 建议借助 Databricks Terraform 提供程序来开发自己的同步过程。
- 另请参阅 Databricks 工作区迁移工具，获取示例和原型脚本。 除了 Azure Databricks 对象之外，还应复制所有相关的 Azure 数据工厂管道，以便引用映射到次要工作区的链接服务。
- Databricks Sync (DBSync) 项目是一个对象同步工具，用于备份、还原和同步 Databricks 工作区。