web-dev-qa-db-ja.com

MongoDB-エラー：getMoreコマンドが失敗しました：カーソルが見つかりません

約50万のドキュメントのコレクション内の各ドキュメントに新しいフィールドsidを作成する必要があります。各sidは一意であり、そのレコードの既存のroundedDateおよびstreamフィールドに基づいています。

私は次のコードでそうしています：

var cursor = db.getCollection('snapshots').find();
var iterated = 0;
var updated = 0;

while (cursor.hasNext()) {
    var doc = cursor.next();

    if (doc.stream && doc.roundedDate && !doc.sid) {
        db.getCollection('snapshots').update({ "_id": doc['_id'] }, {
            $set: {
                sid: doc.stream.valueOf() + '-' + doc.roundedDate,
            }
        });

        updated++;
    }

    iterated++;
}; 

print('total ' + cursor.count() + ' iterated through ' + iterated + ' updated ' + updated);

最初は問題なく動作しますが、数時間後に約10万件のレコードが記録されると、次のエラーが発生します。

Error: getMore command failed: {
    "ok" : 0,
    "errmsg": "Cursor not found, cursor id: ###",
    "code": 43,
}: ...

mongo error

node.jsmongodbmongodb-querycursor
18
Chava Sobreyra

編集-クエリパフォーマンス：

@NeilLunnがコメントで指摘したように、ドキュメントを手動でフィルタリングするのではなく、代わりに.find(...)を使用する必要があります。

db.snapshots.find({
    roundedDate: { $exists: true },
    stream: { $exists: true },
    sid: { $exists: false }
})

また、MongoDB 3.2から利用可能な .bulkWrite() を使用すると、個々の更新を行うよりもはるかにパフォーマンスが向上します。

それにより、カーソルの10分間の有効期間内にクエリを実行できる可能性があります。それでもそれ以上かかる場合は、カーソルが期限切れになり、とにかく同じ問題が発生します。これについては以下で説明します。

ここで何が起こっていますか：

Error: getMore command failedは、2つのカーソル属性に関連するカーソルタイムアウトが原因である可能性があります。

  • タイムアウト制限。デフォルトでは10分です。 ドキュメントから ：

    デフォルトでは、非アクティブ状態が10分間続くか、クライアントがカーソルを使い果たした場合、サーバーは自動的にカーソルを閉じます。

  • バッチサイズ。101個のドキュメントまたは最初のバッチでは16 MB、ドキュメントの数に関係なく、後続のバッチでは16 MB（MongoDB 3.4時点）。 ドキュメントから ：

    find()およびaggregate()操作の初期バッチサイズは、デフォルトで101ドキュメントです。後続の getMore 結果のカーソルに対して発行される操作にはデフォルトのバッチサイズがないため、16メガバイトのメッセージサイズによってのみ制限されます。

おそらく、最初の101個のドキュメントを使用してから、最大16 MBのバッチを取得し、さらに多くのドキュメントを追加することになります。それらを処理するのに10分以上かかるため、サーバー上のカーソルがタイムアウトし、2番目のバッチでドキュメントの処理が完了するまでに および新しいドキュメントを要求します 、カーソルは既に閉じています：

カーソルを繰り返し処理し、返されたバッチの最後に到達すると、さらに結果がある場合、cursor.next（）はgetMore操作を実行して次のバッチを取得します。

可能な解決策：

私はこれを解決するための5つの可能な方法、3つの良い方法、それらの長所と短所、2つの悪い方法を見ています：

  1. ????バッチサイズを小さくして、カーソルを維持します。

  2. ????カーソルからタイムアウトを削除します。

  3. ????カーソルの有効期限が切れたら再試行してください。

  4. ????結果をバッチで手動でクエリします。

  5. ????カーソルが期限切れになる前にすべてのドキュメントを取得します。

特定の基準に従って番号が付けられていないことに注意してください。それらを読み、特定のケースに最適なものを決定します。

1. ????カーソルを維持するためにバッチサイズを小さくする

これを解決する1つの方法は、 cursor.bacthSize を使用して、findクエリによって返されるカーソルのバッチサイズを、10分以内に処理できるものと一致するように設定することです。

const cursor = db.collection.find()
    .batchSize(NUMBER_OF_DOCUMENTS_IN_BATCH);

ただし、非常に保守的な（小さな）バッチサイズを設定することはおそらく機能しますが、サーバーへのアクセス回数を増やす必要があるため、速度も遅くなることに注意してください。

一方、10分で処理できるドキュメントの数に近すぎる値に設定すると、何らかの理由で一部の反復の処理に少し時間がかかる場合があります（他のプロセスがより多くのリソースを消費している可能性があります） 、とにかくカーソルは期限切れになり、同じエラーが再び表示されます。

2. ????カーソルからタイムアウトを削除します

別のオプションは、 cursor.noCursorTimeout を使用して、カーソルがタイムアウトしないようにすることです。

const cursor = db.collection.find().noCursorTimeout();

これは、カーソルを手動で閉じるか、すべての結果を使い果たして自動的に閉じる必要があるため、悪い習慣と見なされます：

noCursorTimeoutオプションを設定したら、カーソルを cursor.close() で手動で閉じるか、カーソルの結果を使い果たす必要があります。

カーソル内のすべてのドキュメントを処理するため、手動で閉じる必要はありませんが、コード内で何か他の問題が発生し、完了する前にエラーがスローされ、カーソルが開いたままになる可能性があります。

それでもこの方法を使用する場合は、try-catchを使用して、すべてのドキュメントを使用する前に何か問題が発生した場合にカーソルを確実に閉じてください。

注：これは悪い方法だと考えられていたので、これは悪い解決策ではありません（したがって????）。

  • これは、ドライバーがサポートする機能です。他のソリューションで説明されているように、タイムアウトの問題を回避する代替方法があるため、それが非常に悪かった場合、これはサポートされません。

  • それを安全に使用する方法があります、それはそれで余分な注意を払うだけの問題です。

  • この種のクエリを定期的に実行しているわけではないため、開いているカーソルをどこにでも残してしまう可能性は低くなります。これが当てはまらず、常にこれらの状況に対処する必要がある場合は、noCursorTimeoutを使用しないのが理にかなっています。

3. ????カーソルの有効期限が切れたら再試行してください

基本的に、コードをtry-catchに配置し、エラーが発生すると、すでに処理したドキュメントをスキップする新しいカーソルを取得します。

let processed = 0;
let updated = 0;

while(true) {
    const cursor = db.snapshots.find().sort({ _id: 1 }).skip(processed);

    try {
        while (cursor.hasNext()) {
            const doc = cursor.next();

            ++processed;

            if (doc.stream && doc.roundedDate && !doc.sid) {
                db.snapshots.update({
                    _id: doc._id
                }, { $set: {
                    sid: `${ doc.stream.valueOf() }-${ doc.roundedDate }`
                }});

                ++updated;
            } 
        }

        break; // Done processing all, exit outer loop
    } catch (err) {
        if (err.code !== 43) {
            // Something else than a timeout went wrong. Abort loop.

            throw err;
        }
    }
}

このソリューションが機能するには、結果をソートする必要があることに注意してください。

このアプローチでは、事前に10分以内に処理できるドキュメントの数を推測することなく、最大16 MBのバッチサイズを使用して、サーバーへの要求の数を最小限に抑えています。したがって、以前のアプローチよりも堅牢です。

4. ????結果をバッチで手動でクエリする

基本的に、 skip（） 、 limit（） および sort（） を使用して、処理できると思われる多数のドキュメントで複数のクエリを実行します10分で。

ドライバーには既にバッチサイズを設定するオプションがあるため、これは悪いソリューションであると考えます。したがって、手動でこれを行う理由はなく、ソリューション1を使用し、車輪を再発明しないでください。

また、ソリューション1と同じ欠点があることに言及する価値があります。

5. ????カーソルが期限切れになる前にすべてのドキュメントを取得する

おそらく、結果処理のためにコードの実行に時間がかかるため、最初にすべてのドキュメントを取得してから処理することができます。

const results = new Array(db.snapshots.find());

これにより、すべてのバッチが次々に取得され、カーソルが閉じられます。次に、results内のすべてのドキュメントをループして、必要な処理を実行できます。

ただし、タイムアウトの問題がある場合は、結果セットが非常に大きい可能性があります。したがって、メモリ内のすべてをプルすることは、最も賢明なことではありません。

スナップショットモードと重複ドキュメントに関する注意

文書サイズの増加により、書き込み操作を介在させると、一部の文書が複数回返される可能性があります。これを解決するには、cursor.snapshot()を使用します。 ドキュメントから ：

Snapshot（）メソッドをカーソルに追加して、「スナップショット」モードを切り替えます。これにより、文書サイズの増加により、書き込み操作の途中で文書が移動しても、クエリが文書を複数回返さないことが保証されます。

ただし、その制限に留意してください。

  • 断片化されたコレクションでは機能しません。

  • sort() または hint() では機能しないため、ソリューション3および4では機能しません。

  • 挿入または削除からの分離を保証するものではありません。

ソリューション5では、重複ドキュメントの取得を引き起こす可能性のあるドキュメントの移動の時間ウィンドウが他のソリューションよりも狭いため、snapshot()は必要ない場合があります。

特定のケースでは、コレクションはsnapshotと呼ばれるため、おそらく変更される可能性は低いため、おそらくsnapshot()は必要ありません。さらに、データに基づいてドキュメントを更新します。更新が完了すると、同じドキュメントはif条件によってスキップされるため、複数回取得されても再び更新されることはありません。

開いているカーソルに関する注意

開いているカーソルの数を確認するには、 db.serverStatus().metrics.cursor を使用します。

61
Danziger

これは、mongodbサーバーのセッション管理のバグです。現在進行中の修正、4.0 +で修正される必要があります

SERVER-34810：セッションキャッシュのリフレッシュにより、まだ使用中のカーソルが誤って強制終了される場合があります

（MongoDB 3.6.5で再現）

collection.find().batchSize(20)を追加すると、パフォーマンスがわずかに低下しました。

2
Vladimir Ishenko

私もこの問題に遭遇しましたが、私にとってはMongDBドライバーのバグが原因でした。

3.0.x npmパッケージmongodbのバージョンで発生しました。この問題を記録したMeteor 1.7.0.xで使用されています。このコメントでさらに詳しく説明し、スレッドにはバグを確認するサンプルプロジェクトが含まれています。 https://github.com/meteor/meteor/issues/9944#issuecomment-420542042

Npmパッケージを3.1.xに更新すると、ここで@Danzigerから与えられた良いアドバイスを考慮に入れていたので、それを修正しました。

1
SimonSimCity

Java v3ドライバーを使用する場合、FindOptionsでnoCursorTimeoutを設定する必要があります。

DBCollectionFindOptions options =
                    new DBCollectionFindOptions()
                        .maxTime(90, TimeUnit.MINUTES)
                        .noCursorTimeout(true)
                        .batchSize(batchSize)
                        .projection(projectionQuery);        
cursor = collection.find(filterQuery, options);
0
user1240792