unique key conflict within the collection

[hiep1097]

@vinllen Conflict Detection feature not supported in MongoShake opensource version. So what happen if unique key conflict within the collection occur? Is the consistency can be guarantee?

[vinllen]

Yes, it can be guaranteed. The hash function is based on the collection as default(incr_sync.shard_key = collection in configuration collection.conf). So the oplog order on one collection can be guaranteed, as a result, the unique key conflict won't happen. However, if you change the incr_sync.shard_key to id, the order of oplog can't be guaranteed even if two oplogs related to one document. So, the unique key conflict may happen. Generally speaking, this configuration is always used when there is no unique key except _id exists on the collection, and it can keep more fine-grained concurrency than hash by collection to increase the syncing performance.

[hiep1097]

Yes, it can be guaranteed. The hash function is based on the collection as default(incr_sync.shard_key = collection in configuration collection.conf). So the oplog order on one collection can be guaranteed, as a result, the unique key conflict won't happen. However, if you change the incr_sync.shard_key to id, the order of oplog can't be guaranteed even if two oplogs related to one document. So, the unique key conflict may happen. Generally speaking, this configuration is always used when there is no unique key except _id exists on the collection, and it can keep more fine-grained concurrency than hash by collection to increase the syncing performance.

Thanks. But I think you should update your document more clearly. In the document: "in the case of collection-level concurrency, it is necessary to be able to distribute the concurrency evenly and also to solve the case of a unique key conflict within the collection", it make me think that the unique key conflict may occur on collection-level concurrency.

[vinllen]

Thanks for your advice, I'll do it later.