Comment 11 for bug 1096274

I am not able to reproduce any of these reports, but I don't have enough info to do a true reproduction. To reproduce this, we need the full table structure (SHOW CREATE TABLE) being used. Two pseudo-table structs were provided, but indexes are critical, and I think that's probably the difference. PTDEBUG output might help, too.

In various attempts, the latest pt-archiver copied exactly the number of rows it should have. When it leaves a single row, this is due to not using --no-safe-auto-increment.

I could not verify this claim either: "if you attempt to copy over a small number of records - say 100 and your LIMIT is set to 500 - the tool will not Copy ANYTHING!". For example, using MySQL's sakila example database:

$ ./pt-archiver --source F=/tmp/12345/my.sandbox.cnf,D=sakila,t=rental --dest D=sakila,t=dst --limit 2000 --statistics --progress 2000 --no-delete --no-check-charset --where "rental_date < '2005-06-01'" --no-safe-auto-increment
TIME ELAPSED COUNT
2015-11-04T09:27:48 0 0
2015-11-04T09:27:49 0 1156
Started at 2015-11-04T09:27:48, ended at 2015-11-04T09:27:49
Source: D=sakila,F=/tmp/12345/my.sandbox.cnf,t=rental
Dest: D=sakila,F=/tmp/12345/my.sandbox.cnf,t=dst
SELECT 1156
INSERT 1156
DELETE 0

There's only 1156 rows in that range, less than the 2000 limit, but all rows are copied. Results are the same with --limit=5000 and with or without a matching --txn-size.