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 den Status regelmäßig – dies wird als Zusammenfassung bezeichnet. Es ist nicht erforderlich, dass der Benutzer ausdrücklich eine Sicherungsaktion initiiert. Dieser Workflow wird jede (1) Minute ausgeführt, wenn keine Benutzeraktivität erfolgt ist oder früher, wenn mehr als 1.000 ausstehende Vorgänge vorliegen. Jeder ausstehende Vorgang ist gleichbedeutend mit etwa einer einzelnen Benutzeraktion (Auswählen, Texteingabe usw.), die noch nicht zusammengefasst wurde.

Azure-Client-APIs

Wir haben AzureClient die folgenden Methoden hinzugefügt, mit denen Entwickler Daten aus beschädigten Containern wiederherstellen können.

getContainerVersions(ID, options)

getContainerVersions ermöglicht es Entwicklern, die zuvor generierten Versionen des Containers anzuzeigen.

copyContainer(ID, containerSchema)

copyContainer ermöglicht es Entwicklern, einen neuen getrennten Container aus einer bestimmten Version eines anderen Containers zu generieren.

Beispiel für einen Wiederherstellungsflow

async function recoverDoc(
    client: AzureClient,
    orgContainerId: string,
    containerScema: ContainerSchema,
): Promise<string> {
    /* Collect doc versions */
    let versions: AzureContainerVersion[] = [];
    try {
        versions = await client.getContainerVersions(orgContainerId);
    } catch (e) {
        return Promise.reject(new Error("Unable to get container versions."));
    }

    for (const version of versions) {
        /* Versions are returned in chronological order.
        Attempt to copy doc from next available version */
        try {
            const { container: newContainer } = await client.copyContainer(
                orgContainerId,
                containerSchema,
                version,
            );
            return await newContainer.attach();
        } catch (e) {
            // Error. Keep going.
        }
    }

    return Promise.reject(new Error("Could not recreate document"));
}

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.