# Exec\_Master\_Log\_Pos less than Read\_Master\_Log\_Pos after Slave I/O thread stopped **URL:** \ **Category:** Other MySQL® Questions\ **Created:** [January 7, 2020, 8:58am UTC](https://forums.percona.com/t/exec-master-log-pos-less-than-read-master-log-pos-after-slave-i-o-thread-stopped/7369 "2020-01-07T08:58:45Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![chris-card](https://avatars.discourse-cdn.com/v4/letter/c/5fc32e/32.png) [@chris-card](https://forums.percona.com/u/chris-card)\ **Post date:** [January 7, 2020, 8:58am UTC](https://forums.percona.com/t/exec-master-log-pos-less-than-read-master-log-pos-after-slave-i-o-thread-stopped/7369/1 "2020-01-07T08:58:45Z")
We are running a Percona 5.5.22 master replicating to Percona 5.5.62 slaves on CentOS 6.9. We have a database backup script which runs on the slaves and before taking a backup the script attempts to ensure that replication is in sync on the slave. It does this by stopping the Slave I/O thread and waiting until Exec\_Master\_Log\_Pos = Read\_Master\_Log\_Pos. Most of the time this works fine, but occasionally Exec\_Master\_Log\_Pos never reaches Read\_Master\_Log\_Pos - it just sticks at a value lower than Read\_Master\_Log\_Pos, even after 5 minutes, and so the backup doesn’t get run. Any idea what is going on? Is this a valid way of checking that replication has caught up? Chris ---
**Author:** ![chris-card](https://avatars.discourse-cdn.com/v4/letter/c/5fc32e/32.png) [@chris-card](https://forums.percona.com/u/chris-card)\ **Post date:** [January 8, 2020, 4:44am UTC](https://forums.percona.com/t/exec-master-log-pos-less-than-read-master-log-pos-after-slave-i-o-thread-stopped/7369/2 "2020-01-08T04:44:11Z")
An actual example: after stopping the slave i/o thread, the Read\_Master\_Log\_Pos was 1007861939 and the Exec\_Master\_Log\_Pos was 1007861863. Decoding the corresponding binary log showed this: # at 1007861863 #200108 9:05:00 server id 172032277 end\_log\_pos 1007861939 Query thread\_id=585405709 exec\_time=0 error\_code=0 SET TIMESTAMP=1578474300/_!_/; BEGIN /_!_/; # at 1007861939 So it appears that replication has read the SET TIMESTAMP …;BEGIN event, but doesn’t exec it. Is that expected? ---
**Author:** ![lorraine.pocklington](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/lorraine.pocklington/32/37_2.png) [@lorraine.pocklington](https://forums.percona.com/u/lorraine.pocklington)\ **Post date:** [January 8, 2020, 8:12am UTC](https://forums.percona.com/t/exec-master-log-pos-less-than-read-master-log-pos-after-slave-i-o-thread-stopped/7369/3 "2020-01-08T08:12:02Z")
Hi chris-card Can I just check for the sake of clarity if you are using Percona XtraDB Backup in your backup scripts and if so which version? Also, I know that you probably already realize this (sorry for the added hassle factor) but please be aware that 5.5 is end-of-life software… Let me know on PXB and I will see if anyone is about to advise on this question. [URL][Percona Release Lifecycle Overview](https://www.percona.com/services/policies/percona-software-platform-lifecycle#lifecycle%5B/URL%5D) ---
**Author:** ![chris-card](https://avatars.discourse-cdn.com/v4/letter/c/5fc32e/32.png) [@chris-card](https://forums.percona.com/u/chris-card)\ **Post date:** [January 8, 2020, 9:01am UTC](https://forums.percona.com/t/exec-master-log-pos-less-than-read-master-log-pos-after-slave-i-o-thread-stopped/7369/4 "2020-01-08T09:01:13Z")
Hi Lorraine, in this case we aren’t using XtraDB Backup, we’re using mysqldump. We may use XtraDB Backup in the future, though I had the impression that the resulting backups are bigger because the ibdata1 file is copied, and that could be a problem for us. We also plan to upgrade to 5.6 at some point, but we’re upgrading hardware at the moment and we didn’t want to change too much at once. Chris ---
**Author:** ![lorraine.pocklington](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/lorraine.pocklington/32/37_2.png) [@lorraine.pocklington](https://forums.percona.com/u/lorraine.pocklington)\ **Post date:** [January 10, 2020, 11:51am UTC](https://forums.percona.com/t/exec-master-log-pos-less-than-read-master-log-pos-after-slave-i-o-thread-stopped/7369/5 "2020-01-10T11:51:45Z")
All good, just wanted to make sure of the scenario. Can I just get you to check if either of these articles help you out here: [URL][https://www.percona.com/blog/2014/05/02/how-to-identify-and-cure-mysql-replication-slave-lag/[/URL]](https://www.percona.com/blog/2014/05/02/how-to-identify-and-cure-mysql-replication-slave-lag/%5B/URL%5D) [URL][https://www.percona.com/blog/2013/04/17/reset-slave-vs-reset-slave-all-disconnecting-a-replication-slave-is-easier-with-mysql-5-5/[/URL]](https://www.percona.com/blog/2013/04/17/reset-slave-vs-reset-slave-all-disconnecting-a-replication-slave-is-easier-with-mysql-5-5/%5B/URL%5D) However, I’ll also see if I can engage someone that might have a straight answer. Thanks! ---
**Author:** ![lorraine.pocklington](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/lorraine.pocklington/32/37_2.png) [@lorraine.pocklington](https://forums.percona.com/u/lorraine.pocklington)\ **Post date:** [January 10, 2020, 12:11pm UTC](https://forums.percona.com/t/exec-master-log-pos-less-than-read-master-log-pos-after-slave-i-o-thread-stopped/7369/6 "2020-01-10T12:11:50Z")
I had an update For the export, would this work for you? mysqldump --single-transaction --master-data=2 --etc --etc ---
**Author:** ![chris-card](https://avatars.discourse-cdn.com/v4/letter/c/5fc32e/32.png) [@chris-card](https://forums.percona.com/u/chris-card)\ **Post date:** [January 14, 2020, 3:42am UTC](https://forums.percona.com/t/exec-master-log-pos-less-than-read-master-log-pos-after-slave-i-o-thread-stopped/7369/7 "2020-01-14T03:42:10Z")
The problem isn’t the backup, but detecting that replication is up-to-date before running the backup. It seems that relying on Read\_Master\_Log\_Pos == Exec\_Master\_Log\_Pos is not correct, so I am asking if there is a more reliable test.