共用方式為

使用 RecoveryManager 類別來修正分區對應問題

  • 發行項

適用於：Azure SQL 資料庫

RecoveryManager 類別可讓 ADO.NET 應用程式能夠在分區資料庫環境中輕鬆地偵測和校正全域分區對應 (GSM) 與本機分區對應 (LSM) 之間的任何不一致。

GSM 和 LSM 會追蹤分區環境中每個資料庫的對應。 有時候，GSM 與 LSM 之間會發生中斷。 在此情況下，請使用 RecoveryManager 類別來偵測和修復中斷。

RecoveryManager 類別是彈性資料庫用戶端程式庫的一部分。

分區對應

關於術語定義，請參閱 彈性資料庫工具詞彙表。 欲了解如何使用 ShardMapManager 來管理在分區解決方案中的資料，請參閱 [分區對應管理]。

為什麼要使用復原管理員

在分區資料庫環境，每個資料庫都有一個租用戶，每個伺服器有多個資料庫。 這個環境中也可能有許多伺服器。 每個資料庫都會在分區對應中對應，因此呼叫可路由至正確的伺服器和資料庫。 資料庫會根據分區金鑰進行追蹤，而且每個分區都會指派金鑰值的範圍。 例如，分區金鑰可能代表從「D」到「F」的客戶名稱。所有分區的對應（亦稱之資料庫）及其對應範圍都包含在全域分區對應 (GSM)。 每個資料庫也包含分區上所含範圍的對應，稱之本機分區對應 (LSM)。 當應用程式連線到分區，對應會進行快取給應用程式，實現快速擷取。 LSM 可用來驗證快取資料。

GSM 和 LSM 可能會因為下列原因而出現不同步：

  1. 刪除的分區範圍被視為不再使用，或重新命名分區。 刪除分區會導致孤立的分區對應。 同樣地，重新命名的資料庫會造成孤立的分區對應。 根據變更的意圖，可能需要移除分區，或需要更新分區位置。 欲復原刪除的資料庫，請參閱 [還原刪除的資料庫]。
  2. 發生異地容錯移轉事件。 欲繼續作業，必須在應用程式中更新伺服器名稱和分區對應管理員的資料庫名稱，然後更新分區對應中所有分區的分區對應詳細資料。 如果有異地容錯移轉，則這類恢復邏輯應該在容錯移轉工作流程內自動化。 自動化恢復動作可實現異地資料庫啟用無摩擦管理，並避免手動人為動作。 欲瞭解關於在資料中心中斷時復原資料庫的選項，請參閱 [商務持續性 和 災害復原]。
  3. 分區或 ShardMapManager 資料庫會還原至先前的時間點。 欲瞭解關於使用備份進行時間點復原，請參閱 [使用備份恢復]。

如需關於 Azure SQL 資料庫彈性資料庫工具、異地複寫和還原的其他資訊，請參閱下列各項：

從 ShardMapManager 擷取 RecoveryManager

第一步驟是建立 RecoveryManager 執行個體。 GetRecoveryManager 方法會回傳目前 ShardMapManager 執行個體的復原管理員。 欲解決分區對應中的任何不一致，您必須先擷取特定分區對應的 RecoveryManager。

 ShardMapManager smm = ShardMapManagerFactory.GetSqlShardMapManager(smmConnectionString,  
          ShardMapManagerLoadPolicy.Lazy);
          RecoveryManager rm = smm.GetRecoveryManager();

在此範例中，RecoveryManager 會從 ShardMapManager 初始化。 包含 ShardMap 的 ShardMapManager 也已經初始化。

由於此應用程式程式碼會操控分區對應本身，因此 Factory 方法中使用的認證（在先前範例中為 smmConnectionString）應該具備連接字串歸屬之 GSM 資料庫的讀寫權限。 這些認證通常不同於用來開啟資料相依路由連線的認證。 如需其他資訊，請參閱 [在彈性資料庫用戶端使用認證。

刪除分區之後，從 ShardMap 移除分區

DetachShard 方法會從分區對應的給定分區中斷連結，並刪除與分區相關聯的對應。

  • 位置參數是指被中斷連結的分區位置，特別是伺服器名稱和資料庫名稱。
  • shardMapName 參數是分區對應名稱。 只有當多分區對應是由相同的分區對應管理員管理時，才需要這麼做。 選擇性。

這很重要

只有在您確定更新對應的範圍為空白時，才可使用這項技術。 上述方法並不會檢查要移動的資料範圍，因此您最好在程式碼中納入檢查。

此範例會從分區對應中移除分區。

rm.DetachShard(s.Location, customerMap);

分區對應會在刪除分區之前，反映 GSM 中的分區位置。 因為已刪除分區，所以假設這是蓄意，且不再使用分區金鑰範圍。 如果不是，您可以執行時間點還原。 欲從早前的時間點復原分區。 （在此情況下，請檢閱下一節來偵測分區不一致。）欲進行復原，請參閱 [時間點復原]。

因為假設資料庫刪除為蓄意，所以最後的系統管理清除動作是刪除分區對應管理員中的分區項目。 這可預防應用程式不小心將資訊寫入非預期的範圍。

欲偵測對應差異

DetectMappingDifferences 方法會選取並回傳其中一個分區對應（本機或全域），作為真實來源，並協調分區對應（GSM 和 LSM）上的對應。

rm.DetectMappingDifferences(location, shardMapName);
  • 該位置指定了伺服器名稱和資料庫名稱。
  • shardMapName 參數是分區對應名稱。 只有當多分區對應是由相同的分區對應管理員管理時，才需要這麼做。 選擇性。

欲解決對應差異

ResolveMappingDifferences 方法會選取並傳回其中一個分區對應（本機或全域），作為真實來源，並協調分區對應（GSM 和 LSM）上的對應。

ResolveMappingDifferences (RecoveryToken, MappingDifferenceResolution.KeepShardMapping);
  • RecoveryToken 參數列舉特定分區之 GSM 與 LSM 之間的對應差異。
  • MappingDifferenceResolution 列舉可用來指明解決分區對應差異的方法。
  • 當 LSM 包含精確的對應時，建議使用 MappingDifferenceResolution.KeepShardMapping，因此應使用分區中的對應。 如果發生容錯移轉，通常會發生這種情況：分區現在位於新的伺服器上。 由於分區必須先從 GSM 中移除（使用 RecoveryManager.DetachShard 方法），因此 GSM 上不再存在對應。 因此，LSM 必須用來重新建立分區對應。

還原分區之後，將分區連結至 ShardMap

AttachShard 方法會將給定的分區連結至分區對應。 接著，偵測任何分區對應的不一致，並更新對應以符合分區還原點的分區。 假設資料庫也重新命名，以反映原始資料庫名稱（還原分區之前），因為時間點還原預設為附加時間戳記的新資料庫。

rm.AttachShard(location, shardMapName)
  • 位置參數是所連結分區的伺服器名稱和資料庫名稱。
  • shardMapName 參數是分區對應名稱。 只有當多分區對應是由相同的分區對應管理員管理時，才需要這麼做。 選擇性。

本範例會將分區新增至最近從早前時間點還原的分區對應。 由於分區（也就是 LSM 中分區的對應）已還原，因此可能與 GSM 中的分區項目不一致。 在此範例程式碼之外，分區已還原且重新命名為資料庫的原始名稱。 由於已還原，因此假設 LSM 中的對應是受信任的對應。

rm.AttachShard(s.Location, customerMap);
var gs = rm.DetectMappingDifferences(s.Location);
   foreach (RecoveryToken g in gs)
    {
    rm.ResolveMappingDifferences(g, MappingDifferenceResolution.KeepShardMapping);
    }

分區的異地容錯移轉（還原）後，更新分區位置

如果有異地容錯移轉，次要資料庫會變成具寫入權限，並成為新的主要資料庫。 伺服器的名稱，而且可能是資料庫（取決於您的設定），可能與原始主要資料庫有所不同。 因此，必須修正 GSM 和 LSM 中分區的對應項目。 同樣地，如果資料庫還原到不同的名稱或位置，或還原到早前時間點，這可能會在分區對應中造成不一致。 分區對應管理員會處理與正確資料庫的開啟連線散發。 散發是基於分區對應中的資料和應用程式要求目標的分區金鑰值。 異地容錯移轉之後，這項資訊必須以所復原資料庫的準確伺服器名稱、資料庫名稱和分區對應進行更新。

最佳做法

異地容錯移轉和恢復操作通常是由應用程式雲端系統管理員刻意使用 Azure SQL 資料庫 商務持續性功能所管理。 商務持續性規劃需要處理、程序和措施，確保可以繼續商務操作，不會中斷。 此工作流程中應使用 RecoveryManager 類別中提供的方法，確保根據所採取的恢復動作，將 GSM 和 LSM 保持在最新狀態。 有五個基本步驟，可正確確保 GSM 和 LSM 反映容錯移轉事件後的準確資訊。 執行這些步驟的應用程式程式碼可以整合到現有的工具和工作流程。

  1. 從 ShardMapManager 擷取 RecoveryManager。
  2. 將舊分區與分區對應中斷連結。
  3. 將新分區連結至分區對應，包括新的分區位置。
  4. 偵測 GSM 與 LSM 之間的對應不一致。
  5. 解決 GSM 與 LSM 之間的差異，信任 LSM。

此範例會執行下列步驟：

  1. 從分區對應中移除分區，反映容錯移轉事件前的分區位置。

  2. 將分區連結至分區對應，反映新的分區位置（參數 「Configuration.SecondaryServer」 是新的伺服器名稱，但相同的資料庫名稱）。

  3. 偵測每個分區中 GSM 與 LSM 之間的對應差異，擷取恢復權杖。

  4. 藉由信任每個分區的 LSM 對應來解決不一致的情況。

    var shards = smm.GetShards();
foreach (shard s in shards)
{
  if (s.Location.Server == Configuration.PrimaryServer)
      {
       ShardLocation slNew = new ShardLocation(Configuration.SecondaryServer, s.Location.Database);
       rm.DetachShard(s.Location);
       rm.AttachShard(slNew);
       var gs = rm.DetectMappingDifferences(slNew);
       foreach (RecoveryToken g in gs)
         {
            rm.ResolveMappingDifferences(g, MappingDifferenceResolution.KeepShardMapping);
         }
     }
 }

相關內容

尚未使用彈性資料庫工具？ 請參閱使用者入門指南。 如有疑問，請在 SQL Database 的 Microsoft Q&A 問題頁面上與我們連絡。如有功能要求，請在 SQL Database 意見反應論壇中新增想法或投票支持現有的想法。