pt-table-checksum creating empty checksum table

I successfully ran pt-table-checksum once against one of my masters. Subsequently, I have upgraded to v2.2 of percona-toolkit.

Now, when I run pt-table-checksum against the same master with a new checksum table (old checksum table was in test db, new table is in percona db), instead of chunking/summing the tables in my target database the tool immediately exits without any error or message, but it creates the replicate table (which is replicated to the slave) and does not populate it. Any idea how to fix this?

I’m running:

pt-table-checksum -u percona-test -p redacted --create-replicate-table --nocheck-replication-filters --set-vars innodb_lock_wait_timeout=50 --databases foo

Dave,

Could you please send us the output with the debug info?

PTDEBUG=1 pt-table-checksum -u percona-test -p redacted --create-replicate-table --nocheck-replication-filters --set-vars innodb_lock_wait_timeout=50 --databases foo > pt-table-checksum.log 2>&1

Regards,

Martin

Hi Martin -

Thanks for replying. Now that I know how to get debug output I figured out the problem. The test user I set up for using pt-table-checksum didn’t have sufficient permissions to show the database I was trying to checksum, but instead of getting a nice message that the database couldn’t be selected, it was quietly dying. Here’s the relevant portion of the debug output:

SchemaIterator:7146 3414 Getting next schema object from dbh DBI::db=HASH(0x1d6ab980)

SchemaIterator:7150 3414 SHOW DATABASES

SchemaIterator:7223 3414 Database information_schema is a system database, ignoring

SchemaIterator:7240 3414 Database percona is not in --databases list, ignoring

SchemaIterator:7156 3414 Found 0 databases

SchemaIterator:7162 3414 Next database: undef

pt_table_checksum:10004 3414 Exit status 0 oktorun 1 have time 1

Cxn:3587 3414 Destroying cxn

Running SHOW DATABASES as that user only showed the information_schema and percona databases. After allowing SELECT on the target database, pt-table-checksum is running.

The user had

PROCESS
SUPER
REPLICATION CLIENT
REPLICATION SLAVE

but not SELECT on the target database.

Thanks for your help!
-Dave