Använda klassen RecoveryManager för att åtgärda problem med shardkarta

2025-06-16

Klassen RecoveryManager ger ADO.NET program möjlighet att enkelt identifiera och korrigera eventuella inkonsekvenser mellan den globala shardkartan (GSM) och den lokala shardkartan (LSM) i en fragmenterad databasmiljö.

GSM och LSM spårar mappningen av varje databas i en fragmenterad miljö. Ibland uppstår en paus mellan GSM och LSM. I så fall använder du RecoveryManager klassen för att identifiera och reparera brytningen.

RecoveryManager-klassen är en del av projektet Bygga skalbara molndatabaser.

Termdefinitioner finns i Elastic Database-verktygsordlista. Information om hur ShardMapManager används för att hantera data i en horisontell lösning finns i Skala ut databaser med shard map manager.

Varför ska du använda återställningshanteraren?

I en fragmenterad databasmiljö finns det en klientorganisation per databas och många databaser per server. Det kan också finnas många servrar i miljön. Varje databas mappas i fragmentkartan, så anrop kan dirigeras till rätt server och databas. Databaser spåras enligt en partitioneringsnyckel och varje shard tilldelas ett intervall med nyckelvärden. En horisontell partitioneringsnyckel kan till exempel representera kundnamnen från "D" till "F". Mappningen av alla shards (även kallade databaser) och deras mappningsintervall finns i den globala shardkartan (GSM). Varje databas innehåller också en karta över intervallen som finns på fragmentet som kallas den lokala shardkartan (LSM). När en app ansluter till en shard cachelagras mappningen med appen för snabb hämtning. LSM används för att verifiera cachelagrade data.

GSM och LSM kan bli osynkroniserade av följande skäl:

Borttagning av en shard vars intervall antas inte längre vara i bruk, eller namnbyte av en shard. Om du tar bort en shard resulterar det i en överbliven shard-mappning. På samma sätt kan en omdöpt databas orsaka en överbliven shardmappning. Beroende på avsikten med ändringen kan fragmentet behöva tas bort eller fragmentplatsen behöva uppdateras. Information om hur du återställer en borttagen databas finns i Återställa en databas från en säkerhetskopia i Azure SQL Database.
En geo-failoverhändelse inträffar. Om du vill fortsätta måste du uppdatera servernamnet och databasnamnet för shard map manager i programmet och sedan uppdatera shardmappningsinformationen för alla shards i en fragmentkarta. Om det finns en geo-redundans bör sådan återställningslogik automatiseras i arbetsflödet för redundans. Automatisering av återställningsåtgärder möjliggör friktionsfri hanterbarhet för geo-aktiverade databaser och undviker manuella mänskliga åtgärder. Mer information om alternativ för att återställa en databas om det uppstår ett avbrott i datacenter finns i Affärskontinuitet i Azure SQL Database och Vägledning för haveriberedskap – Azure SQL Database.
Antingen återställs en shard eller en ShardMapManager databas till en tidigare tidpunkt. Information om återställning till tidpunkt med hjälp av säkerhetskopior finns i Återställa en databas från en säkerhetskopia i Azure SQL Database.

Mer information om Azure SQL Database Elastic Database-verktyg, geo-replikering och återställning finns i:

Hämta RecoveryManager från en ShardMapManager

Det första steget är att skapa en RecoveryManager instans. Metoden GetRecoveryManager returnerar återställningshanteraren för den aktuella ShardMapManager-instansen. För att åtgärda eventuella inkonsekvenser i fragmentkartan måste du först hämta RecoveryManager för den specifika fragmentkartan.

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

I det här exemplet RecoveryManager initieras från ShardMapManager. Den ShardMapManager som innehåller en ShardMap är också redan initierad.

Eftersom den här programkoden manipulerar själva shardkartan bör de autentiseringsuppgifter som används i fabriksmetoden (i föregående exempel smmConnectionString) vara autentiseringsuppgifter som har läs- och skrivbehörigheter för GSM-databasen som refereras av anslutningssträngen. Dessa autentiseringsuppgifter skiljer sig vanligtvis från autentiseringsuppgifter som används för att öppna anslutningar för databeroende routning. Mer information finns i Autentiseringsuppgifter som används för att komma åt Elastic Database-klientbiblioteket.

Ta bort en shard från ShardMap när en shard har tagits bort

Metoden DetachShard kopplar bort det angivna fragmentet från fragmentkartan och tar bort mappningar som är associerade med fragmentet.

Parametern location avser shardens plats, närmare bestämt servernamn och databasnamn, för den shard som kopplas bort.
Parametern shardMapName är shardkartans namn. Detta krävs endast när flera shardkartor hanteras av samma shardkarthanterare. Valfritt.

Viktigt!

Använd endast den här tekniken om du är säker på att intervallet för den uppdaterade mappningen är tomt. Dessa metoder kontrollerar inte data för det intervall som flyttas, så det är bäst att inkludera kontroller i koden.

Det här exemplet tar bort shards från fragmentkartan.

rm.DetachShard(s.Location, customerMap);

Fragmentkartan återspeglar platsen för fragmentet i GSM innan fragmentet tas bort. Eftersom skärvan har tagits bort antas det att detta var avsiktligt och att nyckelområdet för skärvning inte längre används. Annars kan du köra punktåterställning. Så här återställer du fragmentet från en tidigare tidpunkt. (I så fall granskar du följande avsnitt för att identifiera shard-inkonsekvenser.) Information om hur du återställer finns i Återställa en databas från en säkerhetskopia i Azure SQL Database.

Eftersom det antas att databasborttagningen var avsiktlig, är den sista administrativa rensningsåtgärden att i shard map manager ta bort posten för fragmentet. Detta förhindrar att programmet oavsiktligt skriver information till ett intervall som inte är förväntat.

Identifiera mappningsskillnader

Metoden DetectMappingDifferences väljer och returnerar en av shardkartorna (antingen lokal eller global) som sanningskälla och stämmer av mappningar på båda shardkartorna (GSM och LSM).

rm.DetectMappingDifferences(location, shardMapName);

location Anger servernamnet och databasnamnet.
Parametern shardMapName är shardkartans namn. Detta krävs bara om flera shardkartor hanteras av samma shardkarthanterare. Valfritt.

Lösa mappningsskillnader

Metoden ResolveMappingDifferences väljer en av shardkartorna (antingen lokal eller global) som den definitiva källan och avstämmer mappningar på båda shardkartorna (GSM och LSM).

ResolveMappingDifferences (RecoveryToken, MappingDifferenceResolution.KeepShardMapping);

Parametern RecoveryToken räknar upp skillnaderna i mappningarna mellan GSM och LSM för den specifika sharden.
Uppräkningen MappingDifferenceResolution används för att ange metoden för att lösa skillnaden i shardmappningarna.
MappingDifferenceResolution.KeepShardMapping rekommenderas att när LSM innehåller den korrekta mappningen, ska mappningen i shard användas. Detta är vanligtvis fallet om det finns en redundansväxling: fragmentet finns nu på en ny server. Eftersom fragmentet först måste tas bort från GSM (med hjälp av RecoveryManager.DetachShard metoden) finns det inte längre någon mappning på GSM. Därför måste LSM användas för att återupprätta delmappningen.

Anslut en skärva till ShardMap efter att en skärva har återställts

Metoden AttachShard kopplar den angivna sharden till fragmentkartan. Den identifierar sedan eventuella inkonsekvenser i fragmentkartan och uppdaterar mappningarna så att de matchar fragmentet vid tidpunkten för fragmentåterställningen. Man antar att databasen också har bytt namn för att återspegla det ursprungliga databasnamnet (innan databassharden återställdes), eftersom standard för återställning till en tidigare tidpunkt är en ny databas som har lags till med en tidsstämpel.

rm.AttachShard(location, shardMapName)

Parametern location är servernamnet och databasnamnet för den shard som kopplas.
Parametern shardMapName är shardkartans namn. Detta krävs endast när flera shardkartor hanteras av samma shardkarthanterare. Valfritt.

Det här exemplet lägger till en shard i fragmentkartan som nyligen har återställts från en tidigare tidpunkt. Eftersom fragmentet (nämligen mappningen för shard i LSM) har återställts är det potentiellt oförenligt med fragmentposten i GSM. Utanför den här exempelkoden återställdes sharden och återfick sitt ursprungliga namn på databasen. Sedan den återställdes antas det att mappningen i LSM är den betrodda mappningen.

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

Uppdatera fragmentplatser efter en geo-omkoppling (återställning) av fragment

Om det inträffar en geo-failover görs den sekundära databasen skrivåtkomlig och blir den nya primära databasen. Namnet på servern och eventuellt databasen (beroende på din konfiguration) kan skilja sig från den ursprungliga primära databasen. Därför måste mappningsposterna för shard i GSM och LSM vara fasta. På samma sätt kan detta orsaka inkonsekvenser i fragmentkartorna om databasen återställs till ett annat namn eller en annan plats eller till en tidigare tidpunkt. Shard Map Manager hanterar fördelningen av öppna anslutningar till rätt databas. Distributionen baseras på data i fragmentkartan och värdet för den partitioneringsnyckel som är målet för programbegäran. Efter ett geo-failover måste den här informationen uppdateras med det korrekta servernamnet, databasnamnet och mappningen av fragmenten i den återställda databasen.

Metodtips

Geo-failover och återställning är operationer som vanligtvis hanteras av en molnadministratör för programmet som medvetet använder affärskontinuitetsfunktioner i Azure SQL Database. Planering av affärskontinuitet kräver processer, procedurer och åtgärder för att säkerställa att verksamheten kan fortsätta utan avbrott. De metoder som är tillgängliga som en del av RecoveryManager klassen bör användas i det här arbetsflödet för att säkerställa att GSM och LSM hålls up-todatum baserat på den återställningsåtgärd som vidtagits. Det finns fem grundläggande steg för att säkerställa att GSM och LSM återspeglar korrekt information efter en redundanshändelse. Programkoden för att köra de här stegen kan integreras i befintliga verktyg och arbetsflöden.

Hämta RecoveryManager från ShardMapManager.
Koppla bort det gamla datasegmentet från fragmentkartan.
Koppla den nya fragmentet till fragmentkartan, inklusive den nya fragmentplatsen.
Identifiera inkonsekvenser i mappningen mellan GSM och LSM.
Lös skillnaderna mellan GSM och LSM och lita på LSM.

Det här exemplet utför följande steg:

Tar bort shards från shardkartan som återspeglar shardpositioner före failover-händelsen.
Kopplar shardarna till Shard Map som återspeglar de nya platserna för shardarna (parametern Configuration.SecondaryServer är det nya servernamnet, men har samma databasnamn).
Hämtar återställningstoken genom att identifiera mappningsskillnader mellan GSM och LSM för varje shard.

Löser inkonsekvenserna genom att lita på mappningen från LSM för varje shard.

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

Använder du inte elastiska databasverktyg än? Kolla in vår komma igång-guide. För frågor kan du kontakta oss på Microsoft Q&En frågesida för SQL Database och för funktionsförfrågningar, lägga till nya idéer eller rösta på befintliga idéer i SQL Database-feedbackforumet.

Feedback

Var den här sidan till hjälp?