Guidance needed for pt-table-checksum on MySQL master-master / source-source replication

MySQL & MariaDB Other MySQL® Questions
,
1

Hi Percona community,

I’m looking for guidance on the safest operational pattern for using `pt-table-checksum` in a MySQL master-master / source-source replication setup.

Environment summary:

  • Database: MySQL Enterprise Edition bundled as part of the vendor application
  • Topology: two-node UA MySQL pair
    • node A: server11 (hosted site1)
    • node B: server21 (hosted site2)
  • Replication style: source-source / master-master replication
  • In practice, one node is considered primary in our application inventory, and the other is redundant/secondary, but MySQL replication exists between both nodes.
  • We are trying to use Percona Toolkit to detect table drift between these two nodes.

During validation, `pt-table-checksum` did not run with default safety checks because of the current UA MySQL configuration.

First, it failed due to ROW binlog format on the peer:

`Replica has binlog_format ROW which could cause pt-table-checksum to break replication.
If you understand the risks, specify --no-check-binlog-format to disable this check.

Exit status: 255`

After adding `–no-check-binlog-format` in non-prod testing, the next run failed due to replication skip/filter-related configuration:

`Replication filters are set on these hosts:

replica_skip_errors = 1032,1053,1062,1160
Please read the --check-replication-filters documentation to learn how to solve this problem.

Exit status: 255`

My questions:

1. For a master-master / source-source topology like this, what is the recommended `pt-table-checksum` execution model?

Should it be run only from one chosen source node, allowing checksum statements to replicate to the peer?

Or is it valid/recommended to run it from both nodes, one direction at a time, if both nodes can act as sources?

2. If running from both nodes is valid, what precautions should be used?

For example:

  • different schedules so runs never overlap
  • separate replicate tables
  • explicit DSNs instead of processlist discovery
  • locking / PID file
  • bounded runtime
  • specific table/database scope

3. Given the ROW binlog format warning, is `–no-check-binlog-format` acceptable in this kind of environment, or should we avoid `pt-table-checksum` unless statement-based behavior can be guaranteed?

4. Given `replica_skip_errors = 1032,1053,1062,1160`, is `–no-check-replication-filters` appropriate after documenting the risk, or does that make checksum results unreliable enough that we should not proceed?

5. Are there best practices for using `pt-table-checksum` with vendor-managed MySQL stacks where some MySQL settings cannot easily be changed?

Our current thinking is:

- Start with one intentional source node only, not cron on both nodes by default.
- Keep Percona safety checks enabled unless we can clearly justify overrides.
- Scope the tables/databases explicitly after non-prod canary testing.
- Capture non-prod evidence showing runtime, lag behavior, exit status, and drift/no-drift output before considering production scheduling.

I’d appreciate any expert guidance on whether this is the right approach, especially for master-master/source-source replication.

Regards,
Gokul

2

If you have replica, then you are just allowing the replica to become inconsistent.

You should first check the error logs if there are errors in the logs related to replication.
How big is your database?

As you mentioned that only one node is considered as primary and other is just having replication on it.
Make sure that there are no writes on the other node.

You can check our docs on parameters

If the replication had many errors and you had been ignoring, it is possible that most of the tables would show data inconsistency.

3

@Yunus - Thanks for the response.

I want to clarify that our environment is not a standard single-primary / read-only replica topology.

This is our application, where MySQL is an embedded/vendor-managed application component. In this deployment, the two MySQL nodes (GTID based replication) are intentionally configured in a bidirectional / source-source setup, and both nodes are expected to accept writes as part of the application design. So the concern is not an accidental write on a passive replica; dual write behavior is expected in this environment.

That is why I was specifically asking about pt-table-checksum guidance for a source-source / master-master style topology, rather than a traditional primary-replica model.

What I’m trying to understand is:

  1. In a true bidirectional writable topology, is pt-table-checksum still recommended from only one chosen source at a time?
  2. If both nodes are writable by design, how do you recommend interpreting “source” and “replica” roles for checksum runs?
  3. Is there any documented or recommended pattern from Percona for running pt-table-checksum safely in this kind of topology, assuming the two runs are intentional and non-overlapping?
  4. Are there specific limitations where pt-table-checksum is simply not a good fit for a dual-write source-source setup?

For additional context:

  • the database is not especially large in storage terms because older data is periodically shipped out of the application tier
  • our interest is mainly periodic drift detection and replication/data consistency validation

If source-source dual-write is outside the intended operating model of pt-table-checksum, that would also be useful to know explicitly.

Regards,
Gokul