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

A estrutura fluida salva periodicamente o estado, chamado resumo, sem qualquer ação de backup explícita iniciada pelo usuário. Esse fluxo de trabalho ocorre a cada um (1) minuto se não houver atividade do usuário, ou mais cedo se houver mais de 1000 operações pendentes presentes. Cada operação pendente se traduz aproximadamente em uma ação individual do usuário (selecionar, inserir texto, etc.) que ainda não foi resumida.

APIs de cliente do Azure

Adicionamos os seguintes métodos ao AzureClient que permitem que os desenvolvedores recuperem dados de contêineres corrompidos.

getContainerVersions(ID, options)

getContainerVersions permite que os desenvolvedores visualizem as versões geradas anteriormente do contêiner.

copyContainer(ID, containerSchema)

copyContainer permite que os desenvolvedores gerem um novo contêiner separado de uma versão específica de outro contêiner.

Exemplo de fluxo de recuperação

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"));
}

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.