GET 24/7 LIVE HELP NOW

Announcement

Announcement Module
Collapse
No announcement yet.

pt-table-checksum showing checksum difference

Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • pt-table-checksum showing checksum difference

    SUSE 11 Enterprise
    MySQL 5.5.8
    pt-table-checksum 1.0.1
    ----------------------------------

    I have MASTER-SLAVE replication set up.
    pt-table-checksum consistently returns different checksums for 2 tables. When I do a mysqldump on the tables and the do a DIFF on the dump files, there are no differences.

    I've also refreshed the slave 2 times and restarted replication, but the tables still show different checksums for those tables.

    Below are the fields from one of the tables.

    search_index | CREATE TABLE `search_index` (
    `word` varchar(50) NOT NULL DEFAULT '' COMMENT 'The search_total.word that is associated with the search item.',
    `sid` int(10) unsigned NOT NULL DEFAULT '0' COMMENT 'The search_dataset.sid of the searchable item to which the word belongs.',
    `type` varchar(16) NOT NULL COMMENT 'The search_dataset.type of the searchable item to which the word belongs.',
    `score` float DEFAULT NULL COMMENT 'The numeric score of the word, higher being more important.',
    PRIMARY KEY (`word`,`sid`,`type`),
    KEY `sid_type` (`sid`,`type`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8


    Any ideas what might be going on?

    Thanks!

  • #2
    I changed to "--algorithm=BIT_XOR" and now the checksums match.

    Any idea what's causing this?

    Thanks!

    Comment


    • #3
      Sometimes there is a difference in floating-point values at precisions beyond what mysqldump will output. I don't know why changing to BIT_XOR would change the results. I would suggest using small chunks and isolating a specific chunk, then selecting the rows from that chunk on both servers, using ROUND() if needed to make float/double columns show a lot of digits of precision (20 digits, perhaps).

      Comment


      • #4
        Are there any side effects of using BIT_XOR instead?

        Thanks!

        Comment


        • #5
          No, it's just a checksum algorithm. Sometimes checksums will give a false positive (collision), but not a false negative. We're removing everything except BIT_XOR in the new version of the tool.

          Comment


          • #6
            Thanks!

            BIT_XOR seems to work fine!

            Comment

            Working...
            X