シャーディングされたクラスターで長時間実行されているセカンダリ読み取り

例

次の構造を持つ zipcodesコレクションを含む citiesデータベースを考えてみましょう。

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

この例では 、zipcodeフィールド値は一意であると仮定しています。

次の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
      }
   }
}

例データベースとアプリケーションロジックを確認する際には、次の点を考慮してください。

• この例コードでは、zipcode でソートする再開メカニズムを使用して QueryPlanKilled エラーを処理します。zipcodeフィールドでソートすると、各ドキュメントに対して一貫した順序と一意のソート値が確保されます。これにより、アプリケーションは読み取り操作が終了した場所で正確に再開できるようになります。

• cities.zipcodesコレクションには、再開メカニズム クエリの効率を確保するために {state: 1, zipcode: 1}複合インデックスが実装されています。この複合インデックスを実装すると、コレクションスキャンとメモリ内ソートの両方が防止され、フィルター操作とソート操作がサポートされます。効果的なインデックスの作成の詳細については、ESR（Equality、Sort、Range）ガイドラインを参照してください。

• QueryPlanKilled エラー（エラー コード 175）は、セカンダリ読み取りが終了した以外の理由で発生する可能性があります。QueryPlanKilled エラーを正確に処理するには、errmsgフィールドを解析する必要があります。MongoDB は、セカンダリ読み取りを終了するときに次のエラー メッセージを返します。

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

• アプリケーションで孤立した範囲のクリーンアップが原因で QueryPlanKilled エラーが発生した場合、再開されたクエリの開始点として最後に正常に処理された郵便番号を使用します。$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.