# pt-table-checksum slows point in time recovery

**URL:** <https://forums.percona.com/t/pt-table-checksum-slows-point-in-time-recovery/6600>\
**Category:** Percona Toolkit\
**Created:** [September 28, 2018, 10:57am UTC](https://forums.percona.com/t/pt-table-checksum-slows-point-in-time-recovery/6600 "2018-09-28T10:57:32Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![scottb](https://avatars.discourse-cdn.com/v4/letter/s/e79b87/32.png) [@scottb](https://forums.percona.com/u/scottb)\
**Post date:** [September 28, 2018, 10:57am UTC](https://forums.percona.com/t/pt-table-checksum-slows-point-in-time-recovery/6600/1 "2018-09-28T10:57:32Z")

</div>

Master/Slave replication.  
Backup Slave nightly.  
Run pt-table-checksum on Master nightly.

We periodically restore from a nightly Slave backup and replay Master binary log files from the time of the backup to a specific date/time.

Replaying the binary log files includes the statements that take a checksum of all dbs/tables. Depending on the recovery could be multiple days.

Is there a recommended way of excluding the checksum statements from going to the Masters binary log?  
Or excluding them from the mysqlbinlog export or mysql replay?

Thanks Scott

---

<div class="post-metadata">

**Author:** ![przemek](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/przemek/32/3_2.png) [@przemek](https://forums.percona.com/u/przemek)\
**Post date:** [October 14, 2018, 7:55am UTC](https://forums.percona.com/t/pt-table-checksum-slows-point-in-time-recovery/6600/2 "2018-10-14T07:55:16Z")

</div>

I wonder why you have to check the data consistency every day, do the data inconsistencies happen that often? If so, maybe you should try to prevent them, like by using super\_read\_only setting on the slave, etc.

The pt-table-checksum tool does work that way, it logs the checksum statement to the binary log, so that the slave can execute it’s own checksums. So, no way to skip those from being binlogged.  
However, when you do full restore later, you may use PITR technique by setting up temporary “master” and use replication filters to skip those. Check out this method here: [https://www.percona.com/blog/2017/10/23/mysql-point-in-time-recovery-right-way/](https://www.percona.com/blog/2017/10/23/mysql-point-in-time-recovery-right-way/)