災害復原

發行項
10/14/2024

明確的災害復原模式對於 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 部署的資料來源服務或網路。
您調查雲端提供者的情況。
如果您判斷您的公司無法等到主要區域中的問題獲得補救，就可能會決定需要容錯移轉至次要地區。
確認相同的問題不會影響您的次要地區。
容錯移轉至次要地區。
1. 停止工作區中的所有活動。使用者停止工作負載。如果可能的話，系統會指示使用者或系統管理員備份最近的變更。如果作業尚未因中斷而失敗，系統則會關閉作業。
2. 在次要地區中啟動復原程序。復原程序會將連線和網路流量重新命名，並更新至次要地區。
3. 在測試之後，請宣告次要地區正式運作。您現在可以繼續進行實際作業工作負載。使用者可以登入目前作用中的部署。您可以重新觸發已排程或延遲的工作。
如需 Azure Databricks 情境中的詳細步驟，請參閱測試容錯移轉。
到了某個階段，主要區域中的問題會降低，而且您可確認此事實。
將 (容錯回復) 還原到您的主要區域。
1. 停止次要地區的所有工作。
2. 在主要區域中啟動復原程序。復原程序會處理將連線和網路流量路由回主要區域和重新命名作業。
3. 視需要將資料複寫回主要區域。若要降低複雜度，您或許可將需要複寫的資料量降到最低。例如，如果部份作業在次要部署中執行時處於唯讀狀態，您可能不需要將資料複寫回主要區域中的主要部署。不過，您可能有一個實際生產作業需要執行，而且可能需要將資料複寫回到主要區域。
4. 測試主要區域中的部署。
5. 宣告您的主要區域可正常運作，且其為作用中的部署。繼續實際作業工作負載。
如需還原至主要區域的詳細資訊，請參閱測試還原 (容錯回復)。

重要

在這些步驟期間，可能會發生某些資料遺失的情況。您的組織必須定義可接受的資料遺失量，以及您可以採取哪些動作來減輕這項損失。

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

您的第一個步驟是定義及瞭解您的業務需求。定義哪些資料服務為關鍵項目，以及其預期的 RPO 和 RTO。

研究每個系統的實際容錯能力，並請記住，災害復原容錯移轉和容錯回復的成本可能很高，並具有其他風險。其他風險可能包括資料損毀、寫入錯誤儲存位置時出現重複的資料，以及使用者登入錯誤位置並在該位置進行變更。

對應可影響企業的所有 Azure Databricks 整合點：

您的災害復原解決方案是否需要包含互動式流程、自動化流程，或兩者兼具？
您使用哪些資料服務？部分可能是內部部署服務。
如何將輸入資料傳送至雲端？
誰會取用此資料？哪些流程會在下游取用資料？
是否有需要留意災害復原變更的第三方整合？

判斷可支援災害復原方案的工具或通訊策略：

您將使用哪些工具來快速修改網路設定？
您可以預先定義設定並將其模組化，以自然且可維護的方式容納災害復原解決方案嗎？
哪些通訊工具和通道會向內部小組和第三方 (整合、下游取用者) 通知災害復原容錯移轉和容錯回復變更？你將如何確認他們的認可？
需要哪些工具或特殊支援？
直到完成復原為止，哪些服務將被迫關閉 (若有)？

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

您的解決方案必須複寫控制平面、計算平面和資料來源中的正確資料。災害復原的備援工作區必須對應至不同區域中的不同控制平面。您必須使用指令碼型解決方案 (同步處理工具或 CI/CD 工作流程)，定期讓該資料保持同步。您不需要從計算平面網路內部同步處理資料，例如透過 Databricks Runtime 背景工作角色。

如果您使用 VNet 插入功能 (並非所有訂用帳戶和部署類型皆適用)，您可以使用範本型工具 (如 Terraform)，在兩個區域中一致地部署這些網路。

此外，您必須確保資料來源會視需要跨區域複寫。

災害復原 - 需要複寫哪些項目？

一般最佳做法

成功災害復原方案的一般最佳做法包括：

瞭解哪些流程對企業至關重要，而且必須在災害復原期間執行。
清楚識別範圍擴及哪些服務、正在處理哪些資料、資料流程為何，以及其儲存的位置
請盡可能隔離服務和資料。例如，為災害復原的資料建立特殊的雲端儲存體容器，或將災害期間所需的 Azure Databricks 物件移至個別工作區。
您有責任針對未儲存在 Databricks 控制平面中的其他物件，維護主要和次要部署之間的完整性。

警告

最佳做法是不要將資料儲存在用於工作區 DBFS 根存取的根 ADLS gen2 (適用於 2023 年 3 月 6 日之前在 Azure Blob 儲存體建立的工作區)。實際作業客戶資料不支援該 DBFS 根儲存體。 Databricks 也建議您不要在此位置儲存程式庫、設定檔或 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 可以設定叢集、作業、集區、筆記本和資料夾的存取控制。同步處理用戶端必須對應至次要工作區中每個物件的對應物件識別碼。 Databricks 建議您在複寫存取控制之前，先建立從主要工作區到次要工作區的物件識別碼對應。
程式庫	包含在原始程式碼和叢集/作業範本中。	從集中式存放庫、DBFS 或雲端儲存體 (可以裝載) 同步處理自訂程式庫。
叢集 init 指令碼	您可以依偏好包含在原始程式碼中。	若要簡化同步處理，請盡可能將 init 指令碼儲存在一般資料夾或一組小型資料夾中的主要工作區中。
掛接點	請僅在透過筆記本型作業或命令 API 建立時，才包含在原始程式碼中。	使用可作為 Azure Data Factory (ADF) 活動執行的作業。請注意，如果工作區位於不同的區域，儲存體端點可能會有所變更。這也取決於您的資料災害復原策略。
資料表中繼資料	請僅在透過筆記本型作業或命令 API 建立時，才包含在原始程式碼中。這適用於內部 Azure Databricks 中繼存放區或外部設定的中繼存放區。	使用 Spark 目錄 API比較中繼存放區之間的中繼資料定義，或透過筆記本或指令碼顯示建立資料表。請注意，基礎儲存體的資料表可以是區域型資料表，而且在中繼存放區執行個體之間會有所差異。
密碼	請僅在透過命令 API 建立時，才包含在原始程式碼中。請注意，您可能需要在主要和次要工作區之間切換，才能使用部分祕密內容。	您需要透過 API 才能在這兩個工作區中建立祕密。請注意，您可能需要在主要和次要工作區之間切換，才能使用部分祕密內容。
叢集組態	可以是 Git 中的範本。共同部署至主要和次要部署，不過在發生災害復原事件之前，都應該終止次要部署中的部署。	叢集會在使用 API 或 CLI 同步至次要工作區之後建立。視自動終止設定而定，您可以視需要明確終止這些項目。
筆記本、作業和資料夾權限	可以是 Git 中的範本。共同部署至主要和次要部署。	使用權限 API 複寫。

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

您需要完全控制災害復原觸發程式。您可能會決定隨時或基於任何原因觸發此程式。您必須承擔穩定災害復原的責任，才能重新啟動作業容錯回復 (一般實際作業) 模式。這通常表示您必須建立多個 Azure Databricks 工作區，以符合您的實際作業與災害復原需求，並且選擇您的次要容錯移轉區域。

在 Azure 中，檢查您的資料複寫以及產品和 VM 類型可用性。

步驟 3：準備工作區並執行一次性複製

如果工作區已處於實際作業狀態，使用者通常會執行一次性的複製作業，以同步處理被動部署與主動部署。這項一次性複製作業會處理下列項目：

資料複寫：使用雲端複寫解決方案或 Delta 深層複製作業進行複寫。
權杖產生：使用權杖產生作業來自動化複寫作業和未來的工作負載。
工作區複寫：透過步驟 4：準備資料來源中所述的方法，使用工作區複寫。
工作區驗證： - 進行測試，以確定工作區和流程可以順利執行，並提供預期的結果。

完成初始的一次性複製作業之後，將可提升後續的複製和同步速度，而且工具的任何記錄也能夠記錄變更的項目和變更時間。

步驟 4：準備資料來源

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

從資料來源進行批次處理

在批次處理資料時，資料通常位於可以輕鬆地複寫或傳遞到另一個區域的資料來源中。

例如，資料可能會定期上傳至雲端儲存位置。在次要地區的災害復原模式中，您必須確定檔案會上傳至次要地區儲存體。工作負載必須讀取次要地區儲存體，並寫入次要地區儲存體。

資料流

處理資料流是一項更艱難的挑戰。您可以從各種來源擷取串流資料，並在處理後傳送至串流解決方案：

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

在所有這類案例中，您都必須設定資料來源來處理災害復原模式，並在次要地區中使用您的次要部署。

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

此檢查點必須及時經過複寫。請考慮使用任何新的雲端複寫解決方案同步處理檢查點間隔。

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

針對串流工作負載，請確定在客戶自控儲存體中設定檢查點來複寫到次要地區，以便從最近的失敗點恢復工作負載。您也可以選擇平行執行將次要流程串流至主要流程的作業。

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

定期測試災害復原設定，以確保其正常運作。如果您無法在需要時使用災害復原解決方案，那麼維護災害復原解決方案就毫無意義。部分公司會每隔幾個月就切換至不同區域。定期切換區域會測試您的假設和流程，並確保其符合您的復原需求。這也可確保貴組織熟悉在緊急情況下生效的原則和程序。

重要

定期使用真實世界的條件來測試災害復原解決方案。

如果您發現遺漏物件或範本，且仍需要依賴儲存在主要工作區中的資訊，請修改您的計劃以移除這些障礙，並在次要系統中複寫此資訊，或以其他方式提供此資訊。

測試流程及一般組態中的任何必要組織性變更。您的災害復原計劃會影響您的部署管線，而且您的小組必須知道需要保持同步的項目。設定災害復原工作區之後，必須確定您可在次要地區中使用基礎結構 (手動或程式碼)、作業、筆記本、程式庫和其他工作區物件。

與您的小組討論如何擴充標準工作流程和組態管線，以將變更部署至所有工作區。管理所有工作區中的使用者識別。請記得為新的工作區設定作業自動化和監視等工具。

規劃與測試組態工具的變更：

擷取：了解資料來源的位置，以及這些來源取得其資料的位置。可能的話，請將來源參數化，並確定您有其他的組態範本來使用次要部署和次要地區。準備容錯移轉計劃並測試所有假設。
執行變更：如果您有觸發作業或其他動作的排程器，您可能需要設定與次要部署或其資料來源搭配運作的個別排程器。準備容錯移轉計劃並測試所有假設。
互動式連線：請考量在使用 REST API、CLI 工具或其他服務 (例如 JDBC/ODBC) 時出現區域中斷的話，組態、驗證和網路連線會受到何種影響。準備容錯移轉計劃並測試所有假設。
自動化變更：針對所有自動化工具，準備容錯移轉計劃並測試所有假設。
輸出：針對任何產生輸出資料或記錄的工具，請準備容錯移轉計劃並測試所有假設。

測試容錯移轉

災害復原可由許多不同的案例觸發。該情況可以由非預期的中斷觸發。部分核心功能可能會故障，包括雲端網路、雲端儲存體或其他核心服務。您無法正常關閉系統，而且必須嘗試進行復原。不過，此流程可能會因關機或計劃性中斷而觸發，或甚至是因兩個區域之間定期切換作用中部署而觸發。

當您測試容錯移轉時，請連線到系統並執行關機流程。請確定所有作業都已完成，且叢集已終止。

同步處理用戶端 (或 CI/CD 工具) 可以將相關的 Azure Databricks 物件和資源複寫至次要工作區。若要啟用次要工作區，您的流程可能包含部分或全部的下列項目：

執行測試以確認平台處於最新狀態。
停用主要區域的集區和叢集，如此一來，如果失敗的服務恢復運作，主要區域就不會開始處理新的資料。
恢復流程：
1. 檢查最新同步資料的日期。請參閱災害復原產業術語。此步驟的詳細資料會根據同步處理資料的方式和各自的商務需求而有所不同。
2. 穩定您的資料來源，並確保來源全部可供使用。包含所有外部資料來源，例如 Azure Cloud SQL，以及您的 Delta Lake、Parquet 或其他檔案。
3. 尋找您的串流復原點。設定流程以從該處重新啟動，並備妥流程以識別並消除潛在的重複項目 (Delta Lake Lake 可簡化此作業)。
4. 完成資料流程程序並通知使用者。
啟動相關集區 (或將 min_idle_instances 增加為相關數字)。
啟動相關的叢集 (如果未終止)。
變更作業的並行執行，並執行相關的作業。您可能需要一次性執行或定期執行這些項目。
對於任何使用 Azure Databricks 工作區 URL 或網域名稱的外部工具，請更新組態以將新的控制平面納入其中。例如，更新 REST API 和 JDBC/ODBC 連線的 URL。當控制平面變更時，Azure Databricks Web 應用程式的客戶對應 URL 也會相應變更，因此請向組織的使用者通知新 URL 的資訊。

測試還原 (容錯回復)

容錯回復更容易控制，而且可以在維護期間完成。此方案可以包含部分或全部的下列項目：

確認主要區域已還原。
停用次要地區的集區和叢集，避免集區和叢集開始處理新的資料。
將次要工作區中任何新的或修改的資產同步處理回主要部署。根據容錯移轉指令碼的設計方式，您也許能夠執行相同的指令碼，將物件從次要 (災害復原) 區域同步至主要 (實際作業) 區域。
將任何新的資料更新同步回主要部署。您可以使用記錄和 Delta 資料表的稽核線索，以保證不會出現資料遺失的情形。
關閉災害復原區域中的所有工作負載。
將作業和使用者 URL 變更為主要區域。
執行測試以確認平台處於最新狀態。
啟動相關集區 (或將 min_idle_instances 增加為相關數字)。
啟動相關的叢集 (如果未終止)。
變更作業的並行執行，並執行相關的作業。您可能需要一次性執行或定期執行這些項目。
視需要再次設定次要地區，以用於未來的災害復原。

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

針對災害復原專案的自動化指令碼考量：

Databricks 建議您使用 Databricks Terraform 提供者來協助開發您自己的同步處理流程。
如需範例和原型指令碼，請同時參閱 Databricks 工作區移轉工具。除了 Azure Databricks 物件以外，請複寫任何相關的 Azure Data Factory 管線，使其參考對應至次要工作區的連結服務。
Databricks Sync (DBSync) 專案是物件同步處理工具，可備份、還原及同步 Databricks 工作區。

共用方式為