# How to run pt-table-sync on two replicas

**URL:** <https://forums.percona.com/t/how-to-run-pt-table-sync-on-two-replicas/39920>\
**Category:** Uncategorized\
**Created:** [December 19, 2025, 11:42am UTC](https://forums.percona.com/t/how-to-run-pt-table-sync-on-two-replicas/39920 "2025-12-19T11:42:36Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![andryosribeiro](https://avatars.discourse-cdn.com/v4/letter/a/85f322/32.png) [@andryosribeiro](https://forums.percona.com/u/andryosribeiro)\
**Post date:** [December 19, 2025, 11:42am UTC](https://forums.percona.com/t/how-to-run-pt-table-sync-on-two-replicas/39920/1 "2025-12-19T11:42:36Z")

</div>

I have one master environment and two slaves.

MASTER: 192.168.200.14  
SLAVE: 192.168.200.74  
SLAVE: 192.168.200.12

I ran pt-table-checksum and noticed a difference in slave 200.74.

According to the pt-table-sync manual, “changes are always made at the replication source, never directly on the replica.”

If the changes are made directly at the source (MASTER), I believe that through the binlog, the changes (replace) will also happen on 200.12, which has no differences. Am I right?

The command I intend to execute is this:

pt-table-sync --execute --replicate=percona.checksums --sync-to-master --databases=teste–tables=cadlogenviosmsespecifico h=192.168.200.74,u=usr\_xxxxxx,p=xxxxxx --socket=/var/lib/mysql/mysql.sock

The question is:

Does it apply the correction to 200.74 without applying it to the master? Or does it apply it to the master and the data comes through the binlog, also executing on 200.12?

I’m a little confused about how the tool works when you have two replicas.

---

<div class="post-metadata">

**Author:** ![matthewb](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/matthewb/32/34_2.png) [@matthewb](https://forums.percona.com/u/matthewb)\
**Post date:** [December 19, 2025, 4:05pm UTC](https://forums.percona.com/t/how-to-run-pt-table-sync-on-two-replicas/39920/2 "2025-12-19T16:05:28Z")

</div>

> [@andryosribeiro](#):
>
> I have one master environment and two slaves.

Correction, you have a **source** environment, and two **replicas.**

> [@andryosribeiro](#):
>
> If the changes are made directly at the source (MASTER), I believe that through the binlog, the changes (replace) will also happen on 200.12, which has no differences. Am I right?

Correct

> –sync-to-master

The correct flag is `--sync-to-source`

> [@andryosribeiro](#):
>
> does it apply it to the master and the data comes through the binlog, also executing on 200.12?

Yes. As it states, changes **NEVER** take place directly on replicas. Changes always go _through_ replication. If the data is correct on 200.12, then the UPDATE does nothing.

---

<div class="post-metadata">

**Author:** ![andryosribeiro](https://avatars.discourse-cdn.com/v4/letter/a/85f322/32.png) [@andryosribeiro](https://forums.percona.com/u/andryosribeiro)\
**Post date:** [December 19, 2025, 5:44pm UTC](https://forums.percona.com/t/how-to-run-pt-table-sync-on-two-replicas/39920/3 "2025-12-19T17:44:40Z")

</div>

Perfect, understood! Thanks for your help.

And in the case of missing data in 200.74, for example? Pt-table-sync tends to perform replace/insert commands, correct?

Assuming that:

- Data is missing in replica 200.74;
- The data is correct in Source 200.14;
- The data is correct in replica 200.12.

How does pt-table-sync behave, since the data exists in the Source and in one of the replicas?

Usually when data is missing in the replica, it performs a replace, correct? So, if the data that is missing in one of the replicas already exists in the source, does it delete the data from the source and insert it again so that the data reaches the replicas?

Doesn’t this tend to cause a replication error because the data already exists in one of the replicas? Or is the delete that is executed at the source also sent to the slaves?

This flow is a little confusing to me.

---

<div class="post-metadata">

**Author:** ![Yunus](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/yunus/32/6430_2.png) [@Yunus](https://forums.percona.com/u/Yunus)\
**Post date:** [December 20, 2025, 4:57am UTC](https://forums.percona.com/t/how-to-run-pt-table-sync-on-two-replicas/39920/4 "2025-12-20T04:57:30Z")

</div>

Hello @andryosribeiro

> [@andryosribeiro](#):
>
> Usually when data is missing in the replica, it performs a replace, correct? So, if the data that is missing in one of the replicas already exists in the source, does it delete the data from the source and insert it again so that the data reaches the replicas?
> 
> Doesn’t this tend to cause a replication error because the data already exists in one of the replicas? Or is the delete that is executed at the source also sent to the slaves?
> 
> This flow is a little confusing to me.

This tool changes data, so for maximum safety, you should back up your data before using it. When synchronizing a server that is a replication replica with the **[`--replicate`](https://docs.percona.com/percona-toolkit/pt-table-sync.html#cmdoption-pt-table-sync-replicate)** or **[`--sync-to-source`](https://docs.percona.com/percona-toolkit/pt-table-sync.html#cmdoption-pt-table-sync-sync-to-source)** methods, it **always** makes the changes on the replication source, **never** the replication replica directly. This is in general the only safe way to bring a replica back in sync with its source; changes to the replica are usually the source of the problems in the first place. However, the changes it makes on the source should be no-op changes that set the data to their current values, and actually affect only the replica.  
It sets the data to its current values on master and replicates that same data to all the replicas.

You can use –print option to understand what all statements it is going to execute.

> **[Percona Toolkit Documentation](https://docs.percona.com/percona-toolkit/pt-table-sync.html#cmdoption-pt-table-sync-print)**
>
> Specify at least one of --print, --execute, or --dry-run. | Command-line tools for common MySQL database administration tasks.
