I do not understand why an application requires the MIXED replication format, as MIXED is equal to STATEMENT-based, but changing to ROW format when executing "unsafe" queries. So, a MIXED-compatible application should be compatible with both STATEMENT and ROW.
As you can see here, if the the format detected (server-side) is ROW or MIXED, it tries to change ...
"Diffs cannot be detected because no slaves were found."
That means that you are using the tool incorrectly -a single run must be done so that it creates checksums that are eventually consistent for the master and the slave.
Run pt-table-checksum only directed to the master, and create the appropriate permissions so that it can check the slave, too. Maybe ...
This is what I'd suggest:
run SHOW INDEXES FROM Y.Z\G
use the index with the highest Cardinality in --chunk-index option
use a different hash function --function=md5
use a smaller --chunk-size (eg. 200)
Optionally, run ANALYZE TABLE on the affected table to re-calculate its statistics. Make sure you're aware of the effects of running ANALYZE TABLE on a ...
The message is both expected and disturbing.
WHY EXPECTED ?
I don't find this message disturbing at all. I would expect pt-table-checksum to bypass chunks since there is no defined uniqueness. Granted, InnoDB will create a row-based index called gen_clust_index when there is no PRIMARY KEY or UNIQUE INDEX. So, chunks read from the table have no rhyme or ...
There were false positives in old versions of pt-table-checksum. Make sure you don't run ancient version.
To check what the differences are you could also use this script():
#./compare_table.sh <db> <table> <master> <slave>
# $0 database table master slave
It is a non goal of pt-table-checksum to show you the actual differences. However, there is a companion tool pt-table-synch which can read the checksum table generated by pt-table-checksum. It will take the bounds of chunks where master/slave checksums differ and then scan with in those to identify rows that don't match.
It will even generate replace ...