support unique_checks option

[mdcallag]

MySQL has the option unique_checks. Unique checks are disabled via 'set unique_checks=0'. MyRocks added an option, rocksdb_skip_unique_check, with the same effect when it could have used the existing option.

https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-bulk-data-loading.html

[VitaliyLi]

Hi,

The unique_checks is now supported and rocksdb_skip_unique_check deprecated:
f740684

Thank you,
Vitaliy

[george-lorch]

unique_checks is specifically for unique secondary indices, it appears to me from a quick browsing of the code that MyRocks is also now using this to disable unique checks for all keys (primary) which IMHO is pretty dangerous. TokuDB has a similar option but requires that all unique secondary indices have all key components as part of the primary key and will only skip the lookup on PK if it is an insert ignore or replace into.

[VitaliyLi]

Agree, will change unique_checks option to be applied only to secondary indexes. For primary indexes we will add another option then, as we need this functionality.

[lth]

@georgelorchpercona I was reading the documentation: https://www.percona.com/doc/percona-server/5.7/tokudb/tokudb_variables.html, and it seems like tokudb also disables PK checks when unique_checks is off (hence the warning about SK corruption)?

[george-lorch]

Good catch, thanks for keeping me honest. I had to go back through the code to verify but you, and the documentation, are correct. We went through all of this a while back right after we acquired Tokutek because we had users seemingly randomly setting every option that mentioned "fast" and ignoring all of the warnings then later complaining of logically corrupted indices. Yes, it really happens, and much more frequently than you would believe. If you give someone enough rope to shot themselves in the foot, eventually they will and they will blame you for allowing them to do it regardless of documented warnings. We closed some loopholes w.r.t. INSERT IGNORE and REPLACE INTO and tokudb_pk_insert_mode but left this one open that honestly we should have closed and made the behavior like the upstream documentation states, which would then be 100% safe.

So my previous comment was based on that memory but I failed to remember the unique_checks portion that we left in.