Wiederherstellen von Containerdaten

In diesem Szenario untersuchen wir die Datenwiederherstellung. Daten gelten als beschädigt, wenn der Container einen ungültigen Status erreicht, in dem keine weiteren Benutzeraktionen verarbeitet werden können. Bei einem beschädigten Status wird der Container unerwartet geschlossen. Häufig handelt es sich um einen vorübergehenden Status, und beim erneuten Öffnen verhält sich der Container möglicherweise wie erwartet. In einer Situation, in der ein Container auch nach mehreren Wiederholungen nicht geladen werden kann, bieten wir APIs und Flows an, mit denen Sie Ihre Daten wie unten beschrieben wiederherstellen können.

So speichern das Fluid Framework und Azure Fluid Relay den Status

Fluid Framework speichert in regelmäßigen Abständen Momentaufnahmen der Daten im Container, die alle an den Daten vorgenommenen Änderungen bis zu diesem Punkt zusammenfassen. Beim normalen Laden wird die neueste Momentaufnahme abgerufen, und alle nachfolgenden Änderungen werden oben in diesem Zustand angewendet.

Wenn die neuesten Momentaufnahmen oder nachfolgende Änderungen beschädigt sind, kann Fluid sie möglicherweise nicht normal laden. In diesem Fall bietet Fluid eine Sammlung von APIs zum Anzeigen der gespeicherten Momentaufnahmenversionen und zum Laden in einem schreibgeschützten Modus ohne nachfolgende Änderungen. Dadurch können die Daten extrahiert und optional in einen neuen Container eingefügt werden, um die Zusammenarbeit fortzusetzen.

Azure-Client-APIs

APIs zum Anzeigen und Laden von Containerversionen

Der AzureClient verfügt über die folgenden Methoden zur Unterstützung dieses Szenarios:

Abrufen von Containerversionen

getContainerVersions(id, options?)

Dient zum Abrufen einer Liste der verfügbaren Versionen, aus denen möglicherweise geladen wird.

Parameters:

• id: Die Container-ID. Dies ist dieselbe ID, die beim Aufrufen getContainerverwendet wird.
• options?: Optional kann ein Optionsobjekt angegeben werden:
  • maxCount: Die maximale Anzahl der abzurufenden Versionen. Wenn mehr Versionen verfügbar sind als angefordert, werden die neuesten Versionen abgerufen. Standard: 5

Returns: Eine Zusage, die in ein Array von Objekten aufgelöst wird, die verfügbare Versionen darstellen (nach dem neuesten zum ältesten sortiert). Die Objekte weisen die folgenden Eigenschaften auf:

• id: Die Versions-ID.
  • Hinweis: Dies unterscheidet sich von der Container-ID und verweist speziell auf eine Momentaufnahmeversion und nicht auf den Container.
• date: Der Zeitstempel, zu dem die Version generiert wurde.

Anzeigen der Containerversion

viewContainerVersion(id, containerSchema, version, compatibilityMode)

Laden Sie eine bestimmte Version eines Containers nur zum Anzeigen. Jede version, aus getContainerVersions der abgerufen wird, kann verwendet werden, aber zum Zweck der Wiederherstellung beschädigter Daten wird empfohlen, mit der aktuellsten Version zu beginnen und rückwärts zu arbeiten, um die neueste nicht beschädigte Version zu finden.

Der Container wird in einen angehaltenen Zustand geladen, was bedeutet, dass die nachfolgenden Änderungen nicht auf die Daten angewendet werden, die nach der Generierung dieser Momentaufnahme aufgetreten sind. Beim Laden in diesem Zustand werden die Containerdaten möglicherweise gelesen, aber nicht bearbeitet.

Parameters:

• id: Die Container-ID. Dies ist dieselbe ID, die beim Aufrufen getContainerverwendet wird.
• containerSchema: Das Containerschema. Dies ist dasselbe Schema, das beim Aufrufen getContainerverwendet wird.
• version: Das Versionsobjekt, das auf die version verweist, aus der geladen werden soll. Das Versionsobjekt kann über getContainerVersions.
• compatibilityMode: Der Kompatibilitätsmodus. Dies ist derselbe Kompatibilitätsmodus, der beim Aufrufen getContainerverwendet wird.

Returns: Eine Zusage, die in ein Objekt aufgelöst wird, das den geladenen Container mit einer einzelnen Eigenschaft darstellt:

• container: Das Containerobjekt. Dies ist derselbe Objekttyp wie das containerobjekt, das von getContainerder ausgewählten Version zurückgegeben wird, aber in seinem vorherigen Zustand angehalten wird.

Beispiel

const azureClient = new AzureClient(/* ... */);
const versions = await azureClient.getContainerVersions(id);
// Since the versions are sorted in order from newest to oldest, versions[0] will attempt to load the most recent version.
// If the most recent version is corrupted, we could try again with versions[1] and so on to find the most-recent uncorrupted version.
const { container } = await azureClient.viewContainerVersion(id, containerSchema, versions[0], "2");

// We can now start reading the data from the container.
const someData = container.initialObjects.someSharedMap.get("hello");

// With the data extracted, we can inject it into a new uncorrupted container and attach it to start collaborating again.
const { container: newContainer } = await azureClient.createContainer(containerSchema, "2");
newContainer.initialObjects.someSharedMap.set("hello", someData);
const newId = await newContainer.attach();

Wichtige Beobachtungen

Wir erstellen einen neuen Container

Der vorhandene Container wird nicht wiederhergestellt (kein Rollback). copyContainer stellt eine neue Instanz bereit, wobei Daten aus dem ursprünglichen Container kopiert werden. In diesem Prozess wird der alte Container nicht gelöscht.

Neuer Container ist getrennt

Der neue Container befindet sich zunächst im Status detached. Wir können weiterhin mit getrennten Containern arbeiten oder sie sofort anfügen. Nach dem Aufrufen von attach wird eine eindeutige Container-ID zurückgegeben, die die neu erstellte Instanz darstellt.

Überlegungen für nach der Wiederherstellung

Wenn es um das Erstellen von Anwendungsfällen für Szenarien nach einer Wiederherstellung geht, finden Sie hier einige Überlegungen dazu, was welche Anwendung unternehmen könnte, um seine Remotemitarbeiter wieder zur Arbeit am selben Container zu bewegen.

Wenn Sie Ihre Anwendungsdaten ausschließlich mithilfe von fluiden Containern modellieren, wird die Kommunikationsverknüpfung effektiv unterbrochen, wenn der Container beschädigt ist. Ein ähnliches Beispiel für die Praxis kann ein Videoanruf sein, bei dem der ursprüngliche Autor den Link für Teilnehmer freigegeben hat und dieser Link nicht mehr funktioniert. Mit dieser Perspektive im Hinterkopf besteht eine Option darin, die Wiederherstellungsberechtigungen auf den ursprünglichen Autor zu beschränken und diesen den Link auf dieselbe Weise freigeben zu lassen, wie er den ursprünglichen Link freigegeben hatte, nachdem die Kopie des ursprünglichen Containers wiederhergestellt wurde.

Alternativ können Sie, wenn Sie dynamisches Framework nur für vorübergehende Daten verwenden, ihre eigenen Datenquellendaten und unterstützenden Dienste verwenden, um autonomere Wiederherstellungsworkflows zu verwalten. Beispielsweise können mehrere Clients den Wiederherstellungsvorgang starten, bis Ihre App über eine erste wiederhergestellte Kopie verfügt. Ihre App kann dann alle teilnehmenden Clients benachrichtigen, damit sie zu einem neuen Container wechseln. Dies kann nützlich sein, da jeder derzeit aktive Client die Blockade der teilnehmenden Gruppe aufheben kann, um mit der Zusammenarbeit fortzufahren. Ein Aspekt hierbei sind die entstandenen Kosten der Redundanz.