Cosmos DB - Microsoft.Azure.Documents.AddressResolver.EnsureRoutingMapPresent

Question

在数据迁移过程中，我遇到了一些关于 Cosmos DB 的奇怪问题。迁移包括删除和重新创建我们的生产集合，然后使用 Azure Cosmos DB 迁移工具从我们的开发集合中复制文档。 我想要完全清除生产集合中已有的数据，而不是复制顶部的新文档，所以为了实现这一点，我执行了以下过程......

1. 删除了名为“Production_Products”的生产集合
2. 重新创建了具有相同名称和分区键的生产集合
3. 使用 Azure Cosmos DB 数据迁移工具，我将开发集合中的文档复制到新创建的空生产集合“Production_Products”

4. 迁移完成后，我们测试了网站，但不断收到以下错误...

   Microsoft.Azure.Documents.NotFoundException：在 Microsoft.Azure.Documents.AddressResolver.EnsureRoutingMapPresent

这非常令人困惑，因为我们可以从 Azure 中查询数据没有问题。在多个应用程序重新启动并检查配置后，我们创建了一个新集合“Production_Products_Test”并重复了迁移步骤。

这很好用。当天晚些时候，我们通过使用原始名称“Production_Products”重新创建一个新集合来恢复我们的更改，但失败了。我们不得不恢复使用“_Test”集合。

谁能提供任何关于为什么会发生这种情况的见解？

Answer 1

基于 cmets。

DocumentClient 维护地址缓存，如果您在外部删除并重新创建集合（不是通过 DocumentClient 或至少不是通过该特定 DocumentClient 实例，因为您描述了许多服务），可能出现的问题是地址该实例具有的缓存无效。较新版本的 SDK 包含会做出反应并刷新缓存的修复（请参阅此处的更改日志https://docs.microsoft.com/azure/cosmos-db/sql-api-sdk-dotnet）。

SDK 2.1.3 相当旧（超过 2 年），建议对其进行更新（此时 2.10.3 是最新版本）。

那些缓存失效的原因是当你删除并重新创建时，新的集合有一个不同的ResourceId。

话虽如此，但有一种情况不容易解决，即当您删除并重新创建集合时，您的代码使用的是 ResourceIds（例如，使用 SelfLinks）而不是名称/ids做操作。在这些情况下，如果您正在缓存或持有对先前集合的 ResourceId 的引用，则这些请求将失败。相反，您需要通过UriFactory 使用名称/ID。

通常在这些情况下，了解异常的完整堆栈跟踪（不仅仅是类型的名称）有助于准确了解发生了什么。