Using pt-table-checksum without creating a new percona schema in a vendor-managed MySQL Enterprise database

Hi Percona community,

I’m looking for guidance on the best way to use pt-table-checksum in a vendor-managed MySQL environment.

Environment:

  • Oracle Unified Assurance application
  • Bundled MySQL Enterprise Edition as a third-party/vendor-managed component
  • Two-node MySQL replication setup
  • Using Percona Toolkit from internally approved RPMs
  • Goal: monitor replication/table drift and alert when checksum differences are detected

pt-table-checksum is working technically when using the default replicate table:

--replicate=percona.checksums
--create-replicate-table

However, we have a concern that creating a new schema named percona inside the vendor-managed MySQL instance may not be allowed under our product/license/support boundaries.

My questions:

  1. Is it fully supported to use pt-table-checksum with an existing application or monitoring schema instead, for example:
--replicate=Assure1.pt_table_checksums

or:

--replicate=ua_monitoring.pt_table_checksums
  1. Does pt-table-checksum require the replicate table to be in a separate schema, or can it safely live in any replicated schema/table as long as both source and replica can access it?

  2. For environments where creating any new schema/table is not allowed, is there a recommended Percona Toolkit alternative for recurring drift detection?

  3. Would pt-table-sync --print between two DSNs be a reasonable read-only alternative for alerting, or is that considered too heavy/risky for periodic monitoring?

  4. Are there any best practices for using pt-table-checksum in vendor-managed or restricted MySQL environments where DB object creation must be minimized?

Our current requirement is alerting only. We don’t need automatic repair. We just need reliable detection of drift with minimal impact and minimal changes to the vendor-managed database.

Thanks in advance for any recommendations or real-world experience.

Regards, Gokul

Yes. pt-table-checksum can use an existing schema/table via:

--replicate=ua_monitoring.pt_table_checksums

It does not require a separate schema. The key requirements are that the table exists or can be created on the source, replicates to the replicas, has the expected structure, and is accessible by the checksum user on both source and replicas. Percona’s docs specifically note that the --replicate table must exist on all replicas, otherwise checksum writes from the source can break replication.

Use pt-table-checksum with a vendor-approved existing monitoring schema, such as:

--replicate=ua_monitoring.pt_table_checksums

That is reasonable and supported as long as the table is replicated and accessible. Avoid application schemas if possible; prefer a monitoring/admin schema to reduce ownership confusion. For alerting only, run pt-table-checksum on a schedule with conservative chunking/load limits, then alert on non-zero diffs from the checksum output/table.