Ripristino dei dati del contenitore

In questo scenario si esplora il ripristino dei dati. Si considera che i dati siano danneggiati quando il contenitore raggiunge uno stato non valido in cui non è possibile elaborare altre azioni utente. Il risultato dello stato danneggiato è la chiusura imprevista del contenitore. Spesso si tratta di uno stato temporaneo e, al momento della riapertura, il contenitore può comportarsi come previsto. In una situazione in cui un contenitore non viene caricato anche dopo più tentativi, vengono offerte API e flussi che è possibile usare per recuperare i dati, come descritto di seguito.

Modalità di salvataggio di Fluid Framework e Inoltro fluido di Azure

Fluid Framework salva periodicamente gli snapshot dei dati nel contenitore, che riepilogano tutte le modifiche apportate ai dati fino a quel punto. Durante il normale caricamento viene recuperato lo snapshot più recente e tutte le modifiche successive vengono applicate su tale stato.

Se lo snapshot più recente o le modifiche successive sono danneggiate, Fluid potrebbe non essere in grado di caricarle normalmente. In questo caso Fluid offre una raccolta di API per visualizzare le versioni di snapshot archiviate e caricarle in una modalità di sola visualizzazione senza modifiche successive applicate. In questo modo i dati possono essere estratti e inseriti facoltativamente in un nuovo contenitore per riprendere la collaborazione.

API client di Azure

API per la visualizzazione e il caricamento delle versioni dei contenitori

AzureClient include i metodi seguenti per supportare questo scenario:

Ottenere le versioni dei contenitori

getContainerVersions(id, options?)

Recuperare un elenco di versioni disponibili da cui è possibile caricare.

Parameters:

• id: ID contenitore. Si tratta dello stesso ID usato per chiamare getContainer.
• options?: facoltativamente, un oggetto opzioni da specificare:
  • maxCount: numero massimo di versioni da recuperare. Se sono disponibili più versioni di quelle richieste, verranno recuperate le versioni più recenti. Impostazione predefinita: 5

Returns: Promessa che si risolve in una matrice di oggetti che rappresentano le versioni disponibili (ordinate più recenti al meno recente). Gli oggetti hanno le proprietà seguenti:

• id: ID versione.
  • Nota: è diverso dall'ID contenitore e fa riferimento in modo specifico a una versione dello snapshot anziché al contenitore.
• date: timestamp in cui è stata generata la versione.

Visualizzare la versione dei contenitori

viewContainerVersion(id, containerSchema, version, compatibilityMode)

Caricare una versione specifica di un contenitore solo per la visualizzazione. Qualsiasi versione recuperata da getContainerVersions può essere usata, ma allo scopo di recuperare i dati danneggiati è consigliabile iniziare con la versione più recente e lavorare indietro per trovare la versione non corretta più recente.

Il contenitore viene caricato in uno stato sospeso, ovvero non applicherà le modifiche successive ai dati che si sono verificati dopo la generazione di tale snapshot. Se caricati in questo stato, i dati del contenitore possono essere letti, ma non modificati.

Parameters:

• id: ID contenitore. Si tratta dello stesso ID usato per chiamare getContainer.
• containerSchema: schema del contenitore. Questo è lo stesso schema usato per chiamare getContainer.
• version: oggetto versione che fa riferimento alla versione da cui caricare. L'oggetto versione può essere recuperato tramite getContainerVersions.
• compatibilityMode: modalità di compatibilità. Questa è la stessa modalità di compatibilità usata per chiamare getContainer.

Returns: Promessa che si risolve in un oggetto che rappresenta il contenitore caricato con una singola proprietà:

• container: oggetto contenitore. Si tratta dello stesso tipo di oggetto restituito dall'oggetto contenitore restituito da getContainer, ma viene sospeso nello stato precedente dalla versione selezionata.

Esempio

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

Osservazioni chiave

Si sta creando un nuovo contenitore

Non viene ripristinato (rollback) del contenitore esistente. copyContainer darà una nuova istanza, con i dati copiati dal contenitore originale. In questo processo, il contenitore precedente non viene eliminato.

Il nuovo contenitore viene scollegato

Il nuovo contenitore è inizialmente in detached stato. È possibile continuare a usare un contenitore scollegato o collegarsi immediatamente. Dopo aver chiamato attach verrà restituito l'ID contenitore univoco, che rappresenta l'istanza appena creata.

Considerazioni successive al ripristino

Quando si tratta di creare casi d'uso relativi agli scenari di post-ripristino, di seguito sono riportate alcune considerazioni su ciò che l'applicazione potrebbe voler fare per ottenere i collaboratori remoti che lavorano di nuovo sullo stesso contenitore.

Se si modellano i dati dell'applicazione esclusivamente usando contenitori fluidi, la comunicazione "link" viene interrotta in modo efficace quando il contenitore è danneggiato. Un esempio reale simile può essere una videochiamata in cui l'autore originale ha condiviso il collegamento con i partecipanti e tale collegamento non funziona più. Tenendo presente questa prospettiva, un'opzione consiste nel limitare le autorizzazioni di ripristino all'autore originale e consentire loro di condividere il nuovo collegamento al contenitore nello stesso modo in cui hanno condiviso il collegamento originale, dopo aver ripristinato la copia del contenitore originale.

In alternativa, se si usa un framework fluido solo per i dati temporanei, è sempre possibile usare i propri dati di origine e i servizi di supporto per gestire flussi di lavoro di ripristino più autonomi. Ad esempio, più client possono avviare il processo di ripristino fino a quando l'app non ha una prima copia ripristinata. L'app può quindi notificare a tutti i client partecipanti di passare a un nuovo contenitore. Ciò può essere utile perché qualsiasi client attualmente attivo può sbloccare il gruppo partecipante per procedere con la collaborazione. Una considerazione è costituita dai costi sostenuti per la ridondanza.