Duplicate Key Error on _id

help
1 
WriteError({"code":11000,"index":0,"errmsg":"E11000 duplicate key error collection: db.locationtracking index: _id_ dup key: { : \"cvnAdmcwb4PaeZx9b\" }","op":{"companyId":"","cardId":"","event":"Position","eventDateTime":"2019-04-26T19:39:18.000Z","resourceType":"Truck","resourceId":"1700","latitude":,"longitude":,"city":"","state":"","proximity":"","_id":"cvnAdmcwb4PaeZx9b"}})
    at resultHandler (/home/site/wwwroot/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb/lib/bulk/ordered.js:459:11)
    at handler (/home/site/wwwroot/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb-core/lib/topologies/replset.js:1209:22)
    at /home/site/wwwroot/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb-core/lib/connection/pool.js:544:18
    at _combinedTickCallback (internal/process/next_tick.js:131:7)
    at process._tickDomainCallback (internal/process/next_tick.js:218:9)
    at endpoint: trucks/:id/position

Hey everyone, we’ve been trying to troubleshoot this issue for awhile now and we haven’t been able to come to a concrete solution. We are running 4 API servers that are running Meteor that are heavily using the Restivus package. There are no UI interactions on these servers. We have found that the issue is only happening on collections that have more than a few million documents in them. Our smaller collections have absolutely NO issues. This doesn’t make a lot of sense because the theoretical chances of running into a duplicate id using Meteor should be astronomical.

The _ids in Meteor.users consists of 17 characters (a-Z + 0-9). That gives you 17^44 = 1.379598e+54 combinations. If you would have a billion (10^9) documents in the collection, the risk of generating an existing _id would be 0.0000000000000000000000000000000000000000001%.

We have found people running into similar issues, but most seem to be around client and server sync problems and the other ones do not have a resolution. This dup key issue will start occurring after awhile on a single API instance and it won’t go away until we reboot the API server that is running into the issue. After a reboot the issue goes away and we might not see it for a week before it comes back.

Our insert statement uses the normal insert method for Meteor and we aren’t doing anything to this collection with collection hooks.

LocationTracking.insert();

Any thoughts or suggestions would be much appreciated!

2

The [A-Za-z0-9]<17> gives you 6217 or about 3x1030. Which is a lot, but the issue you’re seeing is more down to the birthday paradox, which for a large enough range means that there is a 50% chance of a collision once you reach sqrt(n), or about 1.7x1015 in this case. Still a big number, but that’s for a 50% chance on each new insertion. You can see that the more ids you have, the more likely it is there’ll be a collision, even if you’re nowhere near the 1.7x1015 documents.

3

I found the math somewhere else, but we are no where close to these numbers. The collection this is happening on has around 14 million records. If your math is correct we would need 1.7 quadtrillion records to start getting a 50% chance of collision. We will see 10’s of collisions a day when the issue starts happening on a 14 million record collection.

Are you suggesting we start manually setting _id when inserting doucments and using Random.id() with a larger character length?

4

I’d probably use a computed string based on the timestamp (which will be different each ms - assuming a single server instance) appended with a random string. For multiple servers, also include the host name or a hash of that. Basically, minimise your collision space.

1 Like