Recuperando dados do contêiner

Nesse cenário, exploramos a recuperação de dados. Consideramos que os dados estão corrompidos quando o contêiner atinge um estado inválido em que não pode processar outras ações do usuário. O resultado do estado corrompido é o contêiner sendo fechado inesperadamente. Muitas vezes é um estado transitório e, após a reabertura, o recipiente pode se comportar como esperado. Em uma situação em que um contêiner não carrega mesmo após várias tentativas, oferecemos APIs e fluxos que você pode usar para recuperar seus dados, conforme descrito abaixo.

Como o Fluid Framework e o Azure Fluid Relay salvam o estado

O Fluid Framework salva periodicamente instantâneos dos dados no contêiner, que resumem todas as alterações feitas nos dados até esse ponto. Durante o carregamento normal, o instantâneo mais recente é recuperado e todas as alterações subsequentes são aplicadas sobre esse estado.

Se o instantâneo mais recente ou as alterações subsequentes estiverem corrompidos, o Fluid pode não conseguir carregá-los normalmente. Nesse caso, o Fluid oferece uma coleção de APIs para exibir as versões de snapshot armazenadas e carregá-las em um modo somente visualização sem alterações subsequentes aplicadas. Isso permite que os dados sejam extraídos e, opcionalmente, injetados em um novo contêiner para retomar a colaboração.

APIs de cliente do Azure

APIs para visualizar e carregar versões de contêiner

O AzureClient tem os seguintes métodos para dar suporte a esse cenário:

Obter versões de contêiner

getContainerVersions(id, options?)

Recupere uma lista de versões disponíveis que podem ser carregadas.

Parameters:

• id: O ID do contêiner. Este é o mesmo ID usado ao chamar getContainero .
• options?: Opcionalmente, um objeto options para especificar:
  • maxCount: O número máximo de versões a recuperar. Se houver mais versões disponíveis do que o solicitado, as versões mais recentes serão recuperadas. Padrão: 5

Returns: Uma promessa que resolve para uma matriz de objetos que representam as versões disponíveis (classificadas da mais recente para a mais antiga). Os objetos têm as seguintes propriedades:

• id: O ID da versão.
  • Nota: Isso é diferente do ID do contêiner e faz referência especificamente a uma versão de instantâneo em vez do contêiner.
• date: O carimbo de data/hora quando a versão foi gerada.

Ver versão do contêiner

viewContainerVersion(id, containerSchema, version, compatibilityMode)

Carregue uma versão específica de um contêiner apenas para visualização. Qualquer versão recuperada pode getContainerVersions ser usada, mas para fins de recuperação de dados corrompidos, recomenda-se começar com a versão mais recente e trabalhar para trás para encontrar a versão não corrompida mais recente.

O contêiner é carregado em um estado pausado, o que significa que ele não aplicará as alterações subsequentes aos dados que aconteceram após a geração desse instantâneo. Quando carregados nesse estado, os dados do contêiner podem ser lidos, mas não editados.

Parameters:

• id: O ID do contêiner. Este é o mesmo ID usado ao chamar getContainero .
• containerSchema: O esquema de contêiner. Este é o mesmo esquema usado ao chamar getContainero .
• version: O objeto version que faz referência à versão a partir da qual carregar. O objeto version pode ser recuperado via getContainerVersions.
• compatibilityMode: O modo de compatibilidade. Este é o mesmo modo de compatibilidade usado ao chamar getContainero .

Returns: Uma promessa que resolve para um objeto que representa o contêiner carregado com uma única propriedade:

• container: O objeto container. Este é o mesmo tipo de objeto que o objeto contêiner retornado pelo getContainer, mas é pausado em seu estado anterior da versão selecionada.

Exemplo

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

Observações principais:

Estamos a criar um novo Contentor

Não estamos recuperando (revertendo) o contêiner existente. copyContainer nos dará uma nova instância, com os dados sendo copiados do contêiner original. Nesse processo, o contêiner antigo não é excluído.

Novo recipiente é separado

O novo contêiner está inicialmente no detached estado. Podemos continuar a trabalhar com contentor separado, ou anexar imediatamente. Depois de ligar attach , obteremos de volta o ID de contêiner exclusivo, representando a instância recém-criada.

Considerações pós-recuperação

Quando se trata de criar casos de uso em cenários de pós-recuperação, aqui estão algumas considerações sobre o que o aplicativo pode querer fazer para que seus colaboradores remotos trabalhem no mesmo contêiner novamente.

Se você estiver modelando os dados do aplicativo usando apenas contêineres fluidos, o "link" de comunicação será efetivamente quebrado quando o contêiner estiver corrompido. Um exemplo semelhante no mundo real pode ser uma chamada de vídeo em que o autor original compartilhou o link com os participantes e esse link não está mais funcionando. Com essa perspetiva em mente, uma opção é limitar as permissões de recuperação ao autor original e permitir que ele compartilhe o novo link de contêiner da mesma forma que compartilhou o link original, depois de recuperar a cópia do contêiner original.

Como alternativa, se você estiver usando a estrutura fluida apenas para dados transitórios, sempre poderá usar seus próprios dados de origem da verdade e serviços de suporte para gerenciar fluxos de trabalho de recuperação mais autônomos. Por exemplo, vários clientes podem iniciar o processo de recuperação até que seu aplicativo tenha uma primeira cópia recuperada. Seu aplicativo pode então notificar todos os clientes participantes para fazer a transição para um novo contêiner. Isso pode ser útil, pois qualquer cliente atualmente ativo pode desbloquear o grupo participante para prosseguir com a colaboração. Uma consideração aqui são os custos incorridos com o despedimento.