Mongodump and other tools broken after upgrade to 5.0

Ops and Admin
, ,
1

Since 2022-04-26, when we updated to mongo 5.0 with compatibility version on 4.4, we’re having a issue with mongodump and other tools / commands for mongodb.
We investigated and figured it might boil down to a index on a single collection in one of our databases.

Mongodump error: mongodump: read data: make dump: error dumping metadata: (Location5254501) Could not parse catalog entry while replying to listIndexes.
We validated all indices in our cmd database and got an error on one of the indices.

db.tickets.validate()
{
        "ns" : "cmd.tickets",
        "nInvalidDocuments" : 0,
        "nrecords" : 88638415,
        "nIndexes" : 42,
        "keysPerIndex" : {

        },
        "indexDetails" : {

        },
        "valid" : false,
        "repaired" : false,
        "warnings" : [ ],
        "errors" : [
                "The index specification for index 'interaction.networkItemId_1' contains invalid field names. The field 'safe' is not valid for an index specification. Specification: { v: 1, key: { interaction.networkItemId: 1 }, name: \"interaction.networkItemId_1\", ns: \"cmd.tickets\", background: true, safe: null }. Run the 'collMod' command on the collection without any arguments to remove the invalid index options"
        ],
        "extraIndexEntries" : [ ],
        "missingIndexEntries" : [ ],
        "corruptRecords" : [ ],
        "advice" : "A corrupt namespace has been detected. See http://dochub.mongodb.org/core/data-recovery for recovery steps.",
        "ok" : 1,
        "$clusterTime" : {
                "clusterTime" : Timestamp(1651416503, 80),
                "signature" : {
                        "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
                        "keyId" : NumberLong(0)
                }
        },
        "operationTime" : Timestamp(1651407947, 2)
}

We dropped the faulty index and ran a full-validate again, that returned all collections in that database valid.

But mongodump still fails with the same error. Also db.runCommand({listIndexes: "tickets"}) fails.

There are some 42 indices on the tickets collection. When executing db.runCommand({listIndexes: "tickets", cursor: {batchSize:19}}) and then using getMore on that cursorId with an arbitrary batchSize, we can list all indices in that collection.

But when we want to list all or a significant number of indices the command fails. We figured out the magic index seems to be number 20 as db.runCommand({listIndexes: "tickets", cursor: {batchSize:19}}) works but db.runCommand({listIndexes: “tickets”, cursor: {batchSize:20}})` fails with

MongoServerError: Could not parse catalog entry while replying to listIndexes

The full-validate had two warnings but they don’t seem to be that much of a problem

"warnings" : [
                "Could not complete validation of table:collection-31-1751203610025669779. This is a transient issue as the collection was actively in use by other operations.",
                "Could not complete validation of table:index-32-1751203610025669779. This is a transient issue as the collection was actively in use by other operations."

We plan to increase compatibilitylevel to 5 this week. we are also interested in your opinion if this might worsen or resolve our current issue.

Kind regards
Michael

1 Like
2

Hi , Michael_Schmid
got the same problem after upgrade to 5.0 mongo
like 2022-05-25T17:59:52.121+0300 Failed: error dumping metadata: (Location5254501) Could not parse catalog entry while replying to listIndexes

the thing is in broken indexes after upgrade.

for me helped next steps
running commands like

db.getCollection('triggers').getIndexes();
db.getCollection('unsaved-edits').getIndexes();
db.getCollection('users').getIndexes();

for all your collections.
This helps to find broken stuff

> db.getCollection('cfs_gridfs._tempstore.files').getIndexes();
MongoServerError: Could not parse catalog entry while replying to listIndexes

After that just dropped and recreated needed indexes

db.getCollection('cfs_gridfs._tempstore.files').dropIndexes();