Oprava problémů s mapováním horizontálních oddílů pomocí třídy RecoveryManager

  • Článek

Platí pro:Azure SQL Database

Třída RecoveryManager poskytuje ADO.NET aplikace schopnost snadno rozpoznat a opravit všechny nekonzistence mezi globální mapou horizontálních oddílů (GSM) a mapou místních horizontálních oddílů (LSM) v prostředí horizontálně dělené databáze.

GSM a LSM sledují mapování jednotlivých databází v horizontálně děleném prostředí. Občas dojde k přerušení mezi GSM a LSM. V takovém případě pomocí třídy RecoveryManager detekujte a opravte přerušení.

Třída RecoveryManager je součástí klientské knihovny elastické databáze.

Shard map

Definice termínů najdete v glosáři nástrojů elastické databáze. Informace o tom, jak se ShardMapManager používá ke správě dat v horizontálně děleném řešení, najdete v tématu Správa mapování horizontálních oddílů.

Proč používat správce obnovení

V prostředí horizontálně dělené databáze existuje jeden tenant na databázi a mnoho databází na server. V prostředí může být také mnoho serverů. Každá databáze je mapována v mapě horizontálních oddílů, takže volání je možné směrovat na správný server a databázi. Databáze se sledují podle klíče horizontálního dělení a každému horizontálnímu oddílu je přiřazen rozsah hodnot klíčů. Například klíč horizontálního dělení může představovat jména zákazníků z "D" na "F". Mapování všech horizontálních oddílů (označovaných také jako databáze) a jejich rozsahy mapování jsou obsaženy v globální mapě horizontálních oddílů (GSM). Každá databáze obsahuje také mapu oblastí obsažených v horizontálním oddílu, který se označuje jako mapování místních horizontálních oddílů (LSM). Když se aplikace připojí k horizontálnímu oddílu, mapování se ukládá do mezipaměti s aplikací pro rychlé načtení. LSM slouží k ověření dat uložených v mezipaměti.

Gsm a LSM se mohou stát mimo synchronizaci z následujících důvodů:

  1. Odstranění horizontálního oddílu, jehož rozsah se už nepoužívá, nebo přejmenování horizontálního oddílu. Odstraněním horizontálního oddílu dojde k mapování osamocených horizontálních oddílů. Podobně přejmenováná databáze může způsobit osamocené mapování horizontálních oddílů. V závislosti na záměru změny může být horizontální oddíl potřeba odebrat nebo je potřeba aktualizovat umístění horizontálního oddílu. Pokud chcete obnovit odstraněnou databázi, přečtěte si téma Obnovení odstraněné databáze.
  2. Dojde k události geografického převzetí služeb při selhání. Chcete-li pokračovat, je nutné aktualizovat název serveru a název databáze správce mapování horizontálních oddílů v aplikaci a pak aktualizovat podrobnosti mapování horizontálních oddílů pro všechny horizontální oddíly v mapě horizontálních oddílů. Pokud dojde k geografickému převzetí služeb při selhání, měla by být taková logika obnovení automatizovaná v rámci pracovního postupu převzetí služeb při selhání. Automatizace akcí obnovení umožňuje bezproblémovou správu geograficky povolených databází a zabraňuje ručním lidským akcím. Další informace o možnostech obnovení databáze v případě výpadku datacentra najdete v tématu Provozní kontinuita a zotavení po havárii.
  3. Horizontální oddíl nebo databáze ShardMapManager se obnoví do dřívějšího bodu v čase. Další informace o obnovení k určitému bodu v čase pomocí záloh najdete v tématu Obnovení pomocí záloh.

Další informace o nástrojích elastické databáze Azure SQL Database, geografické replikaci a obnovení najdete v následujících tématech:

Načítání objektu RecoveryManager z objektu ShardMapManager

Prvním krokem je vytvoření instance RecoveryManager. Metoda GetRecoveryManager vrátí správce obnovení pro aktuální instanci ShardMapManager . Pokud chcete vyřešit případné nekonzistence v mapě horizontálních oddílů, musíte nejprve načíst Správce obnovení pro konkrétní mapu horizontálních oddílů.

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

V tomto příkladu je Objekt RecoveryManager inicializován z objektu ShardMapManager. Objekt ShardMapManager obsahující objekt ShardMap je již také inicializován.

Vzhledem k tomu, že tento kód aplikace manipuluje se samotnou mapou horizontálních oddílů, přihlašovací údaje použité v metodě továrny (v předchozím příkladu smm Připojení ionString) by měly být přihlašovací údaje, které mají oprávnění ke čtení a zápisu do databáze GSM odkazované připojovací řetězec. Tyto přihlašovací údaje se obvykle liší od přihlašovacích údajů používaných k otevření připojení pro směrování závislé na datech. Další informace najdete v tématu Použití přihlašovacích údajů v klientovi elastické databáze.

Odebrání horizontálního oddílu z objektu ShardMap po odstranění horizontálního oddílu

Metoda DetachShard oddělí daný horizontální oddíl z mapy horizontálních oddílů a odstraní mapování přidružená k horizontálnímu oddílu.

  • Parametr umístění je umístění horizontálního oddílu, konkrétně název serveru a název databáze, od odpojení horizontálního oddílu.
  • Parametr shardMapName je název mapování horizontálních oddílů. To se vyžaduje jenom v případě, že stejný správce mapování horizontálních oddílů spravuje více map horizontálních oddílů. Nepovinné.

Důležité

Tuto techniku použijte pouze v případě, že jste si jisti, že rozsah aktualizovaného mapování je prázdný. Výše uvedené metody nekontrolují data pro přesun rozsahu, takže je nejlepší zahrnout do kódu kontroly.

Tento příklad odebere horizontální oddíly z mapy horizontálních oddílů.

rm.DetachShard(s.Location, customerMap);

Mapa horizontálních oddílů odráží umístění horizontálních oddílů v GSM před odstraněním horizontálního oddílu. Vzhledem k tomu, že se horizontální oddíl odstranil, předpokládá se, že se jedná o úmyslné a rozsah klíčů horizontálního dělení se už nepoužívá. Pokud ne, můžete provést obnovení k určitému bodu v čase. obnovení horizontálního oddílu z dřívějšího bodu v čase. (V takovém případě si projděte následující část a zjistěte nekonzistenci horizontálních oddílů.) Obnovení najdete v tématu Obnovení k určitému bodu v čase.

Vzhledem k tomu, že se předpokládá, že odstranění databáze bylo úmyslné, poslední akcí vyčištění správy je odstranit položku horizontálního oddílu ve správci mapování horizontálních oddílů. To zabrání aplikaci neúmyslně psát informace do rozsahu, který se neočekává.

Detekce rozdílů v mapování

Metoda DetectMappingDifferences vybere a vrátí jednu z map horizontálních oddílů (buď místní nebo globální), jako zdroj pravdy a odsouhlasí mapování na obou mapách horizontálních oddílů (GSM i LSM).

rm.DetectMappingDifferences(location, shardMapName);
  • Umístění určuje název serveru a název databáze.
  • Parametr shardMapName je název mapování horizontálních oddílů. To se vyžaduje jenom v případě, že stejný správce mapování horizontálních oddílů spravuje více map horizontálních oddílů. Nepovinné.

Řešení rozdílů v mapování

Metoda ResolveMappingDifferences vybere jednu z map horizontálních oddílů (místní nebo globální) jako zdroj pravdy a odsouhlasí mapování na obou mapách horizontálních oddílů (GSM i LSM).

ResolveMappingDifferences (RecoveryToken, MappingDifferenceResolution.KeepShardMapping);
  • Parametr RecoveryToken vyčísluje rozdíly v mapováních mezi GSM a LSM pro konkrétní horizontální oddíl.
  • Výčet MappingDifferenceResolution se používá k označení metody pro překlad rozdílu mezi mapováními horizontálních oddílů.
  • MapováníDifferenceResolution.KeepShardMapping se doporučuje, pokud LSM obsahuje přesné mapování, a proto by se mělo použít mapování v horizontálním oddílu. Obvykle se jedná o případ, kdy dojde k převzetí služeb při selhání: horizontální oddíl se teď nachází na novém serveru. Vzhledem k tomu, že horizontální oddíl musí být nejprve odebrán z GSM (pomocí metody RecoveryManager.DetachShard), mapování již v GSM neexistuje. Proto musí být LSM použit k opětovnému vytvoření mapování horizontálních oddílů.

Připojení horizontálního oddílu k objektu ShardMap po obnovení horizontálního oddílu

Metoda AttachShard připojí daný horizontální oddíl k mapě horizontálních oddílů. Pak zjistí nekonzistence mapování horizontálních oddílů a aktualizuje mapování tak, aby odpovídalo horizontálnímu oddílu v okamžiku obnovení horizontálních oddílů. Předpokládá se, že databáze se také přejmenuje tak, aby odrážela původní název databáze (před obnovením horizontálního oddílu), protože obnovení k určitému bodu v čase je výchozí pro novou databázi připojenou s časovým razítkem.

rm.AttachShard(location, shardMapName)
  • Parametr umístění je název serveru a název databáze připojeného horizontálního oddílu.
  • Parametr shardMapName je název mapování horizontálních oddílů. To se vyžaduje jenom v případě, že stejný správce mapování horizontálních oddílů spravuje více map horizontálních oddílů. Nepovinné.

Tento příklad přidá horizontální oddíl do mapy horizontálních oddílů, která byla nedávno obnovena z dřívějšího bodu v čase. Vzhledem k tomu, že horizontální oddíl (konkrétně mapování horizontálního oddílu v LSM) byl obnoven, je potenciálně nekonzistentní se vstupem horizontálního oddílu v GSM. Mimo tento ukázkový kód byl horizontální oddíl obnoven a přejmenován na původní název databáze. Vzhledem k tomu, že byl obnoven, předpokládá se, že mapování v LSM je důvěryhodné mapování.

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

Aktualizace umístění horizontálních oddílů po geografickém převzetí služeb při selhání (obnovení) horizontálních oddílů

Pokud dojde k geografickému převzetí služeb při selhání, zpřístupní se sekundární databáze pro zápis a stane se novou primární databází. Název serveru a případně databáze (v závislosti na vaší konfiguraci) se může lišit od původní primární databáze. Proto musí být opraveny položky mapování horizontálního oddílu v GSM a LSM. Podobně platí, že pokud je databáze obnovena do jiného názvu nebo umístění nebo k dřívějšímu bodu v čase, může to způsobit nekonzistence v mapách horizontálních oddílů. Správce mapování horizontálních oddílů zpracovává distribuci otevřených připojení ke správné databázi. Distribuce je založená na datech v mapě horizontálních oddílů a na hodnotě klíče horizontálního dělení, který je cílem požadavku aplikace. Po geografickém převzetí služeb při selhání musí být tyto informace aktualizovány přesným názvem serveru, názvem databáze a mapováním horizontálních oddílů obnovené databáze.

Osvědčené postupy

Geografické převzetí služeb při selhání a obnovení jsou operace, které obvykle spravuje správce cloudu aplikace záměrně s využitím funkcí provozní kontinuity služby Azure SQL Database. Plánování kontinuity podnikových procesů vyžaduje procesy, postupy a opatření k zajištění toho, aby obchodní operace mohly bez přerušení pokračovat. Metody dostupné jako součást třídy RecoveryManager by měly být použity v rámci tohoto pracovního toku, aby se zajistilo, že GSM a LSM jsou udržovány v aktualizovaném stavu na základě provedených akcí obnovení. Existuje pět základních kroků k řádnému zajištění toho, aby GSM a LSM odrážely přesné informace po události převzetí služeb při selhání. Kód aplikace pro provedení těchto kroků je možné integrovat do stávajících nástrojů a pracovního postupu.

  1. Načtěte Objekt RecoveryManager z objektu ShardMapManager.
  2. Odpojte starý horizontální oddíl z mapy horizontálních oddílů.
  3. Připojte nový horizontální oddíl k mapě horizontálních oddílů, včetně nového umístění horizontálního oddílu.
  4. Detekce nekonzistence v mapování mezi GSM a LSM.
  5. Vyřešte rozdíly mezi GSM a LSM a důvěřujte LSM.

Tento příklad provede následující kroky:

  1. Odebere horizontální oddíly z mapy horizontálních oddílů, které odrážejí umístění horizontálních oddílů před událostí převzetí služeb při selhání.

  2. Připojí horizontální oddíly k mapě horizontálních oddílů odrážející nová umístění horizontálních oddílů (parametr Configuration.SecondaryServer je nový název serveru, ale stejný název databáze).

  3. Načte tokeny obnovení tím, že zjistí rozdíly mapování mezi GSM a LSM pro každý horizontální oddíl.

  4. Vyřeší nekonzistence tím, že důvěřujete mapování z LSM každého horizontálního oddílu.

    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);
         }
     }
 }

Další materiály

Ještě nepoužíváte nástroje elastické databáze? Podívejte se na naši příručku Začínáme. Pokud máte dotazy, kontaktujte nás na stránce otázek Microsoft Q&A pro SLUŽBU SQL Database a žádosti o funkce, přidejte nové nápady nebo hlasujte pro stávající nápady ve fóru pro zpětnou vazbu ke službě SQL Database.