恢复容器数据

  • 项目

在此场景中，我们探索数据恢复。 当容器达到无法进一步处理用户操作的无效状态时，我们认为数据会损坏。 损坏状态的结果是容器意外关闭。 通常这是暂时性状态，重新打开后，容器的行为可能会恢复正常。 如果容器在多次重试后仍无法加载，你可以使用我们提供的用于恢复数据的 API 和流，如下所示。

Fluid Framework 和 Azure Fluid Relay 如何保存状态

Fluid Framework 会定期保存状态（称为摘要），无需用户启动的任何显式备份操作。 如果没有用户活动，则每分钟执行一次此工作流；如果存在 1000 个以上的挂起操作，则执行此工作流的频率会更高。 每个挂起的操作大致转换为一个尚未汇总的用户操作（选择、文本输入等）。

Azure 客户端 API

我们向 AzureClient 添加了以下方法，使开发人员能够从损坏的容器中恢复数据。

getContainerVersions(ID, options)

使用 getContainerVersions，开发人员可以查看以前生成的容器版本。

copyContainer(ID, containerSchema)

使用 copyContainer，开发人员可以从另一个容器的特定版本生成新的已拆离容器。

示例恢复流


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

关键观测结果

我们正在创建新容器

我们不会恢复（回滚）现有容器。 copyContainer 将为我们提供新实例，新实例的数据从原始容器复制。 在此过程中，不会删除旧容器。

已拆离新容器

新容器最初处于“detached”状态。 我们可以继续使用拆离的容器，也可以立即附加它。 调用 attach 后，我们将获得唯一的容器 ID，它表示新创建的实例。

恢复后注意事项

当涉及到围绕恢复后场景构建用例时，关于应用程序可能需要做些什么来让远程协作者再次在同一个容器上正常工作，这里有几个注意事项。

如果要仅使用流体容器对应用程序数据进行建模，则当容器损坏时，通信“链接”实际上就中断了。 类似的真实示例可能是视频通话，其中原作者与参与者共享了链接，并且该链接不再有效。 考虑到这一观点，一种选择是将恢复权限限制为原始作者，并让他们在恢复原始容器的副本后，以与共享原始链接相同的方式共享新的容器链接。

或者，如果你只对暂时性数据使用流体框架，则始终可使用自己的真实数据源和支持服务来管理更自主的恢复工作流。 例如，多个客户端可能会启动恢复过程，直到应用有了第一个恢复的副本。 然后，应用可以通知所有参与的客户端转换到新容器。 这很有用，因为任何当前活动的客户端都可以解除对参与组的阻止以继续进行协作。 这里需要考虑的一个因素是冗余所产生的成本。