Korrigera shard-kartproblem med RecoveryManager-klassen

Gäller för:Azure SQL Database

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 klassen RecoveryManager för att identifiera och reparera pausen.

Klassen RecoveryManager är en del av Elastic Database-klientbiblioteket.

Termdefinitioner finns i Elastic Database-verktygsordlista. Information om hur ShardMapManager används för att hantera data i en horisontell lösning finns i Shard Map Management(Shard Map Management).

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:

1. Borttagning av en shard vars intervall tros inte längre användas eller byta namn på en shard. Om du tar bort en shard resulterar det i en överbliven shardmappning. 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 så måste shardplatsen uppdateras. Information om hur du återställer en borttagen databas finns i Återställa en borttagen databas.
2. En geo-redundanshä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-redundansväxling 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 datacentret finns i Affärskontinuitet och haveriberedskap.
3. Antingen återställs en shard- eller ShardMapManager-databas till en tidigare tidpunkt. Information om återställning till tidpunkt med hjälp av säkerhetskopior finns i Återställning med hjälp av säkerhetskopior.

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

• Översikt: Affärskontinuitet i molnet och haveriberedskap för databaser med SQL Database
• Kom igång med elastiska databasverktyg
• ShardMap Management

Hämtar 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 shardkartan.

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

I det här exemplet initieras RecoveryManager från ShardMapManager. ShardMapManager som innehåller en ShardMap har också initierats.

Eftersom den här programkoden manipulerar själva shardkartan bör de autentiseringsuppgifter som används i fabriksmetoden (i föregående exempel, smm Anslut ionString) vara autentiseringsuppgifter som har läs- och skrivbehörigheter för GSM-databasen som refereras av anslutningssträng. Dessa autentiseringsuppgifter skiljer sig vanligtvis från autentiseringsuppgifter som används för att öppna anslutningar för databeroende routning. Mer information finns i Använda autentiseringsuppgifter i den elastiska databasklienten.

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.

• Platsparametern är shardplatsen, särskilt servernamnet och databasnamnet, för shard som kopplas från.
• 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. Metoderna ovan 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 fragmentplatsen i GSM innan shard tas bort. Eftersom shard har tagits bort antas det att detta var avsiktligt och att intervallet för horisontell partitioneringsnyckel inte längre används. Annars kan du köra återställning till tidpunkt. för att återställa shard 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ällning till tidpunkt.

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

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

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

Så här löser du mappningsskillnader

Metoden ResolveMappingDifferences väljer en av shardkartorna (antingen lokal eller global) som sanningskälla och avstäms 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 matcha skillnaden mellan shardmappningarna.
• MappingDifferenceResolution.KeepShardMapping rekommenderas att när LSM innehåller korrekt mappning och därför 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 metoden RecoveryManager.DetachShard) finns det inte längre någon mappning i GSM. Därför måste LSM användas för att återupprätta shardmappningen.

Koppla en shard till ShardMap när en shard 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. Det antas att databasen också har bytt namn för att återspegla det ursprungliga databasnamnet (innan shard återställdes), eftersom återställningen till tidpunkten som standard är en ny databas som läggs till med tidsstämpeln.

rm.AttachShard(location, shardMapName)

• Platsparametern är servernamnet och databasnamnet för fragmentet 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 shard (nämligen mappningen för shard i LSM) har återställts är den potentiellt inkonsekvent med fragmentposten i GSM. Utanför den här exempelkoden återställdes fragmentet och bytte namn till databasens ursprungliga namn. Sedan den återställdes antas mappningen i LSM vara 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 shardplatser efter en geo-redundansväxling (återställning) av shards

Om det finns en geo-redundans görs den sekundära databasen skrivtillgänglig 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 en geo-redundansväxling måste den här informationen uppdateras med det korrekta servernamnet, databasnamnet och fragmentmappningen av den återställda databasen.

Bästa praxis

Geo-redundans och återställning är åtgärder som vanligtvis hanteras av en molnadministratör för programmet som avsiktligt använder funktioner för affärskontinuitet 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 klassen RecoveryManager bör användas i det här arbetsflödet för att säkerställa att GSM och LSM hålls uppdaterade 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.

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

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

1. Tar bort shards från shardkartan som återspeglar shardplatser före redundanshändelsen.

2. Kopplar shards till Shard Map som återspeglar de nya shardplatserna (parametern "Configuration.SecondaryServer" är det nya servernamnet men samma databasnamn).

3. Hämtar återställningstoken genom att identifiera mappningsskillnader mellan GSM och LSM för varje shard.

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

Ytterligare resurser

Använder du inte elastiska databasverktyg än? Kolla in vår komma igång-guide. Om du har frågor kan du kontakta oss på microsofts Q&A-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.