问题标签 [azure-cosmosdb-changefeed]

在将 cosmos db 重新部署到不同的服务中后，我们遇到了一个奇怪的问题，即更改提要订阅者没有获取新记录。我的假设是，当饲料停止时，一旦容器再次可用，它就会从停止的地方重新开始？

很想知道是否有其他人以前见过这种行为，或者它是否可能与提要的配置有关？

添加一些上下文手动删除和重新创建容器似乎可以解决问题，所以它似乎与部署相关？

这就是我们的更改提要配置的样子。

使用 CosmosDb 触发器函数绑定来处理更改提要，我是否需要处理多个函数可以同时运行、处理更改提要的不同部分的可能性？

如果不是，我是否认为这意味着存在潜在的性能瓶颈？（因为数据可能被多个实例摄取，比单个实例处理提要的速度更快）。

我有一个 Azure 函数，它会从 CosmosDB 触发 Change Feed，然后将其文档 ETL 到 MS SQL。但是，当服务器（CosmosDB 或 Azure Function 主机）有某种压力时，提要会延迟几秒到几分钟甚至丢失。目前我有解决方法来防止数据工厂丢失并每天重新同步它。

现在我想实施测量来监控，例如延迟时间、成功或失败指出并确定我是否应该扩大 DTU 或服务于分析的东西。我无法查询所有 Cosmos 和 SQL 以在它们之间进行比较，尽管这是通过简单查询计数来检测丢失的最后一种方法。

这可能吗？

我的 Cosmos 数据库中有一个集合，我想观察它的变化。我有很多文件（官方和非官方）解释如何做到这一点。但有一件事我无法以可靠的方式工作：当我没有任何共同的实例名称参考时，如何接收对多个实例的相同更改？

我这是什么意思？好吧，我在 Kubernetes 集群 (AKS) 中运行我的工作负载。我在集群中有可变数量的实例应该观察我的集合。为了使更改源正常工作，我必须为每个实例设置一个唯一的实例名称。我唯一的候选者是 pod 名称。它通常以<deployment-name>-<random string>. 例如pod-5f597c9c56-lxw5b。

如果我使用 pod 名称作为实例名称，所有实例都不会收到相同的更改（这是我的要求），只有一个实例会收到更改（请参阅https://docs.microsoft.com/en-us/azure/ cosmos-db/change-feed-processor#dynamic-scaling）。我可以做的是使用 pod 名称作为提要名称，然后所有实例都会得到相同的更改。这就是我害怕在某个时候会咬我的东西；当窥视租赁容器时，我可以看到每个提要名称的一组文档。随着 pod 名称的出现和消失（名称的随机字符串部分），我担心容器会随着时间的推移而增长，从而产生一堆垃圾。我知道 Cosmos 可以处理巨大的工作量，但你知道，我喜欢保持整洁。

我怎样才能保持这东西干净整洁？我真的不想发明（或为此重用！）我的实例之间的一些协议来投票选择哪个实例从有限的名称集中获得哪个名称。

一个“简单”的解决方案是构建我自己的实例名称，如果 AKS 或 Kubernetes 为我的 pod 保存某种“索引”。我知道有状态集给了我这个，但我不想使用有状态集，因为 pod 本身并不是真正有状态的（除了这个特定方面！）。

运行我的 azure function app 应用程序时出现以下错误：

[7/15/2020 8:26:08 AM] 函数“NotificationChangeFeed”的侦听器无法启动。[7/15/2020 8:26:08 AM] 函数“NotificationChangeFeed”的侦听器无法启动。Microsoft.Azure.DocumentDB.Core：对象引用未设置为对象的实例。

错误截图：

这是我的更改提要触发器 Azure 函数：

local.settings.json：

After going through Cosmos db documentation I am a bit confused about the change feed processor library.

1. Lease document exists for each physical partition or logical partition?
2. If I only have one host with multiple logical partition and a single physical partition. Will the change feed processor utilize multiple threads for each logical partition. I have cosmos change feed processor library implemented like this.

My assumption is due to Scheduler.elastic a new thread can be utilized per logical partition basis.

我无法在本地运行 Cosmos DB Change Feed Trigger 功能。

Cosmos DB 更改源触发 Azure 函数：

local.settings.json

当我按 F5 时，它卡在控制台窗口中。（如下面的屏幕截图所示）

也不能调用 http 触发函数。调用时出现以下错误：

错误：连接 ECONNREFUSED 127.0.0.1:7071

有什么想法吗？

出于合规性原因，我需要捕获所有数据库更改。我知道Change Feed存储这些信息（我正在等待完全保真以捕获删除）。目前，我一直在Change Feed通过Function触发器读取并将更改复制到Azure Table.

这是矫枉过正吗？Change Feed只要 Cosmos 数据库处于活动状态，是否会保留所有活动日志，或者在特定保留期后自动删除更改？

我正在Change Feed使用Azure Functions. 我为每个单独的容器CosmosDBTrigger分配了一个唯一的. 这似乎工作正常，但我不太清楚当基于消费的运行时决定扩展并创建多个活动工作者时会发生什么。LeaseCollectionPrefixFunctions

我需要确保多个工作人员不会收到同一个逻辑分区键的更改，因为我更新了一些聚合信息并且不希望并发把这搞砸。推送模型是否会Change Feed自动为每个活动工作人员分配逻辑分区键范围？还是会将更改传递给第一个可用的工作人员，从而使相同的逻辑分区键可以出现在多个工作人员中？

我正在调查ChangeFeedProcessorBuilder processor1在处理特定更改时引发异常或宕机的行为。恢复后，将不再拾取相同的更改。只有在成功处理通知后才能检查点？

委托人如下：

谢谢！