Recuperar dados de contêiner
Nesse cenário, exploramos a recuperação de dados. Consideramos que os dados serã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. Geralmente, é um estado transitório e, após a reabertura, o contêiner pode se comportar conforme o esperado. Em uma situação em que um contêiner não é carregado mesmo após várias tentativas, oferecemos as APIs e os 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 visualizar 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: A ID do contêiner. Essa é a mesma ID usada ao chamargetContainero .options?: Opcionalmente, um objeto de opções para especificar:maxCount: o número máximo de versões a serem recuperadas. Se houver mais versões disponíveis do que as solicitadas, as versões mais recentes serão recuperadas. Padrão: 5
Returns: Uma promessa que é resolvida 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: A ID da versão.- Observação: isso é diferente do ID do contêiner e faz referência especificamente a uma versão de snapshot em vez do contêiner.
date: O carimbo de data/hora em que a versão foi gerada.
Exibir a versão de contêiner
viewContainerVersion(id, containerSchema, version, compatibilityMode)
Carregue uma versão específica de um contêiner somente para exibição. Qualquer versão recuperada pode getContainerVersions ser usada, mas para fins de recuperação de dados corrompidos, é recomendável começar com a versão mais recente e trabalhar de trás para frente 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 ocorreram 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: A ID do contêiner. Essa é a mesma ID usada ao chamargetContainero .containerSchema: O esquema de contêiner. Esse é o mesmo esquema usado ao chamargetContainer.version: O objeto de versão que faz referência à versão a ser carregada. O objeto de versão pode ser recuperado por meio degetContainerVersions.compatibilityMode: O modo de compatibilidade. Esse é o mesmo modo de compatibilidade usado ao chamargetContainero .
Returns: Uma promessa que é resolvida para um objeto que representa o contêiner carregado com uma única propriedade:
container: O objeto contêiner. Esse é o mesmo tipo de objeto que o objeto contêiner retornado porgetContainer, mas é pausado em seu estado anterior a partir 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();
Principais observações
Estamos criando um novo Contêiner
Não estamos recuperando (revertendo) 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 contêiner é desanexado
O novo contêiner está inicialmente no estado detached. Podemos continuar trabalhando com contêiner desanexado ou anexar imediatamente. Depois de chamar attach, recuperaremos a ID de contêiner exclusiva, representando a instância recém-criada.
Considerações pós-recuperação
Quando se trata de criar casos de uso em torno de cenários pós-recuperação, veja algumas considerações sobre o que o aplicativo pode fazer para que os 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 interrompido quando o contêiner estiver corrompido. Um exemplo semelhante do mundo real pode ser uma videochamada em que o autor original compartilhou o link com os participantes e esse link não está mais funcionando. Com essa perspectiva em mente, uma opção é limitar as permissões de recuperação ao autor original e permitir que elas compartilhem um novo link de contêiner da mesma forma que compartilharam o link original, depois de recuperar a cópia do contêiner original.
Como alternativa, se você estiver usando uma estrutura fluida apenas para dados transitórios, sempre poderá usar seus próprios dados de fonte de 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 o aplicativo tenha uma primeira cópia recuperada. Depois, o aplicativo pode notificar todos os clientes participantes a fazerem a transição para um novo contêiner. Isso pode ser útil, pois qualquer cliente ativo no momento pode desbloquear o grupo participante para continuar a colaboração. Uma consideração aqui são os custos gerados pela redundância.