Meet Cupcake for macOS·Version 2.3.11 is here→
← MySQL workflows and guides

Data integrity / Cupcake field notes

MySQL schema exports, snapshots, and data backups

A schema script can recreate the shape of a database. It cannot tell you whether a replica contains the right rows.

Start with what the file contains.

A DDL-only export records schema definitions, such as the statements used to create tables. It does not include the rows in those tables. MySQL makes the distinction explicit: mysqldump --no-data exports definitions without table contents. See the MySQL documentation on definitions and data.

That does not make schema exports unhelpful. They are useful for understanding structure, comparing definitions, and preparing a new environment. It means a successful schema export answers a narrower question than “can we recover our data?” A complete logical dump that includes rows is a different artifact and can be part of a backup strategy.

Matching structure does not mean matching data.

Imagine a source and replica with the same orders table definition. The replica can still be missing recent orders. It can contain a different status for an existing order, or a row that no longer exists in the source. None of those differences requires a schema change.

Even equal row counts do not prove equality: one missing row and one extra row can cancel each other out. A useful comparison needs to examine the identity and values of the rows within the scope you choose.

Use each workflow for the question it answers.

  • Schema comparison: do the table definitions differ?
  • Snapshot or baseline: what structure and data should be copied into the target?
  • Change capture: how do subsequent source changes reach that target?
  • Data comparison: which rows are missing, extra, or different when checked?
  • Reconciliation: which reviewed changes should be applied to close that drift?

In Cupcake-DRCP for macOS, these workflows share connection and plan context. You can inspect schema differences, compare data through your mappings, then decide whether to apply a repair or save its SQL for review.

Keep recovery independent.

A replica can receive an accidental change just as successfully as an intended one. Replication, a live comparison, and a repair workflow therefore serve different purposes from an independent recovery copy.

Keep your backup retention and restore testing in place. Use comparison findings to make the state of a target visible, and retain the results relevant to a cutover or operational decision. A passing comparison describes the work that was checked; it is not a promise about every future write.