So far, I haven’t been able to & have therefore found little use for the CHECKSUM TABLE feature. Any clues or directions would be greatly appreciated.

-fleegan

If tables in the master get modified while mysql-table-checksum is running then this won’t work, or will it?

In other words, do my master and slave have to be just sitting there accepting no connections for this to work? Or just one part has to be stopped (replication itself maybe).

First, initial tests show that COUNT(*) is not much faster than the checksums, at least on InnoDB tables (I will publish these results soon). So this strategy would not be a good one for all scenarios. Let’s say we just omit the COUNT(*) part and select the MIN() and MAX(), which can be satisfied quickly from indexes. Then we divide this into ranges and repeatedly query, possibly with a sleep, as you said. I think rather than just divide into a fixed number of ranges, the DBA should specify the maximum number of rows to checksum at once, and the tool can take care of dividing into ranges with BETWEEN.

This has the disadvantage that the ranges might not be the same size and some of them might even be empty if there are holes in the sequence, but I think it is practical.

This is an important feature I’ll work on soon, but I’m not sure how soon — some people have requested features for MySQL Table Sync that are also important. You are welcome to help if you wish. If you know Perl the code is relatively straightforward. Patches are welcome.

This method can produce “false positives” errors, but very rarely(when we update primary key) and can’t work for tables without primary/unique keys, but don’t produce long locks - it’s very important for some applications.

P.S. Sorry for my english ;-)

I’m sure if MySQL would build something into the server, it would be more efficient than anything I can do outside the server. Until they do that, your options are fairly limited (understatement of the month, haha).