AsyncIOMotorCommandCursor.fetch_next 是否会阻止可重试读取？答案

【问题标题】：Does AsyncIOMotorCommandCursor.fetch_next prevent a retryable read?AsyncIOMotorCommandCursor.fetch_next 是否会阻止可重试读取？
【发布时间】：2021-06-04 08:00:45
【问题描述】：

我正在尝试在 Mongo Atlas 集群故障转移期间使用 motor 诊断读取故障。 Retryable-Reads 规范定义了aggregate calls are retryable，但是Cursor.getMore is not。我的代码如下所示：

cursor = db.foo.aggregate([...])

if not await cursor.fetch_next:
    raise SomeException

doc = cursor.next_object()

此代码似乎不会在集群故障转移期间重试，因为它在内部调用 getMore我假设。我不完全清楚是否是这种情况。更别提fetch_next is deprecated anyway了。

将其更改为可重试读取吗？

async for doc in cursor:
    break
else:
    raise SomeException

还是这样导致内部处理相同，问题出在其他地方？

目标是尝试以可重试的方式从聚合管道（有一个或没有）读取单个结果文档，如果没有则引发异常。

【问题讨论】：

错误是什么？可重试读取是解决网络错误的非常低级的事情。如果您正在获取单个文档，则不会调用 getMore。文档（如果存在）在第一批 github.com/mongodb/mongo-python-driver/blob/… 中返回，并且聚合命令本身是可重试的。
ConnectionRefusedError: [Errno 111] Connection refused During handling of the above exception, another exception occurred: [...] pymongo.errors.AutoReconnect: example.mongodb.net:27017: [Errno 111] Connection refused — 我不确定这是否意味着驱动程序确实尝试重新连接并且失败了两次。如果是这种情况，那么集群扩展期间的 Atlas 故障转移就相当糟糕了……？！
可能没有完全损坏，但比可接受的要慢一些。可重试的东西只尝试重新连接一次。如果第二次尝试失败，则返回原始错误。我猜在你的情况下，新的主节点还没有被选举出来，或者至少客户不知道选举结果。
尝试设置“primaryPreferred”阅读偏好。它应该有助于解决这种情况。默认情况下，它严格从主要读取以提高一致性。如果您可以阅读过时的数据，请放宽阅读偏好。否则，您将需要在应用程序级别处理此类错误。
有道理。所以，需要明确的是，上面的代码应该没问题，问题可能源于“迟到的选举”和过于严格的阅读偏好？

标签： python mongodb pymongo mongodb-atlas

【解决方案1】：

您需要挽救驱动程序在此代码之外的网络错误引发的任何异常，并在这种情况下重复整个迭代。

驱动程序会自动重试初始查询，但不会重试 getMores，因为它们无法指定结果集中的位置。因此，驱动程序的可重试读取逻辑对于健壮的应用程序来说是不够的，您仍然需要在完整迭代级别上处理应用程序中读取错误的可能性。

如果您要检索单个文档，它通常应该包含在初始查询响应中，并且不需要 getMores，因此实际上这个问题不适用。

【讨论】：

那么“聚合可重试”是什么意思？
驱动程序可以重试初始查询。
所以，如果在我即将发送aggregate 查询时连接已经断开，that 将被重试，但如果数据库在@ 987654323@整理和我检索结果，它不会？
驱动程序执行一次重试。这是两个网络错误。
@deceze 会的。看起来查询和检索结果是 pymongo API 上的 2 个不同操作，但在网络上，您的聚合“完成”数据包已经包含文档 docs.mongodb.com/manual/reference/mongodb-wire-protocol/…。在您收到聚合查询的 OP_REPLY 之前发生的任何网络错误都将触发重试。一次。