[SOLVED] Percona Toolkit "pt-table-sync" ... didn't!

I'm trying to use the pt-table-sync command (Ubuntu latest ...) to synchronize all tables in two databases in the following way:

pt-table-sync --verbose --databases medics --execute h=10.11.22.77,u=root,p=secret h=127.0.0.1,u=root,p=secret

... and it cooks away for a while and produces promising-looking output like this:

# DELETE REPLACE INSERT UPDATE ALGORITHM START    END      EXIT DATABASE.TABLE
#     25       0   3380    437 Nibble    14:50:49 15:09:05 2    medics.address_book
#   8590       0   9015      0 Chunk     15:09:11 15:19:07 2    medics.aggregate_info

... but I first noticed that it seemed to produce the same output each time I ran it, as though it were simply re-discovering the same differences again.

Suspicious, now, I found that this is apparently so: the number of rows in (say ...) the address_book table between the two databases was not equal. It looks like "3380 rows should have been inserted," but that they weren't!

When I then ran it against just one table with the D=,t= options, once again the output of the command was the same as before, and the resulting number of rows in the table was not identical: 73,858 in the source; 73,699 in the target. (Also notice that the difference in row-count is only a few hundred ... not "3380.")

Several hours spent running this utility ... seemed to have not done anything at all.

I thought that someone said that this tool, y'know, "sync'd two MySQL databases!" It doesn't appear to do so. At least, not for me!

Why?

At this point I can generally say that the product ... simply does not work for me.

I have, in various times and in various ways, tried to get to do its job but without success.

I tried adding the --tables tablename option, specifying just one table, and I actually got it to end having said that it had nothing further to do, and that the tables were now in sync. But the table in one database contains 18,276 rows, and the same table in the other contains 18,215. Most of the rows that are missing were added in the last few days, not "just moments ago."

The indexes on this table are either Integer or DateTime. The algorithm used was Chunk and by all indications it should have succeeded. (Also possibly-significant is that the omissions would have been in the final chunk, as they are the last rows in the table.) Could this in fact be a bug?

Oh my ... I just found it.

False Alarm!

I was syncing against a slave that had recently stopped replicating!

I was syncing the data against the out-of-date slave, then comparing it to the master.