Containergegevens herstellen
In dit scenario verkennen we gegevensherstel. We beschouwen gegevens als beschadigd wanneer de container een ongeldige status bereikt, waarbij verdere gebruikersacties niet kunnen worden verwerkt. Het resultaat van beschadigde status is dat de container onverwacht wordt gesloten. Vaak is deze tijdelijke status en bij het opnieuw openen kan de container zich gedragen zoals verwacht. In een situatie waarin een container niet kan worden geladen, zelfs na meerdere nieuwe pogingen, bieden we API's en stromen die u kunt gebruiken om uw gegevens te herstellen, zoals hieronder wordt beschreven.
De opslagstatus van Vloeiend Framework en Azure Fluid Relay
Vloeiend Framework slaat periodiek momentopnamen van de gegevens in de container op, waarin alle wijzigingen in de gegevens tot dat moment worden samengevat. Tijdens het normaal laden wordt de meest recente momentopname opgehaald en worden eventuele volgende wijzigingen boven op die status toegepast.
Als de meest recente momentopname of volgende wijzigingen beschadigd zijn, kan Fluid deze mogelijk niet normaal laden. In dit geval biedt Fluid een verzameling API's om de opgeslagen momentopnameversies weer te geven en te laden in een modus die alleen-weergeven is, zonder dat daarop volgende wijzigingen zijn toegepast. Hierdoor kunnen de gegevens worden geëxtraheerd en eventueel worden geïnjecteerd in een nieuwe container om de samenwerking te hervatten.
Azure-client-API's
API's voor het weergeven en laden van containerversies
De AzureClient heeft de volgende methoden om dit scenario te ondersteunen:
Containerversies ophalen
getContainerVersions(id, options?)
Haal een lijst met beschikbare versies op waaruit mogelijk wordt geladen.
Parameters:
id
: de container-id. Dit is dezelfde id die wordt gebruikt bij het aanroepengetContainer
.options?
: Optioneel een optiesobject om op te geven:maxCount
: het maximum aantal versies dat moet worden opgehaald. Als er meer versies beschikbaar zijn dan aangevraagd, worden de nieuwste versies opgehaald. Standaard: 5
Returns:
Een belofte die wordt omgezet in een matrix met objecten die beschikbare versies vertegenwoordigen (gesorteerd nieuwste naar oudste). De objecten hebben de volgende eigenschappen:
id
: de versie-id.- Opmerking: dit verschilt van de container-id en verwijst specifiek naar een momentopnameversie in plaats van de container.
date
: de tijdstempel waarop de versie is gegenereerd.
Containerversie weergeven
viewContainerVersion(id, containerSchema, version, compatibilityMode)
Laad een specifieke versie van een container alleen voor weergave. Elke versie die wordt opgehaald uit getContainerVersions
kan worden gebruikt, maar voor het herstellen van beschadigde gegevens is het raadzaam om te beginnen met de meest recente versie en achterwaarts te werken om de meest recente niet-beschadigde versie te vinden.
De container wordt in een onderbroken status geladen, wat betekent dat de volgende wijzigingen niet worden toegepast op de gegevens die zijn aangebracht na het genereren van die momentopname. Wanneer deze status is geladen, worden de containergegevens mogelijk gelezen, maar niet bewerkt.
Parameters:
id
: de container-id. Dit is dezelfde id die wordt gebruikt bij het aanroepengetContainer
.containerSchema
: het containerschema. Dit is hetzelfde schema dat wordt gebruikt bij het aanroepengetContainer
.version
: Het versieobject waarnaar wordt verwezen naar de versie waaruit moet worden geladen. Het versieobject kan worden opgehaald viagetContainerVersions
.compatibilityMode
: de compatibiliteitsmodus. Dit is dezelfde compatibiliteitsmodus die wordt gebruikt bij het aanroepengetContainer
.
Returns:
Een belofte die wordt omgezet in een object dat de geladen container vertegenwoordigt met één eigenschap:
container
: Het containerobject. Dit is hetzelfde type object als het containerobject dat wordt geretourneerd doorgetContainer
, maar wordt onderbroken in de vorige status van de geselecteerde versie.
Opmerking
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();
Belangrijke waarnemingen
Er wordt een nieuwe container gemaakt
Bestaande container wordt niet hersteld (terugdraaien). copyContainer
geeft ons een nieuw exemplaar, waarbij gegevens worden gekopieerd uit de oorspronkelijke container. In dit proces wordt de oude container niet verwijderd.
Nieuwe container is losgekoppeld
Nieuwe container heeft in eerste instantie de detached
status. We kunnen blijven werken met een losgekoppelde container of direct bijvoegen. Na het aanroepen attach
krijgen we een unieke container-id terug, die het zojuist gemaakte exemplaar vertegenwoordigt.
Overwegingen na herstel
Als het gaat om het bouwen van use cases rond scenario's na herstel, zijn hier enkele overwegingen over wat de toepassing kan doen om de externe medewerkers weer aan dezelfde container te laten werken.
Als u uw toepassingsgegevens alleen modelleert met behulp van vloeistofcontainers, wordt de communicatiekoppeling effectief verbroken wanneer de container beschadigd is. Een vergelijkbaar praktijkvoorbeeld kan een videogesprek zijn waarbij de oorspronkelijke auteur de koppeling met deelnemers heeft gedeeld en die koppeling niet meer werkt. Met dit perspectief in gedachten, is één optie om herstelmachtigingen te beperken tot de oorspronkelijke auteur en hen nieuwe containerkoppeling op dezelfde manier te laten delen als ze de oorspronkelijke koppeling hebben gedeeld, nadat de kopie van de oorspronkelijke container is hersteld.
Als u een vloeiend framework gebruikt voor alleen tijdelijke gegevens, kunt u ook altijd uw eigen bron-of-waarheidsgegevens en ondersteunende services gebruiken om meer autonome herstelwerkstromen te beheren. Meerdere clients kunnen bijvoorbeeld het herstelproces starten totdat uw app een eerste herstelde kopie heeft. Uw app kan vervolgens alle deelnemende clients op de hoogte stellen van de overgang naar een nieuwe container. Dit kan handig zijn omdat elke actieve client de blokkering van de deelnemende groep kan opheffen om door te gaan met samenwerking. Een overweging hier is de gemaakte kosten van redundantie.
Feedback
https://aka.ms/ContentUserFeedback.
Binnenkort beschikbaar: In de loop van 2024 zullen we GitHub-problemen geleidelijk uitfaseren als het feedbackmechanisme voor inhoud en deze vervangen door een nieuw feedbacksysteem. Zie voor meer informatie:Feedback verzenden en weergeven voor