pt-table-checksum doesn't ignore tables for --replicate-check-only

[John Ferlito]

I'm performing the following out of cron

pt-table-checksum master --replicate=pt.table_checksum --empty-replicate-table --quiet '--ignore-tables-regex=bad_table'

Then later I run

pt-table-checksum master --replicate=pt.table_checksum --empty-replicate-table '--ignore-tables-regex=bad_table' --replicate-check-only

I get the following output

Differences on slave-02
TABLE CHUNK CNT_DIFF CRC_DIFF CHUNK_INDEX LOWER_BOUNDARY UPPER_BOUNDARY
bad_database.bad_table 1 5 1

I would expect there to be no output

[Daniel Nichter (daniel-nichter)]

There might be two bugs here. The code block doing --replicate-check-only doesn't look at any of the filters, so that's one bug. The second bug is that since the table should have been ignored by the first run, it shouldn't exist for the second run, yet it seems to, so perhaps --ignore-tables-regex isn't working in general.

[Brian Fraser (fraserbn)]

I can only partially reproduce this.

If I run
$ pt-table-checksum master --replicate=pt.table_checksum --empty-replicate-table --quiet

and then

$ pt-table-checksum master --replicate=pt.table_checksum --empty-replicate-table '--ignore-tables-regex=bad_table' --replicate-check-only

I see the bug described; --replicate-check-only isn't using any of the filters, so the attached branch fixes that. However, the original bug had a --ignore-tables-regex=bad_table in the first invocation as well, but that works just fine here. John, could you post the steps to reproduce this, and if possible, the output of running the tool with PTDEBUG?

[John Ferlito (johnf-inodes)]

Hi Brian,

OK I've worked out what my real issue actually was. It is the way that --empty-replicate-table works. So apparently it empties the table as it checks each table just for that table.

So my workflow was

* run without the ignore
* bad_table now has entries in the checksums table
* run with the ignore
* It still complains because the values aren't deleted from the checksums table

I think the way --empty-replicate-table is non-intuitive. I would expect it to truncate the table so it is always starting afresh so old data can muck up the run.

Cheers,
John

[Brian Fraser (fraserbn)]

Hi John,

You know, I was under the same impression about --empty-replicate-table. It definitely sounds unintuitive, but digging further, the current behavior is needed to make --resume work, so changing it is not an option. So instead, I attached a second branch to this bug with a doc patch emphasizing how --empty-replicate-table works, and pointing out that if users want a truly empty --replicate table, they'll have to manually run a TRUNCATE TABLE.

Not the best solution, but it might save someone our current headache.

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PT-338