Problemen met shard-toewijzingen oplossen met de RecoveryManager-klasse

Van toepassing op: Azure SQL Database

De RecoveryManager-klasse biedt ADO.NET toepassingen de mogelijkheid om eenvoudig inconsistenties tussen de globale shardtoewijzing (GSM) en de lokale shardtoewijzing (LSM) in een shard-databaseomgeving te detecteren en te corrigeren.

De GSM en LSM volgen de toewijzing van elke database in een shard-omgeving. Af en toe treedt er een onderbreking op tussen de GSM en de LSM. In dat geval gebruikt u de RecoveryManager-klasse om de onderbreking te detecteren en te herstellen.

De RecoveryManager-klasse maakt deel uit van de Elastic Database-clientbibliotheek.

Zie de woordenlijst voor hulpprogramma's van de elastische database voor definities van termen. Als u wilt weten hoe ShardMapManager wordt gebruikt voor het beheren van gegevens in een shard-oplossing, raadpleegt u Shard-toewijzingsbeheer.

Waarom de Recovery Manager gebruiken

In een shard-databaseomgeving is er één tenant per database en veel databases per server. Er kunnen ook veel servers in de omgeving zijn. Elke database wordt toegewezen in de shard-toewijzing, zodat aanroepen naar de juiste server en database kunnen worden gerouteerd. Databases worden bijgehouden op basis van een sharding-sleutel en aan elke shard wordt een bereik met sleutelwaarden toegewezen. Een sharding-sleutel kan bijvoorbeeld de klantnamen van 'D' tot 'F' vertegenwoordigen. De toewijzing van alle shards (ook wel databases genoemd) en de bijbehorende toewijzingsbereiken zijn opgenomen in de globale shard-toewijzing (GSM). Elke database bevat ook een kaart van de bereiken die zijn opgenomen in de shard die de lokale shard-toewijzing (LSM) wordt genoemd. Wanneer een app verbinding maakt met een shard, wordt de toewijzing in de cache opgeslagen met de app voor snel ophalen. De LSM wordt gebruikt om gegevens in de cache te valideren.

De GSM en LSM kunnen om de volgende redenen niet synchroon worden:

1. Het verwijderen van een shard waarvan wordt aangenomen dat het bereik niet langer in gebruik is of waarvan wordt aangenomen dat het een shard een andere naam krijgt. Het verwijderen van een shard resulteert in een zwevende shardtoewijzing. Op dezelfde manier kan een hernoemde database een zwevende shardtoewijzing veroorzaken. Afhankelijk van de intentie van de wijziging moet de shard mogelijk worden verwijderd of moet de shardlocatie worden bijgewerkt. Zie Een verwijderde database herstellen als u een verwijderde database wilt herstellen.
2. Er treedt een geo-failovergebeurtenis op. Als u wilt doorgaan, moet u de servernaam en de databasenaam van shard-toewijzingsbeheer in de toepassing bijwerken en vervolgens de details van de shard-toewijzing voor alle shards in een shard-toewijzing bijwerken. Als er een geo-failover is, moet deze herstellogica worden geautomatiseerd binnen de failoverwerkstroom. Het automatiseren van herstelacties maakt een probleemloze beheerbaarheid mogelijk voor databases met geo-functionaliteit en vermijdt handmatige menselijke acties. Zie Bedrijfscontinuïteit en herstel na noodgevallen voor meer informatie over opties voor het herstellen van een database als er sprake is van een storing in een datacenter.
3. Een shard of de ShardMapManager-database wordt hersteld naar een eerder tijdstip. Zie Herstel met behulp van back-ups voor meer informatie over herstel naar een bepaald tijdstip met behulp van back-ups.

Zie het volgende voor meer informatie over azure SQL Database Elastic Database-hulpprogramma's, geo-replicatie en herstel:

• Overzicht: Bedrijfscontinuïteit in de cloud en herstel na noodgevallen van databases met SQL Database
• Aan de slag met hulpprogramma's voor elastische databases
• ShardMap-beheer

RecoveryManager ophalen uit een ShardMapManager

De eerste stap is het maken van een RecoveryManager-exemplaar. De methode GetRecoveryManager retourneert de recovery manager voor het huidige ShardMapManager-exemplaar . Als u inconsistenties in de shard-toewijzing wilt aanpakken, moet u eerst de RecoveryManager voor de specifieke shard-toewijzing ophalen.

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

In dit voorbeeld wordt de RecoveryManager geïnitialiseerd vanuit ShardMapManager. De ShardMapManager met een ShardMap is ook al geïnitialiseerd.

Omdat deze toepassingscode de shardtoewijzing zelf bewerkt, moeten de referenties die worden gebruikt in de factorymethode (in het voorgaande voorbeeld smm Verbinding maken ionString) referenties zijn die lees-schrijfmachtigingen hebben voor de GSM-database waarnaar wordt verwezen door de verbindingsreeks. Deze referenties verschillen doorgaans van referenties die worden gebruikt voor het openen van verbindingen voor gegevensafhankelijke routering. Zie Referenties gebruiken in de client voor elastische databases voor meer informatie.

Een shard uit de ShardMap verwijderen nadat een shard is verwijderd

Met de methode DetachShard wordt de opgegeven shard losgekoppeld van de shard-toewijzing en worden toewijzingen verwijderd die aan de shard zijn gekoppeld.

• De locatieparameter is de shardlocatie, met name servernaam en databasenaam, van de shard die wordt losgekoppeld.
• De parameter shardMapName is de naam van de shard-toewijzing. Dit is alleen vereist wanneer meerdere shard-toewijzingen worden beheerd door hetzelfde shard-toewijzingsbeheer. Optioneel.

Belangrijk

Gebruik deze techniek alleen als u zeker weet dat het bereik voor de bijgewerkte toewijzing leeg is. Met de bovenstaande methoden worden geen gegevens gecontroleerd op het bereik dat wordt verplaatst. Het is daarom raadzaam controles in uw code op te nemen.

In dit voorbeeld worden shards uit de shard-toewijzing verwijderd.

rm.DetachShard(s.Location, customerMap);

De shard-kaart weerspiegelt de shardlocatie in de GSM voordat de shard wordt verwijderd. Omdat de shard is verwijderd, wordt ervan uitgegaan dat dit opzettelijk was en het sharding-sleutelbereik niet meer in gebruik is. Zo niet, dan kunt u herstel naar een bepaald tijdstip uitvoeren. om de shard te herstellen vanaf een eerder tijdstip. (In dat geval raadpleegt u de volgende sectie om inconsistenties in shards te detecteren.) Zie Herstel naar een bepaald tijdstip om te herstellen.

Omdat ervan wordt uitgegaan dat het verwijderen van de database opzettelijk is, is de laatste opschoonactie voor beheer het verwijderen van de vermelding naar de shard in het shard-toewijzingsbeheer. Hierdoor voorkomt u dat de toepassing per ongeluk gegevens naar een bereik schrijft dat niet wordt verwacht.

Toewijzingsverschillen detecteren

De methode DetectMappingDifferences selecteert en retourneert een van de shard-kaarten (lokaal of globaal) als bron van waarheid en zorgt ervoor dat toewijzingen op beide shardkaarten (GSM en LSM) worden afgestemd.

rm.DetectMappingDifferences(location, shardMapName);

• De locatie geeft de servernaam en databasenaam op.
• De parameter shardMapName is de naam van de shard-toewijzing. Dit is alleen vereist als meerdere shard-toewijzingen worden beheerd door hetzelfde shard-toewijzingsbeheer. Optioneel.

Toewijzingsverschillen oplossen

Met de methode ResolveMappingDifferences selecteert u een van de shard-kaarten (lokaal of globaal) als bron van waarheid en worden toewijzingen op zowel shardkaarten (GSM als LSM) afgestemd.

ResolveMappingDifferences (RecoveryToken, MappingDifferenceResolution.KeepShardMapping);

• De parameter RecoveryToken inventariseert de verschillen in de toewijzingen tussen de GSM en de LSM voor de specifieke shard.
• De opsomming MappingDifferenceResolution wordt gebruikt om de methode aan te geven voor het oplossen van het verschil tussen de shardtoewijzingen.
• MappingDifferenceResolution.KeepShardMapping wordt aanbevolen dat wanneer de LSM de nauwkeurige toewijzing bevat en daarom de toewijzing in de shard moet worden gebruikt. Dit is meestal het geval als er een failover is: de shard bevindt zich nu op een nieuwe server. Omdat de shard eerst uit de GSM moet worden verwijderd (met behulp van de methode RecoveryManager.DetachShard), bestaat er geen toewijzing meer op de GSM. Daarom moet de LSM worden gebruikt om de shardtoewijzing opnieuw tot stand te brengen.

Een shard koppelen aan de ShardMap nadat een shard is hersteld

De methode AttachShard koppelt de opgegeven shard aan de shard-toewijzing. Vervolgens worden eventuele inconsistenties in de shardtoewijzing gedetecteerd en worden de toewijzingen bijgewerkt zodat deze overeenkomen met de shard op het punt van de shardherstel. Er wordt van uitgegaan dat de naam van de database ook wordt gewijzigd in overeenstemming met de oorspronkelijke databasenaam (voordat de shard werd hersteld), omdat het herstel naar een bepaald tijdstip standaard is ingesteld op een nieuwe database die is toegevoegd aan de tijdstempel.

rm.AttachShard(location, shardMapName)

• De locatieparameter is de servernaam en databasenaam van de shard die wordt gekoppeld.
• De parameter shardMapName is de naam van de shard-toewijzing. Dit is alleen vereist wanneer meerdere shard-toewijzingen worden beheerd door hetzelfde shard-toewijzingsbeheer. Optioneel.

In dit voorbeeld wordt een shard toegevoegd aan de shard-toewijzing die onlangs is hersteld vanaf een eerder tijdstip. Aangezien de shard (namelijk de toewijzing voor de shard in de LSM) is hersteld, is deze mogelijk inconsistent met de shardvermelding in de GSM. Buiten deze voorbeeldcode is de shard hersteld en hernoemd naar de oorspronkelijke naam van de database. Omdat deze is hersteld, wordt ervan uitgegaan dat de toewijzing in de LSM de vertrouwde toewijzing is.

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

Shardlocaties bijwerken na een geo-failover (herstel) van de shards

Als er een geo-failover is, wordt de secundaire database toegankelijk gemaakt voor schrijven en wordt de nieuwe primaire database. De naam van de server en mogelijk de database (afhankelijk van uw configuratie), kan afwijken van de oorspronkelijke primaire database. Daarom moeten de toewijzingsvermeldingen voor de shard in de GSM en LSM worden opgelost. Als de database wordt hersteld naar een andere naam of locatie of naar een eerder tijdstip, kan dit leiden tot inconsistenties in de shard-toewijzingen. Shard-toewijzingsbeheer verwerkt de distributie van geopende verbindingen met de juiste database. Distributie is gebaseerd op de gegevens in de shard-toewijzing en de waarde van de shardingsleutel die het doel is van de aanvraag voor toepassingen. Na een geo-failover moet deze informatie worden bijgewerkt met de juiste servernaam, databasenaam en shardtoewijzing van de herstelde database.

Aanbevolen procedures

Geofailover en herstel worden doorgaans beheerd door een cloudbeheerder van de toepassing die opzettelijk gebruikmaakt van functies voor bedrijfscontinuïteit van Azure SQL Database. Planning van bedrijfscontinuïteit vereist processen, procedures en maatregelen om ervoor te zorgen dat bedrijfsactiviteiten zonder onderbreking kunnen worden voortgezet. De methoden die beschikbaar zijn als onderdeel van de RecoveryManager-klasse, moeten in deze werkstroom worden gebruikt om ervoor te zorgen dat de GSM en LSM up-to-date blijven op basis van de uitgevoerde herstelactie. Er zijn vijf basisstappen om ervoor te zorgen dat de GSM en LSM de juiste informatie na een failover-gebeurtenis weerspiegelen. De toepassingscode voor het uitvoeren van deze stappen kan worden geïntegreerd in bestaande hulpprogramma's en werkstromen.

1. Haal de RecoveryManager op uit de ShardMapManager.
2. Koppel de oude shard los van de shard-kaart.
3. Koppel de nieuwe shard aan de shard-toewijzing, inclusief de nieuwe shardlocatie.
4. Detecteer inconsistenties in de toewijzing tussen de GSM en LSM.
5. Los verschillen tussen de GSM en de LSM op, waarbij u de LSM vertrouwt.

In dit voorbeeld worden de volgende stappen uitgevoerd:

1. Hiermee verwijdert u shards uit de Shard-toewijzing die shardlocaties weerspiegelen vóór de failover-gebeurtenis.

2. Koppelt shards aan de Shard-toewijzing die de nieuwe shardlocaties weergeeft (de parameter Configuration.SecondaryServer is de nieuwe servernaam, maar dezelfde databasenaam).

3. Haalt de hersteltokens op door toewijzingsverschillen tussen de GSM en de LSM voor elke shard te detecteren.

4. Lost de inconsistenties op door de toewijzing van de LSM van elke shard te vertrouwen.

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

Aanvullende bronnen

Gebruikt u nog geen hulpprogramma's voor elastische databases? Bekijk de handleiding Aan de slag. Neem voor vragen contact met ons op op de microsoft Q&A-vragenpagina voor SQL Database en voor functieaanvragen, voeg nieuwe ideeën toe of stem op bestaande ideeën in het feedbackforum van SQL Database.