Verwenden der RecoveryManager-Klasse zur Behebung von Problemen mit der Shard-Zuordnung

2025-06-18

Die RecoveryManager-Klasse bietet ADO.NET-Anwendungen die Möglichkeit, Inkonsistenzen zwischen der globalen Shardzuordnung (GSM) und der lokalen Shardzuordnung (LSM) in einer horizontal partitionierten Datenbank einfach zu erkennen und zu beheben.

Die GSM und die LSM verfolgen die Zuordnung der einzelnen Datenbanken in einer horizontal partitionierten Umgebung. Gelegentlich tritt eine Unterbrechung zwischen GSM und LSM auf. Verwenden Sie in diesem Fall die RecoveryManager Klasse, um den Bruch zu erkennen und zu reparieren.

Die RecoveryManager Klasse ist Teil der skalierbaren Clouddatenbanken erstellen.

Begriffsdefinitionen finden Sie unter Tools für elastische Datenbanken – Glossar. Um zu verstehen, wie ShardMapManager zur Verwaltung von Daten in einer Sharded-Lösung verwendet wird, lesen Sie Skalieren Sie Datenbanken mit dem Shard Map Manager.

Gründe für die Verwendung von Recovery Manager

In einer Sharded-Datenbankumgebung gibt es einen Mandanten pro Datenbank und viele Datenbanken pro Server. Es können auch viele Server in der Umgebung vorhanden sein. Jede Datenbank muss in der Shardzuordnung zugeordnet werden, sodass Aufrufe an den richtigen Server und die richtige Datenbank weitergeleitet werden können. Datenbanken werden anhand eines Shardingschlüssels nachverfolgt, und jedem Shard wird ein Bereich von Schlüsselwerten zugewiesen. Beispielsweise kann ein Shardingschlüssel die Kundennamen von "D" in "F" darstellen. Die Zuordnung aller Shards (auch als Datenbanken bezeichnet) und deren Zuordnungsbereiche sind in der globalen Shard-Karte (GSM) enthalten. Jede Datenbank enthält außerdem eine Zuordnung der auf dem Shard enthaltenen Bereiche, die als lokale Shardzuordnung (Local Shard Map, LSM) bezeichnet wird. Wenn eine App eine Verbindung mit einem Shard herstellt, wird die Zuordnung für den schnellen Abruf mit der App zwischengespeichert. Die LSM dient zum Überprüfen zwischengespeicherter Daten.

Die GSM und LSM können aus folgenden Gründen nicht mehr synchronisiert werden:

Ein Shard, dessen Bereich anscheinend nicht länger genutzt wird, wurde gelöscht, oder ein Shard wurde umbenannt. Das Löschen eines Shards führt zu einer verwaisten Shardzuordnung. Eine umbenannte Datenbank kann auf ähnliche Weise zu einer verwaisten Shardzuordnung führen. Je nach Intent der Änderung muss der Shard möglicherweise entfernt oder der Speicherort des Shards aktualisiert werden. Informationen zum Wiederherstellen einer gelöschten Datenbank finden Sie unter Wiederherstellen einer Datenbank aus einer Sicherung in der Azure SQL-Datenbank.
Ein Geofailoverereignis tritt ein. Um fortzufahren, müssen der Servername und der Datenbankname des Shardzuordnungs-Managers in der Anwendung und anschließend noch die Shardzuordnungsdetails für sämtliche Shards in einer Shardzuordnung aktualisiert werden. Wenn ein Geofailover vorhanden ist, sollte diese Wiederherstellungslogik innerhalb des Failoverworkflows automatisiert werden. Die Automatisierung von Wiederherstellungsaktionen gewährleistet eine reibungslose Verwaltbarkeit für geofähige Datenbanken und vermeidet manuelle, von Personen durchzuführende Aktionen. Weitere Informationen zu Optionen zum Wiederherstellen einer Datenbank, wenn ein Ausfall im Rechenzentrum vorhanden ist, finden Sie unter Geschäftskontinuität in Azure SQL-Datenbank und Notfallwiederherstellung – Azure SQL-Datenbank.
Entweder ein Shard oder die ShardMapManager Datenbank wird auf einen früheren Zeitpunkt zurückgesetzt. Informationen zum Zeitpunkt der Wiederherstellung mithilfe von Sicherungen finden Sie unter Wiederherstellen einer Datenbank aus einer Sicherung in der Azure SQL-Datenbank.

Weitere Informationen zu Azure SQL Database Elastic Database Tools, Georeplikation und Wiederherstellung finden Sie unter:

Abrufen von RecoveryManager aus einem ShardMapManager

Der erste Schritt besteht darin, eine RecoveryManager Instanz zu erstellen. Die GetRecoveryManager-Methode gibt den Recovery Manager für die aktuelle ShardMapManager-Instanz zurück. Um etwaige Inkonsistenzen in der Shard-Zuordnung zu beheben, müssen Sie zunächst die RecoveryManager für die jeweilige Shard-Zuordnung abrufen.

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

In diesem Beispiel wird die RecoveryManager aus der ShardMapManager initialisiert. Das ShardMapManager, das ein ShardMap enthält, ist ebenfalls bereits initialisiert.

Da dieser Code die Shard-Zuordnung selbst manipuliert, sollten die Anmeldeinformationen, die in der Factory-Methode verwendet werden (im vorangegangenen Beispiel smmConnectionString), Anmeldeinformationen sein, die über Lese- und Schreibberechtigungen für die GSM-Datenbank verfügen, auf die die Verbindungszeichenfolge verweist. Diese Anmeldeinformationen unterscheiden sich in der Regel von Anmeldeinformationen, die für das Öffnen von Verbindungen zum datenabhängigen Routing verwendet werden. Weitere Informationen finden Sie unter Anmeldeinformationen, die für den Zugriff auf die Elastic Database-Clientbibliothek verwendet werden.

Entfernen eines Shards aus der ShardMap nach dem Löschen eines Shards

Die DetachShard-Methode trennt den angegebenen Shard aus der Shardzuordnung und löscht die Zuordnungen, die dem Shard zugeordnet sind.

Der location Parameter ist der Speicherort des Shards, einschließlich des Servernamens und des Datenbanknamens des abgetrennten Shards.
Der shardMapName Parameter ist der Name der Shardkarte. Dieser ist nur erforderlich, wenn mehrere Shardzuordnungen von demselben Shardzuordnungs-Manager verwaltet werden. Wahlfrei.

Wichtig

Verwenden Sie diese Technik nur, wenn Sie sicher sind, dass der Bereich für die aktualisierte Zuordnung leer ist. Diese Methoden überprüfen keine Daten für den verschobenen Bereich, daher ist es am besten, Überprüfungen in Ihren Code einzuschließen.

Dieses Beispiel entfernt die Shards aus der Shardzuordnung.

rm.DetachShard(s.Location, customerMap);

Die Shardzuordnung entspricht dem Shardspeicherort in der GSM vor dem Löschen des Shards. Da die Shard gelöscht wurde, wird davon ausgegangen, dass dies beabsichtigt war, und der Sharding-Schlüsselbereich wird nicht mehr verwendet. Wenn dies nicht der Fall ist, können Sie die Point-in-Time-Wiederherstellung ausführen, Um den Shard von einem früheren Zeitpunkt wiederherzustellen. (Überprüfen Sie in diesem Fall den folgenden Abschnitt, um Shard-Inkonsistenzen zu erkennen.) Informationen zum Wiederherstellen finden Sie unter Wiederherstellen einer Datenbank aus einer Sicherung in der Azure SQL-Datenbank.

Da davon ausgegangen wird, dass die Datenbanklöschung beabsichtigt war, besteht die endgültige verwaltungstechnische Bereinigungsaktion darin, den Eintrag im Shard-Karten-Manager zu löschen. Dadurch wird verhindert, dass die Anwendung versehentlich Informationen in einen Bereich schreibt, der nicht erwartet wird.

Erkennen von Unterschieden in der Zuordnung

Die DetectMappingDifferences-Methode wählt eine der Shardzuordnungen (entweder lokal oder global) aus, gibt sie als gültige Quelle zurück und stimmt Zuordnungen in beiden Shardzuordnungen (GSM und LSM) darauf ab.

rm.DetectMappingDifferences(location, shardMapName);

Dies location gibt den Servernamen und den Datenbanknamen an.
Der shardMapName Parameter ist der Name der Shardkarte. Dieser ist nur erforderlich, wenn mehrere Shardzuordnungen von demselben Shardzuordnungs-Manager verwaltet werden. Wahlfrei.

Unterschiede in der Zuordnung beheben

Die ResolveMappingDifferences-Methode wählt eine der Shardzuordnungen (entweder lokal oder global) als gültige Quelle aus und stimmt Zuordnungen in beiden Shardzuordnungen (GSM und LSM) darauf ab.

ResolveMappingDifferences (RecoveryToken, MappingDifferenceResolution.KeepShardMapping);

Der RecoveryToken Parameter listet die Unterschiede in den Zuordnungen zwischen dem GSM und dem LSM für die spezifische shard auf.
Mit der MappingDifferenceResolution-Enumeration wird die Methode angegeben, die zum Beheben des Unterschieds zwischen den Shardzuordnungen verwendet werden soll.
MappingDifferenceResolution.KeepShardMapping wird empfohlen, wenn die LSM die korrekte Zuordnung enthält und daher die Zuordnung im Shard verwendet werden sollte. Dies ist in der Regel der Fall, wenn ein Failover vorhanden ist: Der Shard befindet sich jetzt auf einem neuen Server. Da der Shard zuerst aus dem GSM entfernt werden muss (mit der RecoveryManager.DetachShard Methode), ist eine Zuordnung auf dem GSM nicht mehr vorhanden. Aus diesem Grund muss die LSM verwendet werden, um die Shardzuordnung wiederherzustellen.

Anfügen eines Shards an die ShardMap nach dem Wiederherstellen eines Shards

Die AttachShard-Methode fügt den angegebenen Shard an die Shardzuordnung an. Anschließend erkennt es eventuelle Inkonsistenzen in der Shardzuordnung und aktualisiert die Zuordnungen so, dass sie dem Shard zum Zeitpunkt der Wiederherstellung entsprechen. Es wird davon ausgegangen, dass die Datenbank auch umbenannt wird, um den ursprünglichen Datenbanknamen (vor der Wiederherstellung des Shards) wiederzugeben, da bei der Point-in-Time-Wiederherstellung standardmäßig eine neue Datenbank mit angehängtem Zeitstempel verwendet wird.

rm.AttachShard(location, shardMapName)

Der location Parameter ist der Servername und der Datenbankname der angefügten Shards.
Der shardMapName Parameter ist der Name der Shardkarte. Dieser ist nur erforderlich, wenn mehrere Shardzuordnungen von demselben Shardzuordnungs-Manager verwaltet werden. Wahlfrei.

In diesem Beispiel wird der Shardzuordnung ein Shard hinzugefügt, der vor kurzem von einem früheren Zeitpunkt wiederhergestellt wurde. Da der Shard (d.h. die Zuordnung für den Shard in der LSM) wiederhergestellt wurde, ist er möglicherweise inkonsistent mit dem Shard-Eintrag in der GSM. Außerhalb dieses Beispielcodes wurde der Shard wiederhergestellt und auf den ursprünglichen Namen der Datenbank umbenannt. Da sie wiederhergestellt wurde, wird davon ausgegangen, dass die Zuordnung in der LSM die vertrauenswürdige Zuordnung ist.

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

Aktualisieren der Speicherorte der Shards nach einem Geo-Failover (Wiederherstellung) der Shards

Wenn ein Geofailover auftritt, wird die sekundäre Datenbank schreibzugänglich gemacht und wird zur neuen primären Datenbank. Der Name des Servers und möglicherweise die Datenbank (je nach Konfiguration) unterscheiden sich möglicherweise von der ursprünglichen primären. Daher müssen die Zuordnungseinträge für den Shard in der GSM und in der LSM korrigiert werden. Wenn die Datenbank auf einen anderen Namen oder Speicherort oder auf einen früheren Zeitpunkt wiederhergestellt wird, kann dies ebenso zu Inkonsistenzen in den Shardzuordnungen führen. Der Shardzuordnungs-Manager verarbeitet die Verteilung der geöffneten Verbindungen an die richtige Datenbank. Die Verteilung basiert auf den Daten in der Shardzuordnung und auf dem Wert des Shardingschlüssels, an den die Anwendungsanforderung gerichtet ist. Nach einem Geofailover müssen diese Informationen mit dem genauen Servernamen, Dem Datenbanknamen und der Shardzuordnung der wiederhergestellten Datenbank aktualisiert werden.

Bewährte Methoden

Geofailover und -wiederherstellung sind Vorgänge, die in der Regel von einem Cloudadministrator der Anwendung verwaltet werden, der bewusst die Geschäftskontinuitätsfunktionen von Azure SQL-Datenbank einsetzt. Die Planung der Geschäftskontinuität erfordert Prozesse, Verfahren und Maßnahmen, um zu gewährleisten, dass der Geschäftsbetrieb ohne Unterbrechung fortgesetzt werden kann. Die als Element der Klasse RecoveryManager verfügbaren Methoden sollten innerhalb dieses Workflows verwendet werden, um sicherzustellen, dass GSM und LSM auf der Grundlage der durchgeführten Wiederherstellungsaktion auf dem neuesten Stand gehalten werden. Es gibt fünf grundlegende Schritte, um ordnungsgemäß sicherzustellen, dass die GSM und die LSM nach einem Failoverereignis die richtigen Informationen enthalten. Der Anwendungscode zum Ausführen dieser Schritte kann in vorhandene Tools und Workflows integriert werden.

Rufen Sie die RecoveryManager aus dem ShardMapManager ab.
Trennen Sie den alten Shard von der Shardzuordnung.
Fügen Sie den neuen Shard an die Shardzuordnung an, einschließlich des neuen Shardspeicherorts.
Ermitteln Sie Inkonsistenzen in der Zuordnung zwischen GSM und LSM.
Lösen Sie Unterschiede zwischen der GSM und der LSM auf, indem Sie die LSM als vertrauenswürdig einstufen.

In diesem Beispiel werden die folgenden Schritte ausgeführt:

Entfernen von Shards aus der Shardzuordnung, die Shardspeicherorte von vor dem Failover angeben.
Fügt Shards an die Shardmap an, welche die neuen Shard-Standorte widerspiegelt (der Parameter Configuration.SecondaryServer ist der neue Servername, aber derselbe Datenbankname).
Abrufen der Wiederherstellungstoken durch das Erkennen von Zuordnungsunterschieden zwischen der GSM und der LSM für die einzelnen Shards.

Auflösen der Inkonsistenzen durch Verwenden der LSM-Zuordnung als vertrauenswürdige Zuordnung für die einzelnen Shards.

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

Verwenden Sie noch keine elastischen Datenbanktools? Sehen Sie sich unseren Leitfaden zu den ersten Schritten an. Wenden Sie sich bei Fragen auf der Frageseite von Microsoft Q&A für SQL-Datenbank und für Featureanforderungen an uns, fügen Sie neue Ideen hinzu, oder stimmen Sie im SQL-Datenbank-Feedbackforumüber vorhandene Ideen ab.