災害復原

Azure Databricks 的災難復原（DR）會將工作區、資料和設定複製到雲端區域，讓你的團隊在區域故障導致主要部署離線時仍能持續運作。完整的災難復原計畫不僅涵蓋 Azure Databricks，還包括與其相連的資料來源、資料擷取工具、商業智慧工具和排程器。

本頁涵蓋設計與執行跨區域災難復原解決方案所需的概念、策略、工具與測試程序。

剛接觸 DR 規劃嗎？從災難復原產業的術語開始，了解 RPO 與 RTO 的定義。

重要

使用受管理的災難復原。 Azure Databricks 建議在 AWS 和 Azure 上進行跨區域 DR 時使用受控災害復原。它能連續排程複製 Unity Catalog 的元資料、管理式資料表資料和工作區資產，提供穩定的 URL 以應付故障轉移，並允許你從帳號主控台觸發故障轉移。無需撰寫或維護複寫指令碼。僅在下列情況下使用本頁的 DIY 指引：針對受控災難復原（DR）未複寫的資源，或是當你需要主動-主動式拓撲、跨雲複寫，或對複寫管線進行細緻控制時。

區域內高可用性保證

本頁其餘部分涵蓋跨區域災難復原，但 Azure Databricks 也提供單一區域內的高可用性（HA）。首先要了解這些保證。他們會判斷你是否需要獨立的災難復原策略。

HA 和 DR 解決了不同的問題：

HA 在區域內使用可用性區（AZ）冗餘。如果一個區域失效，其他區域的服務仍會繼續運行。
DR 使用區域間複製。你可以在另一個區域中執行次要 Azure Databricks 工作區，並將資料和組態複寫到這些工作區，然後在發生區域性中斷時進行故障轉移。

如果您不需要多區域災難復原，Azure Databricks 的高可用性可能就已足夠。 HA 避免跨區域複雜性，但無法防範整個區域的中斷。如果你只依賴 HA 來做災難恢復，請確認你雲端區域的分離性和冗餘性。

區域內 HA 保證涵蓋控制平面與計算平面。

Azure Databricks 控制平面的可用性

Azure Databricks 控制平面對區域故障具韌性，並在區域故障後約 15 分鐘內自動恢復。定期的區域失效測試能驗證此點。

所有無狀態控制平面服務即使失去單一虛擬機，或整個區域中的所有虛擬機，也不會導致服務中斷。工作區數據會儲存在區域內跨多個區域複製的資料庫中。提供 Databricks Runtime 映像的儲存體帳戶在區域內也具備備援機制，而且所有區域都設有次要儲存體帳戶，當主要儲存體帳戶發生故障時，次要儲存體帳戶會接手運作。

注意

上述控制平面保證適用於 Azure Databricks 管理的基礎設施。您需負責運算平面的可用性區域備援，例如為工作區根儲存貯體選擇可用性區域備援儲存，並使用跨多個可用性區域的執行個體集區。

某些 Azure 區域使用部署於配對區域中的控制平面。請參閱 Azure Databricks 區域。

可用性區域故障韌性最多可容許一個可用性區域發生故障，且僅適用於支援多個可用性區域的 Azure 區域。

計算平面的可用性

工作空間的可用性取決於控制平面的可用性。

如果儲存帳號配置為區域冗餘儲存（ZRS）或地理區域冗餘儲存（GZRS），DBFS 根資料則不受影響。預設為地理冗餘儲存（GRS）。

叢集節點會透過向 Azure 運算提供者請求節點，從不同的可用性區域拉取節點，前提是其他區域的容量足夠。如果節點遺失，叢集管理員會向 Azure 計算供應商要求替代節點 (其會從可用的 AZ 加以提取)。例外是當驅動節點遺失時。在這種情況下，叢集管理器會重新啟動工作並重新啟動叢集。

欲確認多 AZ 支援，請參閱 Azure 區域列表。若需為計算層提供多可用性區域復原能力，請使用區域備援儲存。

詞彙

與團隊討論 DR（災難復原）時，請一致使用這些定義。

區域術語

本頁使用以下區域定義：

主要區域：使用者每日執行互動式及自動化資料分析工作負載的區域。
次級區域：IT 團隊在主要區域停機期間暫時移動工作負載的區域。
地理冗餘儲存：持久儲存的非同步跨區域複製。請參閱您的雲端文件：

跨區域的地理冗餘儲存（Azure）。

重要

不要依賴地理冗餘儲存來重複 Azure Databricks 根儲存（例如 Azure Databricks 為每個工作區建立的 ADLS（針對 2023 年 3 月 6 日前建立的工作區，稱為 Azure Blob 儲存體））。若要複製受管理的資料表資料，請使用 Delta 深度複製;對於非 Delta 資料，盡可能先轉換為 Delta。

部署狀態術語

本頁面使用以下部署狀態定義：

主動部署 （有時稱為 熱部署）：使用者連接並執行工作負載。工作和資料流在這裡按時運行。
被動部署 （有時稱為 冷部署）：此處不執行任何程序。 IT 團隊透過自動化部署程式碼、設定及其他 Azure Databricks 物件來保持系統隨時可用。被動部署只有在主動部署中斷時才會變成主動部署。

重要

一個專案可以在不同區域包含多個被動部署，以提升韌性。

大多數團隊一次只執行一個主動部署，採用主動-被動策略。較少見的主動-主動策略則是同時進行兩次主動部署。

災難復原產業術語

災害復原產業術語

請與你的團隊定義這兩個產業術語：

復原點目標（RPO）：在重大事件中，您的服務可容忍的最大資料遺失時間。參見 RPO。

Azure Databricks 不會儲存你的主要客戶資料。它存在於 ADLS（針對 2023 年 3 月 6 日之前建立的工作空間，Azure Blob 儲存體）或其他你控制的系統中。 Azure Databricks 控制平面會儲存一些物件（例如工作和筆記本），因此 Azure Databricks 的 RPO 是這些物件變更可能遺失的最大期限。你負責在 ADLS（針對 2023 年 3 月 6 日之前建立的工作空間，Azure Blob 儲存體）以及你控制的其他資料來源中，定義客戶資料的 RPO。
復原時間目標（RTO）：災難發生後，業務流程必須在最長時間內恢復。請參見 RTO。

災難復原與資料損毀

災害復原和資料損毀

DR 解決方案無法緩解資料損毀。主區域中損壞的資料會複製到次要區域，且兩者皆受損。為了減少這類故障，可以使用 Delta 時間旅行、類似工具或資料備份工具。

一般復原工作流程

Azure Databricks 的災難復原情境通常會如下進行：

故障會影響你主要區域中的關鍵服務：資料來源、網路，或 Azure Databricks 部署所依賴的其他相依性。
你可以向你的雲端服務提供商調查。
如果等待無法接受，你決定切換到次要區域。
確認同樣的問題不會影響你的次要區域。
故障轉移（如需詳細步驟，請參閱測試故障轉移）：
1. 停止所有工作空間的活動。使用者會停止工作負載並在可能的情況下備份最近的變更。工作會停擺（如果停電還沒讓他們失職的話）。
2. 執行次要區域復原程序以更新路由並重新導向連線與網路流量。
3. 將下游系統（BI 工具、排程器、第三方整合）重新定位到次要工作區，並恢復連線。
4. 在測試之後，請宣告次要地區正式運作。使用者登入目前已啟用的部署作業，而您會重新觸發已排程或延後的作業。
在主要區域問題緩解後，確認修復方法。
故障切回（詳情請參見測試還原（故障切回））：
1. 停止次要區域中的所有工作。
2. 執行主要區域恢復程序，將路由重新導向回去。
3. 將任何新資料複製回主要區域。盡量減少需要複製的部分。例如，在次要部署中執行的唯讀作業可能不需要回寫。
4. 測試主要區域部署。
5. 宣告主要區域活躍並恢復生產工作負載。

重要

這些步驟中可能會發生部分資料遺失。定義貴組織可接受的損失程度，以及你如何減緩。

步驟 1：瞭解您的業務需求

辨識哪些資料服務至關重要，並定義其目標 RPO 與 RTO。研究每個系統的實際容忍度。

災難復原、故障轉移與故障回復都會帶來實際的成本與風險，包括資料損毀、資料重複寫入（寫入錯誤的儲存位置），以及使用者在錯誤的區域進行變更。

繪製每個影響您業務的 Azure Databricks 整合點，並選擇您的計畫所使用的工具與溝通管道。

要映射的整合點

你的災難復原解決方案需要支援互動式流程、自動化流程，還是兩者兼具？
您使用哪些資料服務？有些可能是本地部署的。
如何將輸入資料傳送至雲端？
誰會取用此資料？哪些流程會在下游取用資料？
是否有任何第三方整合需要知悉 DR 相關變更？

規劃工具與溝通

你能否預先定義你的配置，並讓它模組化，以自然且易於維護的方式容納災難復原解決方案？
哪些通訊工具和通道會將災難復原（DR）容錯移轉與切回的相關變更通知內部團隊及第三方（整合對象、下游使用者）？你要怎麼確認他們的認可？
在完全復原完成之前，您會關閉哪些服務（如果有的話）？

步驟 2：選擇符合業務需求的流程

預設是管理式災難復原。 它能處理工作區複製、Unity Catalog 元資料、管理資料表資料及故障轉移編排，無需自訂腳本。只有在您的需求超出其涵蓋範圍時，才應使用以下 DIY 指南；例如，受管理 DR 未複寫的資源、主動-主動式拓撲、跨雲複寫，或需要對複寫管線進行更細緻的控制。

DIY解決方案必須在控制平面、計算平面及資料來源間複製正確的資料。冗餘工作區會映射到不同區域的不同控制平面，因此你可以讓它們與腳本解決方案同步，無論是同步工具或 CI/CD 工作流程。至於資料本身，大多數團隊會使用 Azure Databricks 工作（通常會排程執行）或 Delta Deep Clone，在不同區域之間複製資料表。你不需要同步計算平面內的資料（例如來自 Databricks 執行時工作者的資料）。

如果你使用 VNet 注入功能（並非所有訂閱和部署類型都有），就要用像 Terraform 這類範本工具，穩定地在兩個區域部署網路。

根據需要，跨區域複製你的資料來源。

災難復原解決方案通常包含兩個（或更多個）工作空間。請根據你必須容忍的中斷長度、營運投入及回傳至主要區域的成本，在以下策略中選擇。

一般最佳實務

一般最佳做法

成功的災難復原（DR）計畫的一般最佳做法包括：

了解哪些流程對業務營運至關重要，且必須在災難復原期間持續運作。
清楚識別涉及哪些服務、正在處理哪些數據、數據流是什麼，以及儲存的位置。
請盡可能隔離服務和資料。例如，建立一個專門的雲端儲存容器來存放災難資料，或將災難發生時需要的 Azure Databricks 物件移到獨立的工作空間。
你負責維護未儲存在 Azure Databricks 控制平面的物件的主要與次要部署之間的完整性。
對於資料來源，在可行情況下，請使用 Azure 原生工具將資料複寫到您的 DR 區域。

警告

不要將資料儲存在用於 DBFS 根目錄存取的 ADLS 根目錄中（若是 2023 年 3 月 6 日之前建立的工作區，則為 Azure Blob 儲存體）。 DBFS 根儲存不適用於生產客戶數據。 Azure Databricks 也建議不要在那裡存放函式庫、設定檔或初始化腳本。

主動-被動解決方案策略

本節聚焦於主動-被動策略，因為它最常見、最簡單且最具成本效益。主動被動解決方案會將主動部署的資料和物件變更同步到次要區域的被動部署。在災難復原期間，被動部署會轉為主動部署。

有兩種常見變體：

統一（企業範圍）：一組主動與被動部署支援整個組織。
依部門或專案：每個領域維護自己的災難復原解決方案，並依需求設有主要與次要區域。

你也可以用被動部署來處理唯讀工作負載，例如使用者查詢，這些工作不會修改資料或 Azure Databricks 物件。

主動-主動解決方案策略

在主動-主動解決方案中，所有資料程序在兩個區域同時並行執行。您的營運團隊必須僅在每項作業於兩個區域都成功之後，才將其標示為完成。物件在生產環境中不得變更，且必須嚴格遵循從開發／測試環境到生產環境的 CI/CD 升級流程。

主動-主動式策略是最複雜的，且成本較高，因為作業會同時在兩個區域執行，但可提供最低的 RTO 和 RPO。

你可以在全企業範圍內或按部門實施主動-主動架構。你不需要為每個工作負載建立重複的工作區。例如，開發或暫存工作區通常從開發管線重建會比讓其保持同步更容易。

選擇你的工具

選擇您的工具

在你的主要與次要區域中的工作區之間保持資料同步，主要有兩種方法：

從主要區域複製到次要地區的同步處理用戶端：同步處理用戶端會將實際作業資料和資產從主要區域推送至次要地區。通常，這會依排程定期執行，而排程頻率則取決於你的目標 RTO 和 RPO。
平行部署的 CI/CD 工具：針對實際作業程式碼和資產，請使用 CI/CD 工具將實際作業系統變更同時推送至這兩個區域。例如，將程式碼和資產從預備/開發環境推送至實際作業環境時，CI/CD 系統可讓您同時在這兩個區域中使用該程式碼和資產。核心概念是將 Azure Databricks 工作區中的所有成品視為基礎結構即程式碼。大多數產出物可同時部署至主工作區與次要工作區，而部分產出物則可能僅需在災難復原事件後部署。如需工具，請參閱自動化指令碼、範例和原型。

根據你的需求，你可以結合兩種方法。例如，針對筆記本原始程式碼使用 CI/CD，但針對集區和訪問控制等設定使用同步處理。

下表說明如何處理每種工具選項中的資料。

描述	如何使用 CI/CD 工具進行處理	如何使用同步處理工具進行處理
原始程式碼：已封裝程式庫的筆記本來源匯出和原始程式碼	將兩者共同部署至主要和次要地區。	將程式碼從主要同步至次要。
使用者和群組	在 Git 中將中繼資料作為組態進行管理。或者，針對這兩個工作區使用相同的識別提供者 (IdP)。將使用者和群組資料共同部署至主要和次要部署。	請針對這兩個區域使用 SCIM 或其他自動化功能。不建議手動建立，但如果使用手動建立，必須同時進行。如果您使用手動設定，請建立排程的自動化程式，以比較兩個部署之間的使用者和群組清單。
集區設定	可以是 Git 中的範本。共同部署至主要和次要地區。不過，`min_idle_instances` 在次要端中必須為零，直到 DR 事件發生為止。	使用任何 `min_idle_instances` 建立的集區在使用 API 或 CLI 同步到次要工作區時。
作業設定	使用 Databricks 資產套件，搭配每個環境的目標（例如 `prod` 和 `dr`），將相同的工作定義部署到兩個區域。對於次要部署，將並行數設為零，使作業處於暫存狀態而不會執行。等次要部署變成作用中後，再變更並行值。	如果作業因某些原因在現有 `<interactive>` 叢集上執行，則同步客戶端必須對應到次要工作區中的對應 `cluster_id`。
存取控制清單 (ACL)	可以是 Git 中的範本。協同部署至筆記本、資料夾和叢集的主要和次要部署。不過，請將作業資料保留至發生 DR 事件為止。	權限 API 可以設定叢集、作業、集區、筆記本和資料夾的存取控制。同步用戶端需要對應次要工作區中每個物件的對應物件識別碼。 Databricks 建議您在複製存取控制之前，先建立物件識別碼從主要工作區到次要工作區的對照表。
程式庫	包含在原始程式碼和叢集/作業範本中。	從集中式存放庫、DBFS 或雲端儲存體 (可以裝載) 同步處理自訂程式庫。
叢集 init 指令碼	如果您想要的話，請包含在原始程式碼中。	若要簡化同步處理，請盡可能將 init 指令碼儲存在一般資料夾或一組小型資料夾中的主要工作區中。
掛接點	請僅在透過筆記本型作業或命令 API 建立後，才將其包含在原始程式碼中。	使用可作為 Azure Data Factory (ADF) 活動執行的作業。請注意，如果工作區位於不同的區域，儲存體端點可能會有所變更。這也在很大程度上取決於您的資料災難復原策略。
資料表中繼資料	對於 Unity 目錄物件（目錄、結構、資料表、卷及授權），請與 Databricks Terraform 提供者或 Databricks 資產套件共同部署。對於舊有的 Hive 中繼儲存資料表，若透過筆記本工作或 Command API 建立，請包含帶有原始碼的 create-table 語句。	對於 Unity 目錄物件，可以從系統資料表讀取原始元資料，或 `information_schema` 使用 Databricks SDK 複製到次要工作區。對於舊有的 Hive 元儲存庫資料表，請使用 Spark Catalog API 或 `SHOW CREATE TABLE` 筆記本或腳本比較不同元儲存庫之間的元資料定義。底層儲存路徑可以是區域性的，且不同元儲存實例可能有所不同。
秘密	僅在透過命令 API建立的情況下才包含在原始程式碼中。請注意，某些秘密內容可能需要在主要和次要之間進行更改。	祕密透過 API 在這兩個工作區中生成。請注意，某些秘密內容可能需要在主要和次要之間進行更改。
叢集組態	可以是 Git 中的範本。同時部署至主要與次要部署環境，但次要部署環境中的執行個體在 DR 事件發生前應先維持終止狀態。	叢集會在使用 API 或 CLI 同步至次要工作區之後建立。視自動終止設定而定，您可以視需要明確終止這些項目。
筆記本、作業和資料夾權限	可以是 Git 中的範本。協同部署至主要與次要部署環境。	使用權限 API 複寫。

選擇區域和多個次要工作區

你可以控制 DR 何時觸發，以及你要切換到哪個次要區域。你也負責在恢復正常作業前，讓災難復原（DR）環境恢復穩定。這通常意味著建立多個 Azure Databricks 工作區用於生產環境和災難復原，然後選擇次要故障轉移區域。

在選擇次要區域前，請確認你依賴的所有資源和服務（計算類型、產品、整合）都在那裡可用。部分 Azure Databricks 服務僅在特定區域提供。

也要檢查資料複製和虛擬機類型可用性。

步驟 3：準備工作空間並進行一次性複製

首先，在你選擇的次要區域建立一個次要的 Azure Databricks 工作空間（或多個工作空間）及其支援的元儲存庫。次要工作區必須鏡像主帳號的帳號、區域和身份設定，才能複製資料或資產到它。

如果你使用受管理的災難復原，Azure Databricks 會在建立故障轉移群組時，負責初始的範圍內目錄和工作空間資產的啟動。你不需要對這些資源執行一次性複製。請繼續閱讀本節其餘內容，了解任何受管 DR 未複寫的資料來源或資產。

對於執行在受管 DR 範圍之外的生產工作區，執行 一次性複製 ，將被動部署與主動部署同步。此副本會處理：

資料複製：使用雲端複製解決方案或三角洲深度複製。
代幣生成：透過產生代幣自動化複製與未來工作負載。
工作區複製：使用步驟 4 中的方法複製：準備你的資料來源。如需有關匯出工作區設定、資料及 AI/ML 資產的完整指引，請參閱匯出工作區資料。
工作區驗證：測試工作區與流程，確保它們能成功執行並產生預期結果。

後續的同步速度比最初的版本還快，你的工具日誌會記錄哪些內容以及何時改變。

步驟 4：準備資料來源

Azure Databricks 可以使用批次處理或資料流來處理各種不同的資料來源。

從資料來源進行批次處理

批次資料通常存放在一個你可以複製或傳送到其他區域的來源中。

例如，資料通常會按時上傳到雲端儲存。在災害復原 (DR) 模式下，請將這些上傳作業導向次要區域的儲存體，並更新工作負載設定，使其從該儲存體讀取資料並寫入其中。

資料流

處理資料流是一項更艱難的挑戰。串流數據可以從各種來源擷取、處理及傳送至串流解決方案：

Kafka 等的訊息佇列
資料庫異動資料擷取串流
以檔案為基礎的連續處理
檔案型排程處理，也稱為單次觸發

在上述所有情況中，你都必須將資料來源設定為支援災害復原 (DR) 模式，並使用位於次要區域中的次要部署。

串流寫入器會儲存檢查點，其中包含已處理之資料的相關資訊。此檢查點可以包含必須修改為新位置的資料位置 (通常是雲端儲存體)，以確保成功重新啟動串流。例如，檢查點下的 source 子資料夾可能會儲存以檔案為基礎的雲端資料夾。

此檢查點必須及時複製。請考慮將檢查點間隔與任何新的雲端複寫解決方案進行同步。

檢查點更新是寫入器的一項功能，因此適用於資料流擷取或處理，並儲存在另一個串流來源上。

針對串流工作負載，請確定在由客戶管理的儲存體中設定的檢查點能夠複製到次要區域，以便從最近的失敗點恢復工作負載。您也可以選擇將次要串流作業與主要作業同時運行。

步驟 5：實作及測試您的解決方案

如果您使用受管災難復原，您可以從帳戶主控台發起計畫性故障轉移，以驗證您的設定是否能完整正常運作。同樣的程序也適用於 DR 測試和真正的停電。請參見「失敗切換」與「失敗回撤」。

定期測試你的災難復原設定。未經測試的災難復原計畫在你需要時往往派不上用場。有些團隊會按時每隔幾個月更換活躍區域，以驗證假設、練習流程，並讓團隊熟悉跑手冊。

重要

定期在實際環境條件下測試你的災難復原解決方案。

如果測試發現缺少物件或範本，請更新你的計畫：移除相依、複製到次要工作區，或以其他方式提供。

也要測試組織和設定的變更。你的災難復原計畫會影響你的部署流程，因此團隊必須知道哪些內容要保持同步。在你設定好災難復原工作區後，確認你的基礎設施、工作、筆記本、函式庫和其他工作區物件是否在次要區域中可用。

擴展您的標準工作流程與設定流程，將變更部署到所有工作空間。管理跨工作區的使用者身份，並為新工作區設定工作自動化與監控。

規劃並測試你的設定工具變更。

規劃與測試的配置變更

針對以下每一項，請準備故障轉移計畫並測試所有假設：

資料擷取：了解你的資料來源在哪裡，以及這些資料來源從哪裡取得資料。若可能，先參數化來源，並使用獨立的配置範本來處理次要部署與區域。
執行變更：如果你有排程器來觸發工作或其他動作，可能需要一個獨立的排程器來支援次要部署或其資料來源。
互動式連線：請考量在使用 REST API、CLI 工具或其他服務（例如 JDBC/ODBC）時，區域性中斷可能會如何影響設定、驗證及網路連線。
自動化變更：適用於所有自動化工具。
輸出：適用於任何會產生輸出資料或記錄的工具。
下游變更：對於會從 Azure Databricks 讀取資料或寫入資料的 BI 工具、儀表板、排程器和第三方整合，請規劃如何將它們改為指向次要工作區，並通知其擁有者。

測試失敗轉換

測試容錯移轉

許多情境都可能觸發災害復原：例如雲端網路、雲端儲存或其他核心服務發生非預期中斷，導致您無法正常關閉；計畫性的關閉或中斷；甚至作為測試週期的一部分，定期在區域之間切換。

若要測試故障轉移，請連線到系統並執行關機。確認所有作業都已完成，且叢集已終止。

同步客戶端（或 CI/CD 工具）會將相關的 Azure Databricks 物件和資源複製到次要工作空間。要啟用次要工作區，你的流程可能包含以下部分或全部：

執行測試以確認平台處於最新狀態。
停用主要區域的集區和叢集，如此一來，如果失敗的服務恢復運作，主要區域就不會開始處理新的資料。
執行資料來源的復原程序（見下文）。
啟動相關的集區（或將 min_idle_instances 增加到相關數字）。
啟動相關的叢集 (如果未終止)。
變更作業的並行執行，並執行相關的作業。這些可能是一次性運行或定期運行。
對於任何使用 Azure Databricks 工作區 URL 或網域名稱的外部工具，請更新組態以將新的控制平面納入其中。例如，更新 REST API 和 JDBC/ODBC 連線的 URL。當控制平面變更時，Azure Databricks Web 應用程式的客戶對應 URL 會變更，因此請通知貴組織的使用者新的 URL。

復原流程細節

檢查最新同步資料的日期。請參閱災難復原產業術語。此步驟的詳細數據會因同步處理數據的方式和獨特的商務需求而有所不同。
穩定您的資料來源，並確保來源全部可供使用。包含所有外部數據源，例如 Azure Cloud SQL，以及您的 Delta Lake、Parquet 或其他檔案。
尋找您的串流復原點。設定程式從該處重新啟動，並備妥程式以識別並消除潛在的重複專案（Delta Lake 可簡化此作業）。
完成資料流程程序並通知使用者。

測試還原（故障回復）

故障回復更容易控制，而且可以在維護時段內完成。請規劃以下部分或全部步驟：

確認主要區域已還原。
停用次要區域中的資源集區和叢集，使其不會開始處理新資料。
將次要工作區中任何新的或修改的資產同步處理回主要部署。根據你故障切換腳本的設計，你可能能執行相同的腳本，將物件從次要（DR）區域同步到主要（生產）區域。
將任何新的資料更新同步回主要部署。您可以使用記錄和 Delta 資料表的稽核線索，以保證不會出現資料遺失的情形。
關停災難復原區域中的所有工作負載。
把工作和使用者的網址改成主要區域，並將下游連線（BI 工具、排程器、第三方整合）重新定位回去。
執行測試以確認平台處於最新狀態。
啟動相關的集區（或將 min_idle_instances 增加到相關數字）。
啟動相關的叢集 (如果未終止)。
變更作業的並行運行，並運行相關的作業。這些可能是一次性運行或定期運行。
如有需要，請再次設定次要區域，供未來災難復原之用。

自動化指令碼、範例和原型

對於 AWS 和 Azure，受管理的災難復原能處理工作區與管理資料表複製，無需自訂自動化。以下參考資料僅適用於在受管災難復原涵蓋範圍之外自行建置解決方案的情況。

對於 DIY 災難復原（DR）管線，請使用 Databricks Terraform 提供者，以程式碼形式管理工作區資產，並同時部署到主要和次要區域。

如果你從 Azure Data Factory 編排 Azure Databricks，複製相關的 ADF 管線，讓它們指向映射到次要工作區的連結服務。

其他資源

意見反應

此頁面對您有幫助嗎？

上次更新時間： 2026-09-11