Long-Running Secondary Reads in Sharded Clusters分片集群中的长期二次读取

Example示例

Consider a cities database containing a zipcodes collection with the following structure:考虑一个包含以下结构的zipcode集合的cities数据库：

{
        "state": "NY",
        "city": "NEW YORK",
        "zipcode": "00501"
}

For this example, assume the zipcode field values are unique.对于这个例子，假设zipcode字段值是唯一的。

The following JavaScript code performs a secondary read operation to retrieve all documents where the state is NY and implements a resume mechanism to handle QueryPlanKilled errors:以下JavaScript代码执行二次读取操作以检索state为NY的所有文档，并实现恢复机制来处理QueryPlanKilled错误：

let readDoc;
let latestZip;

let cursor = db.getSiblingDB("cities").zipcodes.find({
   state: "NY"
})
.sort({zipcode: 1})
.readPref("secondary");

while(cursor.hasNext()) {
   try {
      readDoc = cursor.next();
      // process `readDoc` here
      latestZip = readDoc.zipcode;
   } catch (err) {
      if (err.code === 175 &&
         err.errmsg.includes("Read has been terminated due to orphan range cleanup")) {
         console.log("Query terminated, resuming from zipcode:", latestZip);

         cursor = db.getSiblingDB("cities").zipcodes.find({
               state: "NY",
               zipcode: {$gt: latestZip}
         })
         .sort({zipcode: 1})
         .readPref("secondary");
      } else {
         throw err; // Rethrow non-termination errors重新考虑非终止性错误
      }
   }
}

When reviewing the example database and application logic, consider the following:在查看示例数据库和应用程序逻辑时，请考虑以下几点：

• The example code handles QueryPlanKilled errors with a resume mechanism that sorts by zipcode. 示例代码使用按zipcode排序的恢复机制处理QueryPlanKilled错误。Sorting on the zipcode field ensures a consistent order and a unique sort value for each document. This allows the application to resume the read operation precisely where it was terminated.对zipcode字段进行排序可确保每个文档的顺序一致，排序值唯一。这允许应用程序在终止的位置精确地恢复读取操作。
• The cities.zipcodes collection implements a {state: 1, zipcode: 1} compound index to ensure the efficiency of the resume mechanism queries. cities.zipcodes集合实现了一个{state: 1, zipcode: 1}复合索引，以确保恢复机制查询的效率。Implementing this compound index prevents both collection scans and in-memory sorts, and supports filter and sort operations. 实现此复合索引可以防止集合扫描和内存排序，并支持筛选和排序操作。To learn more about creating effective indexes, see The ESR (Equality, Sort, Range) Guideline.要了解有关创建有效索引的更多信息，请参阅ESR（相等、排序、范围）指南。
• The QueryPlanKilled error (error code 175) can occur for reasons other than terminated secondary reads. QueryPlanKilled错误（错误代码175）可能是由于终止二次读取以外的原因而发生的。To accurately handle QueryPlanKilled errors, you must parse the errmsg field. MongoDB returns the following error message when it terminates a secondary read:为了准确处理QueryPlanKilled错误，您必须解析errmsg字段。MongoDB在终止二次读取时返回以下错误消息：

{
   code: 175,
   name: QueryPlanKilled,
   categories: [CursorInvalidatedError],
   errmsg: "Read has been terminated due to orphan range cleanup"
}

• When the application encounters a QueryPlanKilled error due to orphan range cleanup, it uses the last successfully processed zipcode as a starting point for the resumed query. 当应用程序因孤立范围清理而遇到QueryPlanKilled错误时，它会使用最后一个成功处理的邮政编码作为恢复查询的起点。The $gt operator ensures the application does not process duplicate documents.$gt运算符确保应用程序不会处理重复的文档。

Test your resume mechanisms in a test environment and monitor your production cluster to understand how often secondary reads are terminated. If terminations occur frequently, you might need to adjust your query patterns, or consider alternative data access approaches. 在测试环境中测试恢复机制，并监控生产集群，以了解二次读取终止的频率。如果频繁发生终止，您可能需要调整查询模式，或考虑其他数据访问方法。To learn how to monitor your cluster for these errors, see Monitoring.要了解如何监视集群中的这些错误，请参阅监视。