Comment 5 for bug 1253537

Frank: That is not a workaround, at least not in all cases.

A typical use of recursion-method=dsns for me is when I want to exclude some replicas from being monitored by pt-table-checksum. Imagine intentionally delayed replicas (via pt-slave-delay): I don't want pt-table-checksum to wait for those to catch up before proceeding with the checksum process. Another case is when replicas are using non standard ports, or they don't all use the same credentials.

So if master M has replicas R1, R2 and R3, of which R3 is delayed, I'll usually create the percona.dsns table and only insert rows for R1 and R2.

That works well for pt-table-checksum, but since pt-table-sync does not support the option, if the delayed replica R3 is also on a non standard port and/or using different credentials, pt-table-sync will fail with an error like this:

[root@master ~]# pt-table-sync --print --replicate percona.checksums --databases dbname localhost
Cannot connect to h=some.example.ip.address

I think the only workaround would be to run --sync-to-master from some.example.ip.address directly, but in some cases, that can fail too (i.e. if the replication connection from replica to master is via an ssh tunnel, meaning the master is also on localhost but on a different port. It seems in that case pt-table-sync, when trying to connect to the master, connects to localhost:3306, which is the slave itself).

That means that, to me, there is no reliable workaround for this problem.