你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

恢复容器数据

项目
06/25/2024

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

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

Fluid Framework 会定期在容器中保存数据的快照，该快照汇总了对数据所做的所有更改。在正常加载期间，将检索最新的快照，并且任何后续更改将应用于该状态。

如果最新的快照或后续更改已损坏，Fluid 可能无法正常加载它们。在这种情况下，Fluid 提供了一组 API 来查看存储的快照版本，并在仅查看模式下加载它们，且未应用后续更改。这样，数据就可以提取并选择性地注入到新容器中以恢复协作。

Azure 客户端 API

用于查看和加载容器版本的 API

AzureClient 具有以下支持此方案的方法：

获取容器版本

getContainerVersions(id, options?)

检索可能从中加载的可用版本的列表。

Parameters:

id：容器 ID。这是调用 getContainer时使用的同一 ID。
options?：（可选）要指定的选项对象：
- maxCount：要检索的最大版本数。如果可用版本多于所请求的版本，将检索最新版本。默认：5

Returns: 一个承诺，它解析为表示可用版本的对象的数组（排序最新到最旧）。这些对象具有以下属性：

id：版本 ID。
- 注意：这不同于容器 ID，并专门引用快照版本而不是容器。
date：生成版本时的时间戳。

查看容器版本

viewContainerVersion(id, containerSchema, version, compatibilityMode)

仅加载容器的特定版本以供查看。可以使用从 getContainerVersions 中检索到的任何版本，但为了恢复损坏的数据，建议从最新版本开始，并向后工作以查找最新未更正的版本。

容器以暂停状态加载，这意味着它不会对生成该快照后发生的数据应用后续更改。在此状态下加载时，可以读取容器数据，但不进行编辑。

Parameters:

id：容器 ID。这是调用 getContainer时使用的同一 ID。
containerSchema：容器架构。这是调用 getContainer时使用的同一架构。
version：引用要从中加载的版本的版本对象。可以通过 . 检索 getContainerVersions版本对象。
compatibilityMode：兼容性模式。这是调用 getContainer时使用的同一兼容模式。

Returns: 解析为表示具有单个属性的已加载容器的对象的承诺：

container：容器对象。这与容器对象返回 getContainer的类型相同，但在所选版本之前的状态中暂停。

示例

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

关键观测结果

我们正在创建新容器

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

已拆离新容器

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

恢复后注意事项

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

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

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

通过