Comment 8 for bug 1080765

Revision history for this message
Daniel Nichter (daniel-nichter) wrote :

# NibbleIterator:5800 28000 0 rows in nibble 1

# ReplicaLagWaiter:7780 28000 All slaves caught up

# pt_table_checksum:10483 28000 ssodb03 max chunk: 1

# RowChecksum:5537 28000 SELECT CONCAT(db, '.', tbl) AS `table`, chunk, chunk_index, lower_boundary, upper_boundary, COALESCE(this_cnt-master_cnt, 0) AS cnt_diff, COALESCE(this_crc <> master_crc OR ISNULL(master_crc) <> ISNULL(this_crc), 0) AS crc_diff, this_cnt, master_cnt, this_crc, master_crc FROM `percona`.`checksums_ssodb03` WHERE (master_cnt <> this_cnt OR master_crc <> this_crc OR ISNULL(master_crc) <> ISNULL(this_crc)) AND (db='vsp_jira_current' AND tbl='AO_563AEE_ACTIVITY_ENTITY')

# pt_table_checksum:9539 28000 1 checksum diffs on ssodb03

That is strange. Unfortunately, the debug output doesn't help me understand why. I ran the same experiment (ptc in a while true loop), but couldn't reproduce the results.

Rob, could you reproduce this and once it happens, run that ^ SELECT query on master and slave and paste the results? (You may need to change tbl='...' for whatever table has the diff.) You may also want to run it multiple times to see if the results change. If they do, then it could be a MySQL bug (same deterministic query, same data, but different results = MySQL bug). If you can reproduce the false-positive diff with that SELECT query, a whole dump of the --replicate table WHERE db=... AND tbl=<the affected table> would be helpful too.

Otherwise, there's nothing in the debug output to help explain this. Then again, the debug output doesn't say much along these lines because this has never been wrong before.